AI agents need a better definition of done than ordinary workplace shorthand usually provides. A person can hear “clean up the report” and infer the audience, the house style, the level of evidence, the deadline, and the point at which the work should stop. An agent can sometimes infer those things too, but every inference becomes a place where the task can drift. The result may look finished while missing the one condition that made the work useful.
Acceptance criteria turn delegated work from a vague request into a task with an inspectable finish line. They say what must be true before the work can be treated as complete, what evidence should travel with the result, which boundaries must remain intact, and which checks should run before a person reviews the output. For agents, this is not administrative polish. It is part of the safety and quality system.
This guide sits close to AI Agent Task Decomposition because decomposed work needs local finish lines. It also connects to AI Agent Output Verification because acceptance criteria are the promises verification will later inspect. Without criteria, verification becomes a mood. With criteria, the reviewer can compare the result against the assignment instead of against a private expectation.
Done Is Not the Same as Busy
Agents are good at producing activity. They can search, summarize, draft, edit, run commands, compare documents, and prepare a handoff. Activity is useful only when it moves toward a named state. If the original task is “look into why onboarding emails are underperforming,” the agent may return a long summary of possible causes. That can be helpful, but it may not be done. The real need might have been a source-backed diagnosis, a list of data gaps, and a proposal for the next experiment.
The first purpose of acceptance criteria is to separate motion from completion. A research task might be complete only when it names the sources inspected, distinguishes evidence from inference, and describes what remains unknown. A coding task might be complete only when the scoped files changed, the focused tests ran, and the agent names any checks it could not perform. A customer operations task might be complete only when the draft uses approved policy, avoids private details that should not be sent, and stops before any irreversible action.
Those criteria do not make the agent smarter. They make the task less ambiguous. The agent still has to reason, but it now reasons toward a visible target. The reviewer also gets a better surface. Instead of asking “does this feel good enough,” the reviewer can ask whether the result meets the named conditions.
Criteria Should Describe Evidence, Not Only Output
A weak acceptance criterion describes only the artifact. “Return a summary” is weak because summaries can be plausible without being grounded. “Return a summary that identifies the governing source, names conflicting evidence, and marks unsupported claims as assumptions” is stronger because it describes the proof that must accompany the artifact.
This distinction matters because agents often fail by producing fluent artifacts with thin evidence. A polished plan can hide the fact that the agent never found the current policy. A confident fix can hide the fact that no test was run. A neat comparison can hide that two options were researched deeply while a third was barely inspected. Acceptance criteria should make those gaps harder to hide.
Evidence requirements should match the task. A low-risk internal brainstorm may not need much proof. A customer-facing policy draft needs source references. A code change needs file paths, commands, and observed results. A workflow that touches private data needs a clear reason for using that data and a record of what was withheld. AI Agent Observability can preserve the trace, but acceptance criteria decide which parts of that trace matter for completion.
Boundaries Belong in the Finish Line
Many agent mistakes are not failures of effort. They are failures of scope. The agent completes something adjacent to the assignment, changes more files than needed, researches a broader market than requested, or takes an action the user meant only to prepare. Acceptance criteria should therefore say not only what must happen, but what must remain untouched.
For a coding agent, the boundary may be a directory, a test target, a public API, or a requirement not to refactor unrelated code. For a browser agent, it may be a rule not to submit forms, not to accept terms, not to message people, or not to rely on untrusted page content as instruction. For an operations agent, it may be a limit on which records can be read, which fields can be changed, and which actions require approval.
This connects directly to AI Agent Permissions . Permission design sets the authority ladder. Acceptance criteria tell the agent and reviewer which rung belongs to this task. If the task is to draft, then a sent message is not extra success. It is a boundary failure. If the task is to inspect, then a changed record is not initiative. It is overreach.
Good criteria make staying inside the boundary part of being done. The handoff should be able to say, in ordinary language, that the task stayed within the assigned files, sources, records, or action level. That statement is valuable only when the boundary was named before the run began.
Validation Should Be Concrete
Acceptance criteria should name the checks that matter before the agent claims completion. The check may be automated, manual, or evidential. What matters is that it is concrete enough to inspect.
In software work, validation might include running a focused test command, checking a diff, confirming no unrelated files changed, or reproducing the original failure before and after the fix. In research work, validation might mean comparing a claim against primary sources, checking that sources are current enough for the task, and marking places where no source was found. In document work, validation might include matching the requested audience, tone, and length, but it should also include whether required facts are supported.
The point is not to force every agent task through a heavy gate. The point is to prevent a common final move: the agent says it is done because it has produced something. Production is not validation. A draft can exist and still fail the assignment. A patch can compile and still violate scope. A summary can be readable and still rely on stale material.
AI Agent Evaluations test agent behavior across many tasks. Acceptance criteria are the local version of that habit. They give the single run a small rubric. When those criteria are repeated across similar work, they also become material for evaluation. The team can see which conditions agents meet reliably and which ones need better tools, prompts, or review.
The Criteria Should Fit the Risk
Not every task deserves the same ceremony. If the agent is renaming a private note, the acceptance criteria may be brief. If it is preparing a public statement, proposing a database migration, handling a customer complaint, or changing production code, the criteria should be sharper. The weight of the finish line should match the consequence of being wrong.
The risk is not only about technical harm. Review burden is also a cost. A task with weak criteria may save time during assignment and then spend that time during review, when the human has to reconstruct the missing standard. A task with bloated criteria may slow simple work for no reason. The mature habit is to choose the smallest set of criteria that actually changes whether the work can be trusted.
For many agent tasks, the useful criteria are plain. The result should answer the requested question or produce the requested artifact. It should name the evidence used. It should identify unresolved assumptions. It should stay inside the stated boundary. It should perform the relevant checks or say which checks were unavailable. It should distinguish proposed work from completed action. These conditions are not exotic. They are the difference between a helpful delegate and a confident blur.
Criteria Make Handoffs Less Tense
The best acceptance criteria reduce the emotional load of reviewing agent work. The reviewer does not have to guess what the agent thought done meant. The handoff can be read against a shared standard. If a condition is missing, the reviewer can send the task back with precision. If all conditions are met, acceptance becomes easier because the result carries the evidence needed to trust it.
This is where acceptance criteria meet Human Review for AI Agents . Human review is strongest when the reviewer can inspect the artifact, the evidence, the validations, and the remaining risks without replaying the entire run. Acceptance criteria define those expected pieces before the handoff exists. They give the agent a structure for reporting and the human a structure for deciding.
Criteria also make partial completion honest. If the agent finds that no approved source exists, the task can finish as blocked rather than pretending to answer. If the tests cannot run because a dependency is unavailable, the task can finish with a clear validation gap. If the work exposes a risk outside the original scope, the agent can hand off a decision instead of absorbing the new task silently. A blocked result may be a good result when the criteria say what safe blocking looks like.
A Finish Line Is a Form of Control
AI agents are often discussed through models, tools, memory, and permissions. Acceptance criteria are quieter, but they are just as practical. They shape the agent’s attention before work begins and shape the review after work ends. They make “done” less dependent on style, confidence, or the agent’s own sense of completion.
The most useful criteria are not long. They are specific. They name the artifact, the evidence, the boundary, the validation, and the handoff state. They make room for uncertainty without rewarding bluffing. They let a task stop cleanly when the next step requires a person, a source, a credential, or a safer environment.
That is why acceptance criteria belong at the start of delegated work, not only at the end. They are the contract that lets the agent act as a bounded delegate instead of a busy assistant trying to satisfy an unstated expectation. When the finish line is visible, the work becomes easier to supervise, easier to verify, and easier to improve after the next run.
