# Test the work before you reuse the Agent. Reviewed: 2026-10-18 Canonical: https://clankercloud.ai/learn/test-ai-agent-before-reuse Test an AI Agent against a small packet with an answer you can verify. Inspect its saved output, run an incomplete-input case, and make one correction. Record the observed results and keep the inputs unchanged when comparing revisions. Manual acceptance checks work before any optional saved evaluation features are enabled. ## What you are working toward A documented acceptance decision supported by source checks and actual saved outputs. ## Start with - A narrow Agent role and a reviewer who can judge the output - A small source packet with known facts and a deliberate ambiguity - A scorecard separating expected behavior from observed evidence ## Turn a broad promise into a checkable question “Is this a good Agent?” is too broad to answer from one demonstration. Ask whether it can prepare the stated deliverable from the selected inputs while respecting the task’s action boundary. An allocation reviewer might need to sum overlapping approved reservations, exclude pending requests, and show any shortage against stock. Write these checks before the first run. Decide what failure would block reuse and what would merely need an edit. A missing critical source should carry more weight than a heading you dislike. Keep formatting preferences separate from factual and operational requirements so a polished layout cannot hide an incorrect conclusion. ## Create a packet small enough to inspect completely Use fictional records or approved sources that you understand. Include a normal fact, a missing value, and a statement that sounds plausible but is only proposed. Give the inputs stable names or source markers. Keep a separate reviewer reference describing what the output should and should not conclude. Do not provide the answer reference as part of the initial task. The Agent should demonstrate that it can derive the result from the source packet. A reviewer can consult the reference afterward. If the task depends on current web information, record the date and exact sources observed rather than expecting a static example to prove current coverage. ## Inspect the artifact, then the explanation Ask for a specific saved file in the intended Project. Open it through Files or Preview and compare its consequential statements with the sources. Check tables, totals, labels, and omitted facts. A Session saying “saved” is a lead to inspect, not the evidence that the deliverable is complete. Record pass, revise, or not observed for each criterion, with a source location or file observation. “Not observed” is useful when you have not tested a behavior. Do not turn it into a pass because a related feature exists. Note any manual repair needed before another person could use the output. ## Change one condition that should matter Remove a required return time, omit a stock count, or add a reservation whose approval is unresolved. The correct response may be a question, a partial calculation, or a clearly labeled limit on availability. Define that expected response in advance instead of rewarding whichever confident answer appears. Then supply a legitimate amendment and inspect the revised output. A reservation quantity can be updated in the table while an old shortage remains in the summary. Review the whole file and any handoff note. A successful first draft does not establish that the Agent can maintain consistency when the evidence changes. ## Compare revisions without moving the target Keep the same input packet and acceptance criteria when testing a changed Agent. Record which instructions, references, Skills, or Tools changed. If you change the examples and the configuration together, an improved answer may reflect easier evidence rather than a better role. Manual tests can be kept in ordinary Project documents and a scorecard. Where saved evaluations are enabled, review the actual cases, checks, run evidence, and supported runtime. A completed model response or finished job does not prove that the result was correct. An automated result can support the acceptance decision without replacing consequential source review. ## Make the reuse decision match the evidence Approve the role for the behavior you tested: for example, drafting internal updates from supplied files with review. Do not extend that result to sending client messages, changing a database, or unattended operation. Each extension adds different access, failure, and recovery requirements that need their own trial. Keep the input packet, scorecard, saved output, and review date together. Retest when a material rule, source, tool, or environment changes. Use version history if a revised setup needs to be restored. Before sharing the Agent, give its recipient the same small acceptance exercise and explain which parts remain untested. ## Try this prompt Copy into a Workspace Session. Opening Workspace does not send it automatically. ```text Help me test this Agent for the specific job in its brief. Before running anything, propose an acceptance scorecard for source accuracy, unknown facts, saved output, and action boundaries. Use the fictional packet I provide. Keep the reviewer answer separate from the Agent input. After one normal case, run one missing-input case and one correction. Save the observed evidence as pass, revise, or not observed. Do not send messages, publish, or start recurring work. ``` ## Before using the result - Expected results were written before the first run. - The Agent received the source packet without the reviewer answers. - Material claims and missing facts were checked in the saved artifact. - The difficult case and correction have their own observations. - The reuse decision covers only the tested role and access. ## Common questions ### Is one successful demonstration enough? It can justify a narrow supervised trial, but it does not establish every behavior. Include a normal case, an incomplete or conflicting input, and a correction before depending on a reusable role. ### Can I test without saved Evals? Yes. Keep inputs, expected behavior, outputs, and a scorecard in ordinary Project files. Saved evaluation features are optional and availability-dependent. ### Does a completed job count as a passed test? No. Completion shows that execution ended. Check the saved result against its acceptance criteria and record the evidence before marking the task correct. ## Sources - [Clanker: create and test a custom Agent](https://clankercloud.ai/learn/build-a-custom-agent) - [Clanker: testable instructions and known examples](https://clankercloud.ai/learn/write-reusable-agent-instructions) - [Clanker Workspace: current product capabilities and availability](https://clankercloud.ai/faq) ## Related - [Build an Agent you can test, reuse, and hand over.](https://clankercloud.ai/learn/ai-agent-factory) - [Give the Agent a test with an answer you can check.](https://clankercloud.ai/templates/agent-acceptance-test) - [Write the Agent brief before adding capabilities.](https://clankercloud.ai/templates/agent-specification) - [Turn a correction into a better repeatable method.](https://clankercloud.ai/learn/improve-agent-from-corrections) - [Give your agents a place to do lasting work.](https://clankercloud.ai/learn/ai-agent-workspace) - [A small packet the next agent can verify.](https://clankercloud.ai/templates/agent-handoff-pack) [Open Workspace](https://workspace.clankercloud.ai) [Current pricing and usage](https://clankercloud.ai/pricing)