AI Agent Evaluation: Why “Done” Is Not Completion
An agent response, an artifact, a verified result, and a real-world outcome are different things. Use a four-layer definition of completion for AI agent evaluation.
This article synthesizes public Anthropic and Claude engineering material with Gwarket's analysis of verifiable AI workflows. It is not Anthropic documentation or a product commitment.
When an AI says “done,” it is easy to treat the sentence as a result. It is not proof. It is only a claim about what the system believes it did.
That distinction becomes important as agents gain access to files, tools, databases, and external services. An agent can describe a correct-looking report without having written the file. It can say that a form was submitted when no record exists. It can produce an elegant research summary whose key facts do not survive a source check.
The useful question is not “Did the agent finish?” It is “What must be true in the environment for this task to count as finished?”
Four layers of completion
- Response complete: the agent says what it did.
- Artifact complete: a document, file, table, or draft actually exists.
- Result complete: that artifact meets the requested data, format, and constraints.
- Task complete: the intended change has occurred in the real system or for the real user.
Take meeting notes. A written summary is only the first layer. Saving it in the right place is another. Including decisions, owners, and unresolved items is another. The task is closer to complete only when the team can actually follow up from it.
Anthropic's agent-evaluation guidance distinguishes a transcript from an outcome for the same reason. A transcript records the path an agent took. An outcome is the final state left in the environment. The two can disagree.
Verify the final state, not only the prose
The verification method should fit the task. Code changes need tests, builds, and observed behavior. Research needs sources, citations, and explicit unknowns. A system action needs a record in the system that was meant to change.
Before delegation, write four fields:
| Field | Question |
|---|---|
| Artifact | What file, decision, or record should exist? |
| Acceptance | What observable conditions make it correct? |
| Exceptions | What uncertainty or failure must remain visible? |
| Permission | Which external action requires human confirmation? |
This does not reduce autonomy. It removes the need for the agent to guess what “good” means.
A research example
Imagine an agent reports that it has completed a competitor analysis with five competitive advantages. That sentence hides the work that matters. Are the advantages supported by current primary sources? Did the agent turn a company's self-description into fact? Did it fill missing evidence with a plausible inference? Can a decision-maker use the analysis without discovering that its foundations are weak?
Without a completion definition, the most fluent answer wins. With one, the agent can be asked to show what it knows, what it inferred, and what it could not verify.
Make incompleteness a legitimate result
Workflows often display only success. That encourages a system to hide a gap behind confident language. A better state model allows messages such as: “Eight of ten required sources were found,” “two key claims could not be verified,” or “this is a discussion draft, not public-ready copy.”
An honest incomplete result is often more useful than an apparently complete one. It tells the next person where judgment is needed.
Conversation history is not a delivery record either. A usable workflow distinguishes raw sources, candidate output, approved output, and unresolved questions. That makes the work intelligible a week later, even when the original chat is no longer open.