How to Write Acceptance Criteria an AI Agent Can Actually Verify

Acceptance criteria were invented for humans to read. A product manager wrote them, a developer interpreted them, and a QA tester checked the result against them, with three brains in the loop to catch the gaps. That worked because the slack between a vaguely worded criterion and a correctly built feature got absorbed by people who could ask a follow-up question. Hand the same criteria to an AI coding agent and the slack does not get absorbed. It gets built.

That is the shift almost nobody writing about acceptance criteria has caught up to. Every guide still teaches them as an agile artifact for aligning a team. The format advice is sound, Given-When-Then, testable, no implementation detail, and you should follow it. But the stakes changed. When the thing reading your criteria is an agent that will write the code, run the tests, and declare the feature done without a single follow-up question, your acceptance criteria stop being a communication tool and become the specification the agent builds against and the only standard it checks itself by. Write them loosely and the agent will confidently ship you the wrong thing, on time.

#What acceptance criteria are, and what changed

Start with the definition the whole industry agrees on. Acceptance criteria are a set of specific, testable conditions that define when a feature is done and working as intended. They describe the what, not the how, and each one passes or fails with no middle state. Scrum Alliance puts the bar plainly: criteria must be clear to everyone involved, verifiable, and unable to be 50 percent complete. That has been the standard for two decades.

Here is what changed. In the human workflow, acceptance criteria were one input among many. The developer also had hallway conversations, Slack threads, a shared sense of the product, and the judgment to notice when a criterion did not quite make sense. An AI agent has none of that. It has the prompt, the codebase, and the criteria you gave it. Whatever you left implicit, it fills in by guessing, and it guesses in the direction of the shortest path to something that looks done.

So the criteria carry more weight than they ever did. They are no longer the summary of an agreement reached by people. They are the agreement. This is why the loop matters: you cannot verify a feature against criteria you never wrote, and an agent cannot self-correct toward a target it was never given. As we have argued in planning in the age of capable coding agents, the more the agent does on its own, the more the upfront definition decides the outcome.

#The format an agent can verify

The most agent-friendly format is the one the industry already recommends for development: Given-When-Then. It maps directly onto how an agent reasons, a starting state, an action, an expected result, which is also exactly the shape of a test.

Given an unauthenticated user on the login page, When they submit a valid email and password, Then they are redirected to /dashboard.

Each clause is a checkable fact. The agent can set up the precondition, perform the action, and assert the outcome. There is no interpretation left to do. Compare that with the kind of criterion that reads fine to a human and strands an agent:

Vague: "Login should work properly and handle errors gracefully."

Verifiable: "Given a user submits an email with no @ symbol, When they click sign in, Then the form shows the inline message 'Enter a valid email address' and does not call the login endpoint. Given five failed attempts within ten minutes, When a sixth is made, Then the account is locked and the response is 'Too many attempts, try again in 5 minutes.'"

The first one is not wrong. It is just unverifiable. "Properly" and "gracefully" are not conditions an agent can test, so it will ship a happy-path login, mark the story done, and you will discover what "gracefully" meant to it when a user with a typo'd email gets a blank screen in production. The second version states the exact error text, the exact threshold, and the exact behavior. There is nothing left to guess, which means there is nothing left to get wrong.

The principles behind the good version are the ones every solid guide repeats, and they happen to be precisely what an agent needs. Be specific and measurable: name the exact message, the exact limit, the exact state. Make every criterion pass-or-fail. Cover the edge cases, not just the happy path, because the happy path is the part the agent was always going to get right. The difference now is that these are not style preferences for a tidy backlog. They are the line between a feature an agent can verify and one it can only pretend to.

#The trap: criteria that sound testable but aren't

There is a failure mode that catches experienced people, because the criterion looks rigorous. "The page must load quickly." "The API should handle a reasonable load." "Search results should be relevant." These have the grammar of acceptance criteria and none of the substance. Quickly, reasonable, and relevant are not values an agent can check against, so it treats them as satisfied by default. The criterion was decorative.

The fix is to ask one question of every criterion before you hand it over: could two people, or two agents, disagree about whether this passed? If yes, it is not done. "The page must load quickly" fails the test. "The dashboard's largest contentful paint must be under 2.5 seconds on a throttled 4G connection" passes it, because there is a number and a condition and no room to argue. This is also the honest limitation worth stating: writing criteria this tight is real work, and it is work that happens before you get to see anything run. That front-loading is the trade. You pay in specification time now, or you pay in production surprises and regeneration loops later, and the second bill is always larger.

The other limit to be clear about: acceptance criteria check whether the feature does what you said, not whether what you said was right. If you specify the wrong behavior precisely, the agent will build the wrong behavior precisely and verify it as done. The criteria are only as good as the intent behind them, which is why the writing of them is the part that still needs you.

#Where this fits in the loop

This is the exact problem BrainGrid was built around, and it sits one step before the agent ever runs. You describe a feature in plain language, and the Planning Agent does the part most people skip: it asks the clarifying questions a senior engineer would, surfaces the edge cases you did not name, and turns your intent into a requirement with explicit, testable acceptance criteria. You are not staring at a blank Given-When-Then template hoping you remembered the failure modes. You are reviewing and correcting a draft that already pushed on the ambiguity.

Those criteria then do double duty. They are the specification your coding agent builds against, whether you hand them to Claude Code, Cursor, or Codex in your own repo or let the Builder Agent run in a managed sandbox. And they are the checklist verification runs at the end: every criterion is checked against the build, and the feature is not done until the evidence says it does what you meant. That is the whole point of writing them to be verifiable in the first place. As Scrum Alliance says, a criterion cannot be 50 percent complete, and now something other than a hopeful glance is enforcing that. This is the Verify step of the loop we cover across spec-driven development: Plan precisely, Build against the plan, Verify with evidence, repeat.

Strip away the agent and the tooling and the argument is older than any of it: a feature you cannot test against a clear standard was never really defined, you just felt like it was. Acceptance criteria have always been how teams turn a fuzzy intent into a checkable one. What changed is who is reading them and how literally. Write them for a machine that takes you at your exact word, and a strange thing happens. They get better for the humans too.

#FAQ

#What format is used for acceptance criteria?

The two most common formats are Given-When-Then and a simple checklist. Given-When-Then (the BDD format) states a precondition, an action, and an expected outcome, for example "Given an unauthenticated user, When they submit valid credentials, Then they are redirected to the dashboard." It is the most structured option and maps directly onto how a test is written, which makes it ideal for development and for AI agents. A plain checklist of testable statements works well for simpler features and non-developers. Either is fine as long as every line is specific and passes or fails with no middle state.

#What are good acceptance criteria?

Good acceptance criteria are clear, testable, and unambiguous. Each one is specific and measurable (it names exact values, messages, and states rather than words like "quickly" or "properly"), it can only pass or fail, it focuses on the user's experience rather than the implementation, and it covers edge cases instead of just the happy path. The practical test: if two people could disagree about whether a criterion was met, it is not specific enough yet. That same test is what makes criteria usable by an AI coding agent, which has no judgment to fall back on when wording is loose.

#What are the three C's of acceptance criteria?

The three C's, Card, Conversation, and Confirmation, come from the user story model. The Card is the short written story, the Conversation is the discussion that fleshes out the details, and the Confirmation is the acceptance criteria that confirm when the story is done. In an AI-assisted workflow the Conversation increasingly happens up front with a planning agent that asks clarifying questions, and the Confirmation becomes the criteria the build is verified against, but the underlying idea is unchanged: a story is not complete until there is an agreed, checkable definition of done.

#What are examples of acceptance criteria?

A clear example for a login feature: "Given a registered user enters a valid email and password, When they click sign in, Then they are redirected to /dashboard." For the failure path: "Given a user enters an email without an @ symbol, When they click sign in, Then an inline error reads 'Enter a valid email address' and no login request is sent." For a limit: "Given five failed attempts in ten minutes, When a sixth is made, Then the account locks for five minutes." Notice each one names exact behavior and exact text, so there is nothing left to interpret, which is what makes them verifiable by a person or an agent.

#What is the difference between acceptance criteria and a definition of done?

Acceptance criteria are specific to one feature or user story: they define what that particular thing must do to be accepted. A definition of done is a general checklist that applies to every story (for example, code reviewed, tests passing, documentation updated, deployed to staging). You need both. Acceptance criteria tell you whether the right thing was built; the definition of done tells you whether it was built to your team's standard of complete. For an AI agent, the acceptance criteria are what it verifies the behavior against, while the definition of done captures the surrounding quality bar.

BrainGrid turns your plain-language idea into testable acceptance criteria your coding agent builds against and is verified by, so "done" means proven, not promised. Try it at braingrid.ai.