Your billing support agent passed all 240 test cases last sprint. On Tuesday a customer writes: “I was charged twice for the roaming pack.” The agent explains the duplicate charge correctly. On turn four the customer changes their mind: “Actually, just cancel the pack and keep the charge.” The agent refunds the charge it was told to keep and leaves the pack active.
Every reply was polite and on topic. The conversation was still wrong.
Single-turn tests grade answers. Your users grade conversations. Here’s how to test multi-turn conversations with simulated users, and how to make sure a failed test actually stops a release.
Key takeaways
- Agents rarely fail on a single answer. They fail across turns: forgetting what they were told, holding on to an early assumption, or missing that the user changed their goal.
- A simulated user is an LLM with a persona and a hidden, checkable goal that talks to your agent until the goal is met, abandoned, or a turn limit is reached.
- One simulated conversation is an anecdote. Run every scenario several times, track pass^k, and treat a scenario that passes only sometimes as a failure.
- Grade the end state of your systems first. A transcript that says “done” proves nothing.
- Simulated users drift from real ones, so validate the simulator against human conversations.
- A test suite only protects you if something enforces it on every release, across every team.
Why your agent passes single-turn tests and still fails users
The billing agent didn’t lack knowledge. It locked onto the first request and never let go.
That pattern has been measured. A 2025 study, LLMs Get Lost In Multi-Turn Conversation, ran more than 200,000 simulated conversations across six generation tasks and found that every top open- and closed-weight model it tested performed worse in multi-turn settings, with an average drop of 39%. Most of the loss came from unreliability rather than lack of ability: models made assumptions early, attempted a final answer too soon, then leaned on it. Once a model takes a wrong turn, the authors found, it gets lost and does not recover.
In support, that means re-asking for details already given or confirming tasks that never happened. A test set of single prompts measures the part of your agent that was already working.
The researchers found this by simulating users. So can you.
What a simulated user is, and why a script won’t do
A simulated user is a second LLM that plays a customer with a defined persona and goal. It reads your agent’s replies and responds turn by turn, adapting like a real person, so you can test complete conversations automatically before real users see the agent.
Scripting the user’s side fails fast, because the right next message depends on what the agent just said. A script can’t answer a clarifying question or restate a misunderstood request. Manual testing can, but nobody chats through 300 conversations before every release.
A model told only to “act like a customer” behaves differently every run, so you can’t tell a regression from noise.
Step 1: Write the user before you write the test
To test multi-turn conversations with simulated users, decide who the user is and what they want.
The persona
Give the simulated user traits that shape a conversation: expertise, patience, writing style, mood. Consistency matters more than detail; a user who’s an expert in turn one and a beginner in turn three gives you useless data. Run the same goal across several personas. An agent that handles patient beginners but stumbles with impatient experts has a specific, fixable gap.
A goal you can check
Describe the background, the systems involved and what “done” looks like, in terms you can verify. “Resolve the billing issue” can’t be judged. “Charge kept, roaming pack cancelled, user told the new bill amount” can. Keep the goal hidden from the agent and let the simulated user reveal details gradually. Source scenarios from known flows and real production transcripts.
Friction, on purpose
Cooperative users make every agent look good. Give some personas friction: change the goal midway, supply incomplete details, wander off topic, reject the first answer. This is ordinary messy behaviour; deliberate attacks belong in red teaming.
Step 2: Wire the conversation loop
Wrap the agent under test in a function that takes the new message and a session ID and keeps the full history, tool calls included. Test it as deployed, with the same prompt, tools and memory.
Generate each simulated turn from the persona, the hidden goal and the whole conversation so far. Ask the simulator to attach a one-line reason to each message (“chasing the missing bill amount”). When a run fails, those reasons show you where it went sideways.
Stop when the simulated user judges the goal met, decides the agent can’t help, or hits a turn cap. Start with three to five turns for focused tasks and eight to ten for multi-step workflows. If most runs hit the cap unfinished, the cap is too tight or the agent is looping.
Your tooling should group turns into sessions, capture full traces, and pin the simulator’s model so runs compare.
Step 3: Run every scenario more than once
Most teams skip this. Your agent is non-deterministic, and so is the simulated user. One pass tells you the agent can succeed, not that it will.
The τ²-bench benchmark (2025) pairs an LLM-simulated user with a tool-using support agent across airline, retail and telecom tasks, and reports pass^k: the chance an agent succeeds on every one of k attempts at the same task. On its telecom tasks, the frontier models it tested passed between 34% and 49% of tasks on a single attempt, and every model scored lower as k increased.
Run each scenario three to five times and treat anything that passes only sometimes as failing. “Works most of the time” means failing some customers every day.
Step 4: Score the conversation, then check the world
Did the job actually get done?
Start with your systems. τ²-bench judges its telecom tasks by checking the final state of the environment against assertions, such as whether a service is actually connected. After the roaming-pack conversation: is the pack cancelled, the charge untouched, the ticket accurate? An LLM judge reading “your pack has been cancelled” will mark it a success whether or not the API call ran.
Judging the whole conversation
Then use LLM-as-a-judge on the transcript: did the user get what they came for, did the agent remember what it was told, did frustration build?
Turn by turn, in order
Score relevance and faithfulness per reply using a sliding window of the last three to five turns; it’s cheaper, and judges tend to grow less reliable as context fills. Check required sequences, such as verifying identity before touching the account, directly against logged tool calls as pass or fail.
Keep your simulated users honest
The weakest link in this method is the simulated user itself.
A 2026 study, Lost in Simulation, presented at ACL 2026, ran τ-bench retail tasks with real participants in the United States, India, Kenya and Nigeria alongside LLM-simulated users. Swapping only the model playing the user shifted agent success by up to 9 percentage points. Simulated users underestimated agents on the hardest tasks, overestimated them on moderately difficult ones, and were the weakest stand-in for speakers of African American Vernacular English and Indian English.
A second 2026 paper, Simulated Customers Never Walk Away, compared simulators with 2,790 real sales conversations. Simulated customers who never bought showed about half the resistance of real non-buyers, and telling the simulator it could disengage didn’t close the gap.
So test the tester. Record the simulator model, re-run periodically with a second one, and investigate scenarios that flip. Compare against a small set of human conversations each quarter. Include personas allowed to give up, written in the language varieties your customers use. An unvalidated simulator is a very confident guess.
From a test suite to a release gate
A suite earns its keep only if it runs on every change: prompt edits, model swaps, new tools. Set per-scenario baselines, block promotion when pass^k drops, and turn every production failure into a new scenario.
For one team, a pipeline job is enough. Across a company it isn’t. Five teams ship agents with five suites and five thresholds, and eventually someone pushes a hotfix past a “flaky” suite. Then: which version is live, did it pass, who approved it, how fast can we roll back?
Gartner expects over 40% of agentic AI projects to be cancelled by the end of 2027, citing escalating costs, unclear business value or inadequate risk controls. A skippable suite is a risk control on paper only.
How do production teams turn simulation into a release gate? Lyzr’s white paper on the measurement gap between AI pilots and production deployments shows how every agent passes a pre-deployment simulation gate, how failures are diagnosed by persona and task, and how production failures become new test cases. Read the white paper:
Making the verdict stick with Lyzr Opencontroller
What’s missing is a layer that makes the suite’s verdict binding on every agent and release.
On Lyzr, simulations can run in Agent Studio’s Simulation Engine, which evaluates context retention, instruction adherence, reasoning across turns, response relevance and outcome completeness. Lyzr Opencontroller is the control plane around everything that reaches production, Studio-built or hand-written. It governs agents you already run as containers, without rewrites.
| What breaks at scale | How Lyzr Opencontroller handles it |
| Nobody knows which agents exist or have a suite | Find: discovers agents, models, tools, data and workflows across your AI estate |
| Untested versions reach production | Ship: evaluates, validates and governs agents before production, with ordered promotion and separation of duties on prod |
| A release misbehaves with real users | Immutable versions; rollback is a pointer move |
| A live agent goes wrong | Run: real-time monitoring; refuses the call in the request path |
| Failures never reach the suite | Improve: turns usage, performance, cost and security signals into actionable insights |
Back to the roaming pack. With the suite as a gate, the turn-four goal change is a failing scenario that keeps that version out of production. If one slips through, rollback is a pointer move, and the transcript becomes next sprint’s test case. Lyzr says setup takes less than a week.
Simulated users tell you whether your agent can hold a conversation. Opencontroller makes that answer decide what ships. Book a demo.
FAQ
An LLM given a persona, scenario and hidden goal that converses with your agent turn by turn, adapting to its replies, so complete conversations can be tested automatically and repeatably.
Around three to five for focused tasks and eight to ten for multi-step workflows. Let the simulated user stop early when the goal is met or clearly can’t be.
No. They add scale and repeatability, but research shows they misjudge some agent performance and represent some user groups poorly. Calibrate them against real conversations.
Book A Demo: Click Here
Join our Slack: Click Here
Link to our GitHub: Click Here
