Field notes. John Arndt, Soxoa. Published .
Before you hire someone to put an AI agent into your business, ask them to show you a test it failed. Then ask what changed because of that failure.
Jon Matzner made a useful point: an AI expert should be able to show evaluations from a system they have put into a business and explain what they learned. I would bring that question to the first call, including a call with Soxoa.
You do not need to read code to assess the answer. You need to understand the work being tested, what counted as success, what actually happened, and who decided it was good enough.
What an eval should tell you
An evaluation, usually shortened to eval, tests an AI system on defined tasks against explicit success criteria. For a business workflow, the useful question is whether it completes the right work, with the right information and permissions, and stops when it needs a person.
A convincing answer in a chat window leaves plenty untested. If an agent says it updated a record, the test should check the record. If it needs approval before sending something, the test should establish what happens when approval is missing or refused.
Ask for five pieces of evidence
Ask the builder to walk you through one recent evaluation. A redacted record or a controlled demonstration can protect a customer's information while still showing how the work was judged. These are the things I would look for.
The cases and where they came from
Which inputs represent normal work? Which cover missing information, unusual requests, and previous failures? Ask whether the examples are synthetic, customer-approved, or drawn from production. Each can be useful; the label tells you what the result supports.
The rule for passing
What must be correct, and which mistakes block release? An invented amount, an unauthorized message, and a clumsy sentence have different consequences. Ask who set the criteria and whether the person who owns the workflow agrees with them.
The actual run and its failures
Request a dated result tied to the version tested, including failed cases. Ask whether tools and integrations were real or simulated, and whether repeated runs behaved consistently. A model saying its own answer looks correct is a separate claim from a check of the resulting record or action.
The change the result caused
Did the team change the prompt, restrict an action, improve the source material, or add a human review step? Ask to see the rerun. Sometimes the right response is to narrow the assignment or leave that part of the work manual.
The owner after launch
Who reviews real failures, maintains the cases, and reruns them when a model, prompt, tool, or business rule changes? Your team should receive the instructions and access needed to use the tests, with a named person responsible for deciding what happens next.
A missing purchase order is a test case
Suppose an agent prepares invoices for finance review. A clean invoice is the easy case. The test set should also include an invoice without a purchase order, a duplicate, conflicting totals, and text inside the document telling the agent to ignore approval rules.
Write the expected behavior before running those cases. The missing purchase order goes to a reviewer. The duplicate is flagged. Conflicting totals remain unresolved. Instructions embedded in an invoice do not authorize payment. The test checks that the agent respects those boundaries and that the review queue or downstream record reflects what it actually did.
A single accuracy percentage can conceal the failure that matters most. Look at the kinds of errors, their consequences, and the review effort required. Include time spent correcting the output when deciding whether the workflow helps.
One test that changed our own product
During Soxoa Studio validation on October 10, 2026, we checked whether the live voice provider greeted a caller who had not spoken yet. It did not proactively greet in two quiet-start checks. That matters because a person can reasonably wait for the guide to begin.
The application was changed to play a separately verified opening and then hand off to live conversation. The opening audio was decoded and transcribed to check its content. Local browser checks covered complete playback, interruption, and closing during the opening, using simulated live-call transport.
Those checks establish specific things. They do not turn the original provider failures into passes, establish physical microphone behavior, or measure reliability across a full conversation. This is a dated validation example from our own product, with synthetic inputs, rather than a customer outcome or a fresh evaluation of today's release.
Inspect the published test-record excerpt. It preserves the failed observation, the subsequent opening checks, and their limits. That is the kind of record I want a buyer to be able to question.
Keep testing after the first release
Prelaunch cases give you a repeatable way to check known behavior. Production review tells you what real work exposed that those cases missed. Keep both. Add consequential failures to the test set and rerun it when the system changes.
For the engineering detail, Anthropic's guide to agent evaluations explains how to define tasks, grade outcomes, inspect runs, and account for variation between attempts. It also describes why automated evaluations belong alongside production monitoring and human review.
Bring this question to our first call
Ask us what we would test in your workflow, what should stay on a human path, and what evidence would make us stop. In an AI Build Sprint, the evaluation and handoff belong in the scope from the beginning. The people doing the work should understand the acceptance criteria and the decision they are being asked to make.
Bring one recurring task, an approved example, and the person responsible for its outcome to a strategy call. We can start by writing down what a useful result would have to prove.