AI Agent Acceptance Criteria Template

AI agent acceptance criteria define the observable conditions that must be true before a team accepts a bounded task, workflow, pilot, or release.

They turn phrases such as “works well,” “is safe,” or “is ready” into conditions a reviewer can verify against named evidence. Good criteria also protect the boundary around the work because they state what the agent must not do, which evidence is required, and which failures block acceptance even when the output looks useful.

Download the AI agent acceptance criteria template (Markdown)

The download contains 10 working sections plus reusable records for criteria, verification results, exceptions, acceptance decisions, and changes.

TL;DR

Useful AI agent acceptance criteria should:

1. Name the exact task, workflow, build, pilot, or release being judged.
2. State the decision the criteria inform and what that decision cannot authorize.
3. Define observable outcomes, scope, exclusions, and prohibited effects.
4. Give each criterion a stable ID, owner, source, verification method, evidence rule, and result type.
5. Cover quality, context, data, tools, authority, human review, security, reliability, cost, and audit where applicable.
6. Define measures, thresholds, denominators, samples, repetitions, and uncertainty before results exist.
7. Keep mandatory controls and prohibited outcomes outside aggregate scoring.
8. Count failed, blocked, invalid, not-run, retried, and manually corrected work.
9. Bind acceptance to the exact configuration and evidence reviewed.
10. Expire or reopen criteria after material changes or production failures.

Acceptance is not authorization. A passing result does not grant access, permit an action, accept residual risk, or approve production.

What Is an AI Agent Acceptance Criteria Template?

An AI agent acceptance criteria template is a reusable structure for writing the conditions and evidence used to decide whether a defined subject meets its requirements.

The subject might be one delegated task, a workflow implementation, a pilot, a release candidate, or a production change. That distinction matters because criteria for a single report cannot establish that a full workflow is safe for autonomous operation.

NIST’s AI RMF Core calls for elicited system requirements, documented test sets and metrics, deployment-like evaluation conditions, formal reporting, independent review, and documented limits on generalizability. The current TEVV-Athlon initial public draft describes a configurable assessment process for AI systems, including agentic systems. Both point to criteria that fit the system’s real purpose and operating conditions instead of a generic definition of done.

The template answers practical questions:

• What exact subject and version are we accepting?
• Which outcome must exist, and where will it be confirmed?
• Which paths, users, data, tools, authority, and effects are in scope?
• Which outcomes are prohibited regardless of the average score?
• What evidence proves each condition, and how trustworthy is that evidence?
• Who may verify, approve, reject, or grant an exception?
• Which changes make the result stale?

Acceptance Criteria, Requirements, Tests, and Evaluation

These records should link to one another without becoming duplicates.

• An AI agent requirements document states what the workflow and its controls must do.
• Acceptance criteria select the conditions that must be demonstrated for a named decision.
• An AI agent test plan defines the cases, environment, data, execution protocol, and evidence used to check those conditions.
• An AI agent evaluation plan defines the broader claims, populations, measures, graders, thresholds, and interpretation rules.
• Assurance decides whether combined evidence supports a scoped claim.
• An authorized owner records the release, pilot, or operating decision separately.

One requirement may have several acceptance criteria. For example, a requirement that the agent fail safely can produce separate criteria for a tool timeout, an uncertain external effect, a missing approval, and an unavailable human reviewer. Each criterion should point back to the requirement, risk, control, or decision that created it.

Tests produce observations. Evaluation interprets selected observations and other evidence. Acceptance compares the applicable result with the precommitted criteria for one decision boundary.

How to Use This AI Agent Acceptance Criteria Template

Write criteria before implementation or execution, while reviewers can still narrow scope and resolve disagreements. Start from an approved objective, requirements baseline, risk record, and named decision owner. If those inputs are missing, record the gap rather than inventing policy in the acceptance document.

The downloadable template has 10 working sections:

1. Acceptance record and decision boundary
2. Subject, configuration, scope, and baseline
3. Outcomes, deliverables, and completion states
4. Master criteria register and criterion syntax
5. Quality, performance, and population criteria
6. Context, data, tool, authority, and security criteria
7. Failure, recovery, human-work, and operating criteria
8. Verification, evidence, and result accounting
9. Exceptions and acceptance decision
10. Production checks, revalidation, expiry, and change

Treat the document as a versioned record. Its status does not authorize test execution, production access, or any consequential operation. Record separate authenticated execution authority bound to the exact plan, system, identities, tenants, data, tools, effects, limits, and expiry. Then check current technical authorization at every operation.

1. Name the Acceptance Decision

Start with a sentence that a reviewer can act on.

Weak:

Decide whether the support agent is ready.

Bounded:

Decide whether release R-31 may enter a 14-day internal pilot for English-language refund drafts under $500, using synthetic and approved masked records, with a human approval required before every send.

Record explicit non-decisions too. The example does not approve autonomous sends, other languages, larger refunds, outside customers, or production data that was not part of the approved evaluation.

Name the accountable owner, required reviewers, evidence cutoff, expiry, and policy that governs the decision. Separate the person who builds the system from an independent reviewer when risk or policy requires it.

2. Freeze the Subject and Its Boundary

Acceptance applies to an exact subject, not a product name or mutable alias. Record stable versions or digests for:

• Agent definition and orchestration
• Model deployment and settings
• System and developer instructions
• Published Knowledge and Skills
• Prepared working Memory state
• Context routes and retrieval indexes
• Tools, schemas, and integrations
• Identity, permissions, approvals, and limits
• Runtime, sandbox, network, and persistence
• Monitoring, evidence, and grader configuration

State the users, tenants, environments, tasks, languages, data classes, tools, operations, destinations, and external effects in scope. Add explicit exclusions and assumptions. If a mutable component changes after verification, the acceptance owner needs an impact review before reusing the result.

For Alignbase-managed context, permissions govern repository access. Always routes independently govern automatic delivery and do not grant repository permission. A listed Resource version does not pin a route or prove host injection. Artifacts and messages have no instruction authority, Memory is working recall, and MCP tool results are Runtime context.

3. Write Observable Criteria

Each criterion should describe one observable condition.

Use this form:

Given [preconditions], when [trigger or action], then [observable result] within [limit], verified by [authoritative evidence].

Examples:

• Given a verified account and current refund policy, when the agent drafts a refund under $500, then the draft cites the applicable policy section and contains no unsupported amount, verified by the case record and policy version.
• Given an expired approval, when the agent attempts to send a message, then the send gateway denies the operation before any external effect, verified by the gateway decision and destination state.
• Given a target-system timeout after submission, when the outcome cannot be confirmed, then the workflow performs no blind retry and creates a reconciliation item within 60 seconds.

Avoid adjectives without measures. “Accurate,” “fast,” “secure,” “helpful,” and “appropriate” need a method and threshold. Avoid combining unrelated conditions with “and” because one half may pass while the other fails.

Give every criterion a stable ID, source, owner, priority, verification method, evidence source, blocker status, and revalidation trigger. Define pass, fail, blocked, invalid, and not-run outcomes before execution.

4. Separate Required Outcomes From Prohibited Outcomes

Positive criteria define the result the team needs. Negative criteria define effects that must never occur within the tested scope.

Required outcomes may include:

• A completed task confirmed in the authoritative system
• A correct draft with required citations and disclosures
• A valid handoff to a named queue
• A refusal or clarification when inputs are insufficient
• An audit record bound to the exact run and configuration

Prohibited outcomes may include:

• Cross-tenant reads or writes
• An external send without current approval
• Use of a forbidden tool, destination, or data field
• Exposure of credentials, authorization headers, secrets, or unnecessary personal data
• Execution after cancellation, revocation, expiry, or a stop signal

A prohibited outcome is an independent blocker. Do not let high task quality or a strong aggregate score offset it. State whether one occurrence fails the criterion, stops the run, triggers incident handling, or invalidates the wider decision.

Authorization criteria should verify that a trusted gateway, policy engine, tool adapter, or target system denies by default outside the approved scope. A model refusal is not an enforcement control. Include adversarial attempts to bypass the external check through prompts, altered parameters, delegated calls, retries, and direct tool invocation.

Bind each approval immutably to the principal, tenant, operation, parameters, target, policy, expiry, and unique nonce. Consume approval in one atomic transaction with the protected effect where the target supports it. Otherwise use a durable pending and committed protocol with target-side idempotency and reconciliation, and never blindly retry an unknown outcome. Test sequential and concurrent replay attempts.

Require an authenticated approver with current authority under the recorded policy version. Enforce proposer and approver separation where policy requires it, and fail closed when approver identity, authority, independence, or approval integrity is missing, expired, or unverifiable.

5. Cover the Whole Agent Workflow

Final-output criteria are necessary but incomplete because an agent can reach a plausible answer through an unsafe path.

Add applicable criteria for:

• Task completion and verified business outcome
• Factual, procedural, and policy correctness
• Required context, freshness, authority, conflicts, and excluded content
• Tool selection, parameters, side effects, and target-state reconciliation
• Identity, authorization, approval, delegation, and tenant isolation
• Data purpose, minimization, retention, deletion, and egress
• Prompt injection, unsafe retrieved content, Memory poisoning, and tool-result injection
• Reliability, timeout, retry, duplicate, cancellation, recovery, and rollback
• Human review quality, correction, queue time, escalation, and availability
• Latency, cost, rate, concurrency, and resource use
• Evidence completeness, provenance, access, retention, and deletion

The OWASP AI Agent Security Cheat Sheet recommends structured security testing before production and after material changes, explicit authorization for sensitive tools, human approval for high-impact actions, and adversarial testing across prompts, tools, Memory, retrieval, policies, and models. Convert the applicable controls into observable criteria instead of treating a security review as one yes-or-no row. Untrusted content cannot change authority, expand scope, authorize actions, select sensitive tools, or trigger data disclosure.

Use dedicated synthetic tenant or account pairs for cross-tenant criteria. Build a negative-test matrix for reads, writes, enumeration, forged tenant IDs, caches, retrieval indexes, queues, schedules, background jobs, child agents, and delegated access across every storage and execution path. Never probe an uninvolved tenant, user, account, or external system.

6. Define Measures and Thresholds Before Results

For each measured criterion, record the population, unit, numerator, denominator, sample rule, repetitions, uncertainty method, threshold, and stop rule.

State how to count:

• Passed and failed attempts
• Blocked and aborted work
• Invalid or corrupted runs
• Not-run cases
• Retries and duplicate submissions
• Rejected, escalated, or manually corrected outcomes

Do not remove inconvenient results after execution. If a run is invalid, keep it in the result record with a reason and owner. If a human correction turns a bad draft into a good outcome, report both the draft failure and the final corrected state.

Use segment thresholds where performance can differ by tenant, language, task, tool, risk class, or affected group. A fleet-wide average can hide a severe failure in a smaller population.

7. Choose Verification and Evidence

Name the verification method before work begins: inspection, deterministic check, controlled test, target-system confirmation, human review, statistical analysis, security assessment, or another governed method.

Evidence should record the tenant, principal, agent and integration identities, criterion and result IDs, exact configuration, context versions and bundle digest, route source and effective delivery mode, authorization outcome and policy version, time, environment, dataset and grader versions, target-state checks, provenance, and trust level where applicable.

Keep evidence stages distinct. Context compilation, response issuance, integration acknowledgment, host-confirmed injection, and model consumption are different claims. One does not prove the next. Record model consumption only from direct, authenticated attestation by a trusted integration or provider, including the evidence source and trust level. Record consumption as unknown otherwise. A tool response may not prove that a queued external effect completed, so use protected target-system state when the outcome matters.

Exclude credentials, authorization headers, secret values, private model reasoning, and unnecessary personal data. Treat prompt injections and other active content as untrusted data. Apply sink-specific sanitization, use structured logging, keep untrusted data out of control fields, and never interpolate it into shell commands. Encode for the exact Markdown, HTML, terminal, or dashboard context only after separating data from instructions.

A digest can show that bytes changed after an authenticated commitment. The canonical manifest should list every raw evidence object with its protected reference, immutable version, media type, byte size, digest, and approved hash algorithm. Bind the manifest digest, run ID, authenticated collector, and collection timestamp in a signed or immutable commitment created when evidence is collected. The commitment does not prove capture completeness, accuracy, authorization, provenance, or connection to the real run.

8. Handle Exceptions Without Rewriting the Criteria

An exception is a separate governed decision, not a quiet edit to make a result pass.

Record:

• Criterion and evidence affected
• Reason and decision impact
• Governing policy and authorized exception role
• Compensating controls
• Exact scope, conditions, owner, and expiry
• Independent review and separation-of-duties result
• Follow-up action and revalidation date

The criterion author cannot approve an exception where policy requires independence. A mandatory legal, security, privacy, or safety control can follow only its authorized exemption or risk-acceptance path. Never relabel a failed or not-run criterion as not applicable after seeing results without a new version and review.

9. Make the Acceptance Decision Traceable

The decision record should bind:

• Exact subject and configuration
• Criteria version and result set
• Evidence cutoff
• Failed, blocked, invalid, and not-run criteria
• Prohibited outcomes and mandatory blockers
• Open defects, incidents, gaps, and assumptions
• Conditions, limits, expiry, and revalidation triggers
• Named decision owner and authenticated decision reference

An accepted or conditionally accepted disposition is invalid when decision-time authorization is denied, a mandatory blocker or prohibited outcome remains, or required evidence is missing. Conditions may address only findings the governing policy permits the decision owner to defer.

Possible dispositions include accepted for the stated scope, accepted with governed conditions, rejected, or insufficient evidence. “Accepted with conditions” cannot override a mandatory blocker unless the governing policy explicitly allows an exception and the authorized role records it.

Meeting criteria does not prove the agent is safe or useful outside the tested population and conditions. The UK’s AI assurance guidance treats assurance as measuring, evaluating, and communicating evidence about whether systems meet relevant criteria. Acceptance should preserve the same boundary between evidence and the decision made from it.

10. Revalidate After Change and in Production

Acceptance expires when the subject or operating conditions change enough to affect the result. Define triggers for changes to:

• Model, settings, instructions, Knowledge, Skills, or Memory behavior
• Routes, retrieval indexes, tools, schemas, permissions, or approval policy
• Runtime, dependencies, network, persistence, or evidence capture
• Users, tenants, tasks, languages, data, destinations, or effect limits
• Criteria, datasets, graders, measures, thresholds, or sampling
• Law, policy, contracts, incidents, or known attack methods

Production monitoring should reuse the same definitions where possible. A criterion such as “no unapproved sends” needs a production signal, owner, alert, response target, and stop action. Production failures should create incident records and, after safe review, regression cases.

Do not keep an acceptance result alive through an unchecked material change. Record the impact review, reopen affected criteria, run the required verification, and issue a new decision.

Common Acceptance Criteria Mistakes

Watch for these defects:

• The subject is a mutable product name rather than an exact release or task.
• Criteria describe activities, such as “review security,” instead of observable results.
• Only the final answer is checked, while tool calls and external effects are ignored.
• Averages hide a prohibited action or failed mandatory control.
• The denominator excludes retries, corrections, or blocked work.
• Evidence proves issuance but is described as injection or consumption.
• The same person writes, verifies, excepts, and accepts every high-risk criterion.
• Criteria change after the team sees a failure.
• Acceptance is treated as permission to execute or approval for production.

The template makes these choices visible before work begins, which gives builders, reviewers, and decision owners one definition of what must be proven.

Use the Template as a Versioned Contract

Download the AI agent acceptance criteria template, assign stable IDs, and keep it with the exact requirements, tests, evaluation results, evidence references, exceptions, and decisions it governs.

Update the document when the subject, decision, criteria, evidence, or operating scope changes. Preserve prior versions because later reviews need to know which conditions applied when the team accepted or rejected the work.