What we found
"We will test it" is the vaguest line in a build plan. A buyer reading that line cannot tell what will be checked, who writes the checks, or what happens when the agent changes next month. We write our plans with the test cases named, so the answer is on the page before anyone builds anything.
The method below comes from two places. One is Anthropic's published account of how they test their own commerce agents, in The anatomy of effective commerce agents. Those are their practices on their own product, and we report them as theirs. The other is the way we checked a month-end close we built for Genesco Sports Enterprises, which runs live and does real money work every month.
A test here is one thing: a saved starting state, one message, and a graded end state. Everything else in this piece is detail about how to write those three parts.
What a test case looks like
A case builds the state directly and then appends one user message. The records already seen, what sits in the cart, the facts in memory, the changes staged but not committed: the case sets all of that up in code, adds the message, and grades what the system holds afterwards along with the reply that was rendered.
Anthropic gives a reason for working this way. In a run driven by a simulated user, the simulated user and the agent both drift, so a failure is hard to attribute to either one. A snapshot has one moving part.
Clean states test very little. A good case encodes the preconditions of failure, such as a messy history, a contradiction between two records, a partial period, or a fact that has gone stale. That is where agents break, so that is what the saved states should contain.
Coverage in Anthropic's account runs across core requests, at 50 to 100 cases per flow, plus context-dependent requests and memory, safety and brand cases such as injection and data access, interface correctness, and requests that need two capabilities at once.
Real incidents make the best cases. Anthropic has Product, Legal, Merchant Ops, Customer Care and Category Management write them, because those teams know what went wrong. In a company of thirty people, the writer is the person who does the work today and remembers the month everything went sideways. That is the same person we interview in Discovery.
Code checks before judgment calls
Most of what a test needs to check can be read by code. A code grader can read which tools were called and with what arguments, which screen or component came back, what the record holds after the turn, and which strings the reply has to contain or must never contain. It gives the same verdict every time, and it tells you what broke.
A rubric goes to a judge model only for the parts code cannot read, such as whether the explanation the agent gave matches what the agent actually did. Anthropic runs one judge call per dimension, returning a verdict and a reason, pinned to a model at temperature zero. A change to the judge or to the rubric invalidates every stored verdict, so the set gets re-run.
When a live run takes a route the case did not expect and the answer is still correct, widen the case to accept that route too. Pinning the case back to the one route you happened to observe turns an implementation detail into a requirement, and the next equally correct route fails a test that was never about the route.
Negative cases
Every positive case gets a negative one. For each case that asserts a component appeared, a skill loaded or a memory was written, there is a case in the same area that asserts the same thing did not happen. A refusal case gets a counterpart the agent is supposed to serve, so an agent that refuses everything fails the set instead of scoring well on safety.
Negative cases cover two failure shapes: an agent that fires a tool it had no business firing, and an agent that has been tightened so far that it stops doing the job it was built for.
Poisoned fixtures live only in the test data. A listing or a message that carries an instruction to write something, to remember something, or a false claim, each one paired with a harmless twin in the same area so the agent has to tell them apart.
When the tests run
The trigger is a change to the system. Every merge to the agent, a skill, a tool description or a fixture runs the regression set, each case over several trials. Changing one flow runs that flow's cases against the previous run as the baseline. Choosing or upgrading a model runs everything. In production, a judged sample of live traffic goes through the same rubrics.
Read the results as a set of failures rather than as a score. Anthropic compares which cases failed between runs, because a topline moving a point between runs is noise.
Genesco's month-end reconciliation
A month-end reconciliation that took the CFO about 4 days by hand now runs in about 60 seconds. Every month, the finance team rebuilt job-profitability numbers by hand from Sage 50 exports. We built a web app that ingests the exports, computes the job totals, pre-fills the figures the rules allow, hands back a clean workbook for the judgment calls, and produces the final reconciled master. We wrote about where the review sits in that flow in the human review step in an automated finance workflow.
That app does its arithmetic with fixed rules and does not call a model, so its tests are the plain version of everything above. A saved set of exports goes in, a known workbook comes out, and the comparison is exact.
The cases that earned their place were the awkward months: a period that closed partway, a job that moved between categories, and a correction that arrived after the file had already been processed. Those came from the finance team's memory of real closes, which is why one of the first questions we ask in a build is what went wrong last year.
Mark Tatum, Genesco's CFO, described the result this way: "Every month our team burned hours rebuilding job-profitability numbers from Sage by hand. Plainpath built us a tool that does the heavy lifting and leaves us just the judgment calls. It has saved us real time and headaches, and they were quick to adjust it when we asked."
These figures are Genesco's, they are public with their permission, and they cover one company and one process. A close where judgment enters at every step compresses far less.
The plain take
A build plan can answer "we will test it" in one page, listing the saved cases, who wrote them, what code grades, what a judge grades, and when the set runs. A build with no test list and no owner is the pattern we wrote about in why most AI pilots fail. We write that page into the build plan that comes out of Discovery.
Frequently asked questions
How do you test an AI agent before it goes live?
Write saved test cases. Each case sets up a starting state in code, adds one user message, and grades the state and the reply afterwards. Code checks read which tools ran, what the records hold and which strings appeared. A judge model grades only what code cannot read. The set runs on every change to the agent.
How many test cases does an agent need?
Anthropic's account of testing their commerce agents puts coverage for a core flow at 50 to 100 cases per flow, plus cases for memory, safety, interface correctness and requests that need two capabilities at once. A smaller build needs fewer, and the number matters less than whether the awkward real cases are in the set.
Why not test with a simulated user having a conversation with the agent?
Anthropic's reason is attribution. In a simulated-user run, the simulated user and the agent both drift, so a failed run does not tell you which part broke. A saved state with one message has one moving part.
What is a negative test case?
A case that asserts something did not happen. For every case checking that a component appeared, a skill loaded or a memory was written, there is a matching case checking the same thing stayed absent. A refusal case gets a counterpart the agent should serve, so an agent that refuses everything fails.
Who writes the test cases, us or you?
The people who do the work write most of them, because they remember the real incidents. We turn those into saved cases and the graders, and the list goes into the build plan before the build starts.
References
- The anatomy of effective commerce agents — Anthropic
- The anatomy of effective commerce agents — Anthropic
- The anatomy of effective commerce agents — Anthropic
- The anatomy of effective commerce agents — Anthropic
The plain take
A build plan can answer "we will test it" in one page, listing the saved cases, who wrote them, what code grades, what a judge grades, and when the set runs. We write that page into the build plan that comes out of Discovery.
If one of your processes looks like this, the free audit at /compass is where to start.