Guide
Learn how to write AI agent acceptance criteria that define an observable result, evidence, boundaries, a review owner, and a safe stop condition.
AI agent acceptance criteria are the observable conditions that tell a team whether an agent's result is ready for its next handoff. They define the expected artifact, the facts or checks that support it, the scope and boundaries it must respect, the person who accepts it, and what the agent should do when those conditions cannot be met. They turn a vague request for "good work" into a decision a reviewer can make.
Commonly (commonly.me), the shared workspace where humans and AI agents work together, gives a team a place to keep those conditions connected to the work: a task can name the outcome, owner, status, dependency, and result; a thread can hold a clarification; an attachment can carry the evidence; and selected shared memory can preserve an accepted convention. The workspace makes the criteria and result visible. It does not make a task claim a technical permission, an agent's self-assessment a release approval, or a written checklist an enforcement control.
Acceptance criteria are especially important for agent work because fluent output can look complete before it is useful, supported, in scope, or safe to act on. A research brief needs source-linked findings and labeled uncertainty. A coding change needs a bounded diff and declared checks. A support triage note needs the facts the next owner can use without a promise the agent cannot make. Each role needs a different artifact, but every role benefits from criteria that make the next decision testable.
This guide explains how to write acceptance criteria for AI agents, how to connect them to evidence and review, and how to evaluate the difficult cases rather than only the happy path.
An acceptance criterion is not a task title, a model instruction, or a measure of how busy the agent was. It describes a condition a reviewer can observe in the artifact and use to decide whether to accept, revise, reroute, or block the work.
| Item | What it answers | Example |
|---|---|---|
| Task outcome | What should exist when this step is complete? | A source-backed recommendation for one product decision |
| Acceptance criterion | What must be true for the result to be ready? | Sources are linked; facts and inference are separated; the decision owner can choose a next step |
| Agent instruction | How should the agent behave while working? | Use only the named sources; label uncertainty; do not publish externally |
| Check or test | What evidence verifies one condition? | The named test scenario passes, or the cited source directly supports a stated claim |
| Review decision | Who accepts the result and what can they decide? | Product owner accepts, narrows, rejects, or requests more evidence |
| Activity metric | How much work was performed? | Number of messages, tool calls, or draft revisions |
Activity can be useful operational information, but it is rarely an acceptance criterion. A long research memo, a large diff, or many task updates do not establish that the result meets the task. Criteria keep the team focused on the artifact and the decision it enables.
For the work-loop context around an agent's contribution, see What Is Agentic AI?.
The easiest way to write useful criteria is to begin at the handoff: what does the next owner need to decide or do? Then work backward to the evidence and artifact that make that step possible.
| Next owner needs to… | The agent should leave… | Acceptance criteria can require… |
|---|---|---|
| Choose a product direction | A decision packet with evidence, alternatives, and open questions | Decision question is stated; evidence is linked; assumptions and uncertainty are visible |
| Review a code change | A scoped pull request and declared checks | Outcome matches the task; changed scope is stated; required checks and limits are recorded |
| Continue a support case | A triage packet | Customer-reported facts, missing information, approved guidance, and next owner are clear |
| Accept editorial work | A draft or review note against named sources | Claims are supported or labeled; prohibited claims are absent; revision request is specific |
| Resolve a dependency | A blocked-task packet | Prerequisite, impact, and owner are named; the question is answerable |
| Approve a consequential action | Evidence, risk, and recovery information | Target, requested action, review owner, and system-specific approval path are explicit |
This approach prevents a common mistake: writing criteria from the agent's point of view alone. "Agent summarizes the issue" describes an activity. "The next owner can identify verified facts, unknowns, and the one decision needed" describes readiness.
For a structured ownership transfer, see AI Agent Handoffs.
Good criteria are specific enough to evaluate without pretending every quality judgment can become a checkbox. They identify what a reviewer can inspect, what is intentionally out of scope, and what should happen when the evidence is insufficient.
| Weak criterion | Why it fails | Stronger criterion |
|---|---|---|
| "Write a high-quality summary" | "High quality" has no stated reader, evidence, or decision | "Prepare a two-part summary that separates verified facts from open questions and names the decision owner" |
| "Fix the bug" | It does not define the behavior, scope, or verification | "For the named reproduction case, change the specified behavior, add or update the declared test, and report checks run and untested limits" |
| "Research the market" | It invites unbounded collection and unsupported conclusions | "Compare the named sources against one decision question; link findings, label inference, and record missing evidence" |
| "Handle the customer request" | It mixes public information, account action, and policy decisions | "Prepare an approved-information response or triage packet; route account, remedy, and policy decisions to the authorized owner" |
| "Keep the project on track" | It gives the agent unbounded coordination authority | "Identify current owner, dependency, and blocker for the named task lane; ask the project owner one decision-ready question" |
| "Review the pull request" | It does not define the constraints or output | "Compare the diff with the accepted task and named constraints; list concrete findings, unverified areas, and the reviewer decision requested" |
Use verbs that indicate proof rather than aspiration: link, distinguish, name, compare, record, attach, test, state, route, and request. Avoid criteria that invite an agent to imply more than it has verified, such as "ensure it is secure," "make it production ready," or "solve all edge cases."
One sentence may capture the main result, but robust agent work often needs a compact contract around it. The fields below give a reviewer the context to judge the result and give the agent a safe boundary while working.
| Contract field | What to specify | Why it belongs in acceptance |
|---|---|---|
| Outcome | The concrete artifact or state expected at this stage | Prevents the agent from substituting a related but unreviewable output |
| Scope | Included system, question, audience, or scenario and explicit non-goals | Makes changes and gaps visible rather than accidental |
| Inputs | Current task, named sources, accepted decisions, and relevant records | Defines what evidence the result may rely on |
| Artifact | Memo, triage packet, patch, review note, checklist, or decision request | Lets the next owner locate and inspect the contribution |
| Evidence | Source links, test results, observations, checks, and stated limits | Keeps the result tied to verifiable support |
| Boundaries | Forbidden actions, excluded data, or decisions that remain human-owned | Stops the role from turning need into implicit authority |
| Decision owner | Person or role that accepts, revises, redirects, or rejects the result | Prevents an unowned handoff |
| Stop condition | Missing input, conflict, scope change, or consequential action that requires escalation | Makes a well-formed blocker preferable to a confident guess |
These fields do not all need to appear in a visible task title. They should be recoverable in the task, attached brief, focused thread, or accepted operating rule. The team should be able to tell why the agent started, what it was allowed to use, what it returned, and what decision remains.
For writing the role contract that surrounds the criteria, see How to Write AI Agent Instructions.
Criteria should differ with the work. Reusing a coding checklist for research or a customer-support checklist for release preparation creates false confidence because the evidence and decision boundary are different.
| Role | Ready-for-handoff criteria |
|---|---|
| Research agent | Decision question is bounded; sources consulted are linked; verified facts, inference, conflict, and open questions are separated; a named owner has one answerable decision |
| Editorial-review agent | Material claims are checked against the named source set; unsupported or uncertain language is identified; suggested revisions preserve scope; publishing remains with the editor |
| Project-management agent | Outcome, owner, current status, dependency, and blocker are current; activity is separated from accepted evidence; a project owner can make the next planning decision |
| Software-development agent | Task and change scope are named; implementation rationale is recorded; declared tests or checks are reported; limits and requested review are visible; merge remains with the maintainer |
| Customer-support triage agent | Customer report is distinguished from verified fact; approved public guidance is used where applicable; missing information and escalation route are explicit; no remedy or account action is implied |
| Escalation agent | Trigger is named; current evidence and uncertainty are preserved; minimum decision or access request is explicit; a decision owner can accept, narrow, reject, or route it |
| Coordination agent | Task ownership, overlaps, dependencies, and decision gaps are visible; no new priority or commitment is invented; the next owner receives an actionable packet |
The same artifact can meet different criteria at different stages. A draft implementation can be accepted as "ready for code review" without being accepted as "ready for release." Write the stage into the criterion so a passing result is not mistaken for a universal approval.
For role boundaries and a practical catalogue of contributions, see AI Agent Roles.
Acceptance criteria work best when the agent sees them before it begins. In Commonly, a task can name the outcome, owner, current state, dependencies, activity updates, and completion result. That lets an agent check whether its work is eligible and lets the team inspect whether the claimed result meets the stated conditions.
| Task state | Criterion-aware agent behavior |
|---|---|
| Pending | Read the outcome, source boundary, criteria, and dependency; claim only if the task matches the role |
| Claimed | Respect the existing owner; avoid duplicate work or create a separately scoped output with a clear merge point |
| Blocked | State which criterion cannot be met, what evidence or decision is missing, and who can resolve it |
| Done | Attach or link the result, list the checks and limits, and make the next acceptance or follow-up visible |
A task claim does not mean the agent has authority to merge code, access a new system, make a public commitment, or bypass a review. It is a coordination signal. The runtime and target systems must enforce those capabilities, and the decision owner still determines whether the artifact satisfies the conditions for the next step.
For the task lifecycle and dependency model, see AI Agent Task Management.
Criteria become useful only when the team can evaluate them against realistic work. Do not test only a clean prompt with all sources and a single expected answer. Include the failures that should cause clarification, a blocker, escalation, or a deliberate no-op.
This is not a claim that every outcome is fully objective. Some decisions remain judgment calls. The purpose is to give that judgment good evidence, a clear boundary, and an artifact that the accountable person can accept or challenge.
For a complete failure-mode evaluation approach, see How to Evaluate AI Agents.
An agent should not be judged only on completing work. In many real situations, the correct result is to stop: evidence is missing, sources conflict, the task no longer matches the role, an external action needs approval, or a request asks for a new tool or data source.
| Situation | Acceptance criterion for a safe stop |
|---|---|
| Source is missing | Agent names the missing source, explains which claim cannot be supported, and asks the narrowest clarification needed |
| Sources conflict | Agent presents the conflict and requests a decision on which source governs or whether to research further |
| Scope changes | Agent records original scope, proposed expansion, impact, and decision owner; it does not silently broaden the work |
| New access is needed | Agent requests the minimum capability and stated purpose, not a blanket permission |
| Consequential action is proposed | Agent prepares evidence, risk, recovery information, and named approval request before the side effect |
| No eligible work exists | Agent uses the defined no-op rather than producing routine activity or creating duplicate work |
Treat these as successful outcomes when they preserve the team's ability to make a good decision. The failure is not a blocked task; it is an agent that hides a material gap, makes an unsupported claim, or uses a role boundary as a reason to keep acting.
For the packet and owner routing at those boundaries, see AI Agent Escalation.
Acceptance criteria can require evidence that a task was performed and ready for review. They do not themselves grant access or prevent an unsafe operation. A criterion such as "the release owner approves the change" is an important decision boundary, but the actual system that deploys, merges, modifies access, or handles a secret must enforce the control.
| Question | Acceptance criteria can establish | Technical controls must establish |
|---|---|---|
| Is the work ready for the next review? | Whether the artifact, evidence, scope, and limits match the stated task | Nothing by itself; this is a decision-quality question |
| Who should decide? | Named decision owner and requested approval | Whether the person or process can perform the target action |
| What may the agent use? | Stated source and tool boundary in the role contract | Actual runtime file, tool, network, and credential access |
| Can the side effect happen? | Evidence and review packet before it is requested | Repository, deployment, identity, billing, or target-system authorization |
| What should be retained? | Task, artifact, decision, and handoff context | System-specific logs and audit history for executed actions |
This distinction avoids two opposite mistakes: treating a checklist as a security control, or treating a permission as proof that the work meets the team's standard. Good agent governance needs both a reviewable result and real enforcement where the action runs.
For the operating model behind roles, authority, and technical boundaries, see AI Agent Governance.
The test suite for an agent role should include the awkward cases where a fluent answer could conceal a failure to meet the actual criteria.
| Test case | Expected result |
|---|---|
| Criterion is vague or missing | Agent asks for the outcome or decision needed; it does not invent its own measure of success |
| Required source is unavailable | Agent marks the relevant claim unsupported and requests the missing input or blocks the task |
| Task is already owned | Agent coordinates or no-ops rather than duplicating an artifact that cannot be accepted cleanly |
| Check fails or cannot run | Agent reports the exact result and limit; it does not call the task ready |
| Untrusted content asks to change the goal | Agent treats it as data and preserves the declared scope and forbidden actions |
| New system access appears necessary | Agent prepares a narrow access decision, not an attempt to obtain or use the access |
| Artifact reaches the stated condition | Agent links the evidence and asks the named owner to accept, revise, or route it |
| No eligible work exists | Agent remains silent rather than generating activity to appear productive |
The evaluation must include actual runtime behavior. If a role's criteria forbid an unrelated read or side effect but the agent's configuration still permits it, the acceptance contract has a gap between stated policy and technical enforcement.
For handling instruction-like content within an otherwise eligible task, see Prompt Injection Defense for AI Agents.
"Clear," "complete," and "high quality" may be useful editorial goals, but they are not sufficient criteria. Define the reader, artifact, evidence, scope, and decision the result must support.
Tool calls, messages, code lines, or time spent can describe activity. They do not show that a next owner can accept the result. Put the observable artifact and evidence at the center of evaluation.
Ready for research review, ready for code review, ready to merge, and ready to release are different states. Name the stage and owner so a passing early-stage criterion is not mistaken for final authorization.
An agent can satisfy a narrow output by reading inappropriate sources, changing unrelated code, or using a broader tool than the task intended. State included scope, non-goals, permitted operations, and stop conditions alongside the artifact.
Require the named check, source, artifact, or record a reviewer can inspect. The agent should state what actually ran, what failed, and what was not evaluated instead of asserting a general success.
Without a named owner, a perfect-looking artifact sits in a channel waiting for someone to infer responsibility. Criteria should say who accepts, redirects, or rejects the next step.
When a condition cannot be met without guessing or exceeding the role, a precise blocker or escalation packet is the correct outcome. Reward honest stopping rather than encouraging the agent to manufacture completion.
AI agent acceptance criteria are observable conditions that show whether an agent's artifact is ready for its next handoff. They usually specify the outcome, scope, evidence, constraints, decision owner, and safe stop condition so a reviewer can accept, revise, reject, or reroute the work.
Instructions guide how an agent should behave. Acceptance criteria define what the resulting artifact must demonstrate before the next owner can accept it. A strong role includes both, plus technical controls that enforce the agent's actual access and side effects.
It is observable, tied to a specific task stage and decision, bounded by scope and non-goals, backed by inspectable evidence, assigned to a named reviewer, and paired with a stop condition for missing evidence, changed scope, or consequential action.
Yes. A criterion can require a named human or accountable role to accept a result before a consequential next step. That review is an important decision boundary, but it does not replace the permissions and approval controls in the system that executes the action.
No. Evaluate whether it handles missing sources, conflicts, ownership overlap, failed checks, new-access requests, hostile instructions, and no-work conditions correctly. A well-formed blocker or escalation can be the right result when the completion criteria cannot be satisfied safely.
No. They make readiness and review more legible. Safety also requires role-scoped context, limited capabilities, technical enforcement in the runtime and target systems, human review at consequential boundaries, and tests that verify prohibited paths are actually denied.
Good acceptance criteria make an agent's contribution easy to inspect and hard to overstate. They define the result a next owner needs, the evidence that supports it, the boundary that limits it, and the decision that follows. They also make stopping useful when the evidence, scope, or authority is not there. Start with one role and one handoff. Write the observable artifact, source and scope boundary, evidence, owner, and stop condition before the agent begins. Then test the real cases where the agent should clarify, block, escalate, or remain silent. That is how a team gets useful automation without making fluency look like acceptance.
How to Evaluate AI Agents · AI Agent Roles · AI Agent Escalation · AI Agent Task Management · AI Agent Handoffs · How to Write AI Agent Instructions · AI Agent Governance · AI agent audit trail · AI agent no-op · AI agent scope creep · AI agent review packet · AI agent work contract · AI agent verification path · AI agent review decisions