A browser test is one conversation. Simulated callers are several: the Builder asks the platform to invent callers from the goals recorded on an agent, each with a reason to ring and a way of behaving, and to run them against the draft one at a time while you listen. Every call is then judged against those goals and the result comes back into the chat for the Builder to act on.
It is optional. Nothing stops you going live without it, and the Go live window only says whether it has been run on the draft you are about to publish.
How a run works
Once an agent has its goals recorded and a test call has gone well, the Builder offers to run simulated callers, and again before you go live. Say yes, or ask for it in your own words ("run some simulated callers against the team").
A panel lists the scenarios the platform wrote: a title, which goals each one exercises, and the caller's brief if you want to read it. Happy paths cover each must-have goal; the rest come from a catalogue of ways real callers trip agents up, such as a vague caller, someone asking for a person, a request the agent must refuse, or a question the knowledge cannot answer. Untick any you do not want. Scenarios that could make the agent ring a real number, or book or email anything for real, start unticked with a warning.
The calls run in your browser, one after another, in the same test window as an ordinary browser test. You hear the caller and the agent, and the transcript shows both sides. Skip a call or stop the run at any time.
Each call is marked pass, partial or fail: a pass means every must-have goal that applied was achieved and the agent kept to its prompt; partial means only should-have goals were missed. Each goal carries a line of evidence from the call. When a call fails a must-have goal, a second judge on a different model checks it; where the two disagree the goal is marked contested rather than decided.
Send the report to the Builder. It reads the verdicts like a test result, proposes fixes to the draft and applies them when you agree. Run again if you want to see the difference.
Simulated calls are real calls on your team's models and voices and count as normal usage, the same as a browser test. The panel tells you how many calls and roughly how long before anything runs. Each call also uses the caller's own voice minutes. A run holds two of your plan's simultaneous-call slots while a call is live.
Running in the background
Run in the background on the review panel hands the calls to the platform instead of your browser. Nothing plays on your machine; the report arrives in the Builder chat the next time you open the team, and the Go live window says "queued" until then. The calls bill the same way.
Keeping a failure as a test
When the Builder diagnoses a failed call, a test call or a real one, it can keep a simulated caller that reproduces the failure. Say yes and it writes the caller from its diagnosis, shows you the brief to adjust, and saves it. From then on every simulated-callers run against that team includes it, marked Saved test in the review list, where you can also forget it. The report also says when a failure has appeared in earlier runs, and whether a saved test already covers it.
What the judge sees
The judge is given the caller's brief, the goals recorded on the agent, the transcript of what the caller said and heard, the platform's record of which tools ran and whether they succeeded, and a set of mechanical checks (the call connected, the expected tool ran, nothing forbidden was said). Tool records outrank dialogue: an agent that says it has booked something without a successful booking call has not booked it.
Where to see it again
The latest result for a team shows in the Go live window, with whether it ran on the draft you are publishing or an earlier one. Any edit after a run makes it an earlier draft.