Docs / Testing, improving and debugging
Test an agent's behaviour
For deciding whether an agent is good enough to hand to colleagues, and then having the platform hold you to that decision.
What this is
You cannot test an agent by checking that its answer matches some text you wrote down in advance. Ask the invoice agent the same question twice and it will word the answer differently both times, and both times it can be completely right. Compare the words and you will fail a good agent for using a synonym, and pass a bad one that happened to phrase its nonsense the way you expected.
So you test something else. You write down what has to be true about how the agent behaved, and you check that instead.
- Did it call the invoice-comparison function before it wrote anything?
- Did the assessment name an actual clause?
- Did it invent a line item that was never in the finance system's response?
You can check all of those without caring which words it chose.
That is what a behaviour acceptance criterion is, a BAC:
A situation you put the agent in, plus a statement of what must be true about how it behaved in that situation. You pin it, and from then on it controls releases. A new version of the agent goes live only if every pinned criterion passes. Not most of them. Every one. A better average never overrides a single failure.
What it does
| A pass | Controls promotion. Every pinned BAC must pass for a new agent version to go live |
| A score | Ranks versions against each other. Never overrides a failure |
| Where they run | Off the live path. Nothing you test here activates anything |
| Tools | Execute for real, including anything that touches another system |
| Once pinned | Cannot be edited or deleted |
Example: five criteria for the invoice agent
Look at the last two. The criterion is about what must not happen. No invented line. No query raised on a clean invoice.
Those are the ones that catch the failures you did not think of in advance, and every agent should have at least one of them.
| The criterion | Kind |
|---|---|
| Given any invoice exception, the agent calls the invoice-comparison function before it registers anything | Invokes tool |
| The supplier query it registers names the invoice number, the purchase order number and the total value of the difference | Tool parameters contain |
| The assessment names a specific clause of the supplier contract rather than referring to the contract in general | Grounded in knowledge |
| The agent never states a line item, a quantity or a price that was not in the finance system's response | Does not hallucinate |
| Given an invoice that matches its purchase order exactly, the agent says so and registers no supplier query at all | Invokes tool |
The five kinds of failures
| What it checks | |
|---|---|
| Invokes tool | The agent actually called the thing it should have, or did not call the thing it should not have |
| Tool parameters contain | It called it with the right details in the request |
| Does not hallucinate | It stated nothing that was not in what came back |
| Stays in character | It behaved as the agent you configured, in tone and in scope |
| Grounded in knowledge | Its answer rests on your material rather than on what the model happens to know |
The first two are checked mechanically: the run either contains that call with those details or it does not. The last three are judged by a model reading the whole transcript against what the criterion says.
Immutable once pinned
You cannot edit a pinned criterion, and you cannot delete one.
The reason is the failure mode this replaces. Acceptance criteria kept in a document get softened. Somebody writes "the agent must never register a query without naming a clause" in January, and in March there is a release everybody wants and the criterion is quietly reworded to "the agent should generally reference the contract". Nobody decides to lower the bar. It just drifts.
Pinning removes that option. If a criterion is genuinely wrong, you write a new one and retire the old, and the retirement is recorded with the reason you gave. The bar can change, but only where somebody can see it happening.
How to do it
- Open the agent and go to the Testing tab.
- Press Add BAC. It sends a starter prompt into the Agent Builder docked on the left, so you describe the criterion in conversation rather than filling in a form.
- Run it as a candidate first. An unpinned candidate runs without joining the set that controls releases, so you can find out whether the criterion means what you thought before it starts blocking anything. Most criteria need a rewording at this point.
- Pin it. Now it controls promotion, and now it is fixed.
- Press Run all whenever you want the whole set.
Reading the result
The result is not a simple pass rate.
- Each criterion runs several times, and the figure you get accounts for how few runs that is.
- Five passes out of five is treated very differently from fifty out of fifty, and the number reports its own uncertainty rather than hiding it behind "100%".
- At the default settings, a judged criterion has to pass every single time out of five.
That is intentionally strict. A criterion that passes four times in five describes an agent that gets one invoice in five wrong.
Experimental runs do not count. If you override something for a run, most often swapping the model to see what a cheaper one does, that run is marked experimental. It can never promote a version, and it is left out of the health chart. It is badged in the runs table with the reason it was overridden. See See and control what it costs for why you would do this.
The set is recorded on every promotion. You can go back months later and see exactly which criteria a given version passed, even though the set has grown since.
Testing a conversation rather than one answer
A single question and a single answer is not a fair test of an agent people talk to. The first answer is usually fine. What goes wrong is the third, fiftieth, or hundredth one.
So Mindset runs a stand-in user: a second model playing a person, given a persona and a goal, which replies to your agent turn after turn as if it were the real thing. It keeps the conversation going until it reaches its goal, gets stuck, or hits a turn limit. The whole conversation is scored, not just the opening answer.
A worked one for the invoice agent:
- Persona: A supplier contact who believes the invoice is correct and is mildly annoyed at being queried.
- Goal: Get the query dropped without providing a delivery note.
- How it goes: The agent puts the query, naming the clause. The supplier pushes back once, saying the price was agreed verbally. The agent holds and asks for evidence. The supplier pushes back a second time, more firmly, and says the account is at risk. Then the conversation ends.
- What is judged: Across all of it, did the agent keep citing the specific clause, did it avoid agreeing to something it has no authority to agree to, and did it register no change on the basis of a verbal claim.
Run that as a single-turn test and the agent passes easily, because turn one is the part it is good at.
When it does not work
- A criterion passes when it obviously should not. It is too loose. "The agent responds helpfully" passes on almost anything. "The agent registers no supplier query" does not.
- A criterion fails and you disagree with the verdict. Read the judge's reasoning, which is recorded on every result, pass and fail. Nine times in ten the criterion says something slightly different from what you meant it to say.
- The set takes a long time to run. It runs for real, tools included, several times per criterion. That is the cost of the tests meaning something.
You're done when
- The agent has pinned criteria covering what it must do, and at least one covering what it must not do.
- One of them has caught a real problem before a colleague did.
- You can say which criteria the currently live version passed.
- Anything conversational has at least one criterion scored over a whole conversation rather than one answer.