How to evaluate an AI agent before it starts doing client work

Define acceptable behaviour before testing

Choose one job and state its useful result. Include permitted sources, actions requiring approval, actions the system must never take and the conditions that should stop it. Give a reviewer enough information to judge the result.

Separate different failure types. A correctly written answer from the wrong client’s record is an access failure. A correct citation supporting the wrong claim is an evidence failure. A useful draft that was sent before approval is an action failure.

Build tests from actual work and known exceptions

Begin with approved or anonymised examples of the current process. Include ordinary requests, incomplete inputs, changed requirements and unusual but legitimate cases. Keep some examples outside the development set so you can test behaviour on work the system was not tuned against.

For each example, record the expected result and the evidence needed to justify it. A precise expectation might be “return unknown and request the account owner’s decision because two current budget records disagree”. Avoid “give a good answer”.

Use synthetic examples when access or a known exception makes them useful, and label them. They help exercise a rule but do not demonstrate how often the condition occurs in live client work.

Try a small set of evidence checks yourself

The AI knowledge-base tutorial includes downloadable code with 12 tests. They cover current sources, client boundaries, missing and expired records, future dates, contradictions, incomplete provenance, false citations, unsupported answers and model-response failures.

node --test demo.test.mjs
node demo.mjs client-a budget-approved account-a 2026-10-01

The second command returns unknown because the two invented budget sources disagree. The sample holds the decision for a person. Run the tests in the unzipped knowledge-base example folder.

Review the route as well as the answer

Said describes provenance as central to our current build. Each trace needs a reviewable baseline or deterministic element. If the system cannot expose the required evidence for review, it must acknowledge that it does not know.

Inspect tool inputs and results, selected record IDs, their dates and the decisions that followed. Check whether a valid source is relevant to the actual claim. A citation that exists is only the beginning of that check.

If the agent can act, use a test environment and a controlled adapter before giving it live authority. Test duplicate events and partial failures. Include a budget for model calls, time and retries, so an incomplete job cannot keep trying indefinitely.

Make a release decision for the tested job

Record failures by their consequences, and decide which block rollout. A private-data leak or unapproved external action should not disappear inside a high average score. Report the test coverage and unresolved gaps alongside any overall result.

Retest after changes to the model, prompt, tools, retrieval, source schema or business rules. Use monitored early jobs and a named owner for corrections. Reviewed human decisions can update the business records; that is different from automatically training model weights.