Agent reliability
Your AI agent said “done.” How do you prove it?
Define agent completion with independent evidence, a worked intake example, and a reusable scorecard for outcomes, destinations, and side effects.
An AI agent has finished a task when the requested outcome exists in the right system, matches your instructions, and passes a check the agent cannot satisfy merely by saying it succeeded. A confident reply, a successful tool call, and a completed business task are different things.
Start with the smallest check that proves the outcome. If the task is to save a record, read the saved record. If it is to deliver a message, distinguish acceptance by the sending service from observed delivery. If it is to publish a page, inspect the public page. Report anything you could not verify as unknown.
Define “done” before giving the agent tools
Write one sentence describing the final state. Then name the evidence needed to establish it.
“Organize this intake request” is ambiguous. “Create one draft intake record, attach the source document, assign it to the review queue, and send nothing externally” gives the workflow a testable boundary.
This follows a useful distinction in Anthropic’s agent-evaluation guide, published January 9, 2026: a transcript records what happened during a run; the outcome is the final state in the environment. Evaluation should examine both without confusing them.
Use this approach when the workflow changes something
Outcome checks are especially useful for workflows that create records, update files, schedule work, or call another service. They also help with read-only research: the outcome may be a report with supported claims and sufficient coverage rather than a changed database.
Avoid turning every low-stakes draft into an elaborate approval process. Match the check to the consequence. A suggested heading needs editorial review. A production database update needs stronger authorization, state checks, and a recovery path. No checklist makes an unauthorized action acceptable.
Worked example: a synthetic intake workflow
Suppose an agent reads a fictional equipment-service request. It should create a draft record and place it in an internal review queue. It must not contact the requester.
The create-record tool responds successfully. The agent says the request is ready. A separate read-back finds a record, but its status is new, not awaiting_review. The attachment is missing. The task is incomplete even though the tool returned success.
A better completion check verifies the record identifier, status, source attachment, and assigned queue. It also checks that no outward message was triggered. The agent can then report the verified result or explain which step needs attention.
If a timeout interrupts the create operation, do not immediately create another record. Use a stable request identifier to check whether the first attempt already wrote the record. A repeated call should return or update the existing result where the system supports that behavior. Otherwise, stop for review rather than risk duplication.
This example is illustrative. It is not a test result or a description of a client system.
Worksheet
Completion scorecard
Copy this for one task. Use pass, fail, or unknown. Do not convert missing evidence into a pass. Scroll the table horizontally on a narrow screen.
| Check | Your expected result | Evidence to inspect | Result |
|---|---|---|---|
| Authorized scope | Account, record, allowed actions | Approved task boundary | ___ |
| Correct output | Required fields and source attached | Saved artifact or record | ___ |
| Correct destination | Intended account and queue | Independent read-back | ___ |
| No duplicate | One result for this request | Record lookup by request identifier | ___ |
| Safe side effects | No unauthorized sends or writes | Service activity record | ___ |
| Useful result | Ready for the next person or step | Reviewer acceptance | ___ |
Task: ___
Reviewer: ___
Evidence location and check time: ___
Unresolved issue and next action: ___
Failure mode: trusting the same story twice
Asking the agent “Are you sure?” does not provide independent evidence. Nor does checking only its summary of a tool response. Where practical, use a read-only check against the system that owns the result, with a verifier separate from the agent’s editable workspace.
Protect the review trail too. METR’s October 6, 2026 research post describes a proof-of-concept vulnerability that could alter a transcript viewer without changing the underlying database records. METR did not observe agents exploiting it in its evaluations. The practical lesson is narrower than “never trust logs”: treat agent-generated content as untrusted, protect the underlying evidence, and safely display it.
Acceptance checklist
- Define the outcome and prohibited side effects before execution.
- Test normal inputs, missing data, interrupted calls, and repeated requests.
- Check the owning system, not only the agent’s reply.
- Keep failures and unknowns visible; do not average away a critical error.
- Record the tool, model, and workflow versions used in each test.
- Name who reviews exceptions and who can authorize the next action.
The goal is a useful result with a defensible completion receipt—not a longer conversation about whether the agent tried hard enough.
Next, compare the cost of accepted work across model routes, including the checking needed to prove completion.
Sources linked above were checked October 7, 2026. The workflow and scorecard are implementation guidance, not a guarantee of safety or performance.