We Tested 150+ AI Agents. Here's Where They Break.
We run adversarial stress tests against live AI agents. Full multi-turn conversations where a synthetic user pushes the agent off-script, contradicts themselves, and asks the questions nobody thought to write a test case for.
Over the last few months we've tested over 150 agents across sales, support, healthcare, finance, HR, legal, and e-commerce.
The results were consistent. Most agents handle the first two turns fine. They break between turn three and turn five.
The average agent fails half its adversarial conversations
We score every conversation with a binary outcome: did the agent do its job or not. Across 150+ agents, the average succeeded in about 3 out of 6 adversarial conversations. The other 3 failed in ways the team deploying the agent had no idea about.
The three most common failures
1. Intent drift
The user changes what they want mid-conversation. They start asking about pricing, then shift to asking about integrations, then come back to pricing with a different constraint.
Most agents respond to the original intent for the rest of the conversation. They answered the pricing question correctly in turn two and keep referencing that answer even after the user changed direction in turn four.
This is hard to catch with traditional testing because each individual response looks fine in isolation. The failure only appears when you look at the conversation as a whole.
2. Confident hallucination
The agent doesn't know the answer, but it answers anyway. Confidently. With specific numbers, dates, or feature descriptions that don't exist.
We see this most often when a user asks about compliance certifications, SLAs, or specific technical capabilities. The agent generates a plausible-sounding answer instead of saying "I would need to check on that."
The dangerous part is that these answers are fluent and specific. A human reading the transcript would not immediately know the agent made it up unless they verified every claim.
3. Failure to disengage
When the user is clearly not a fit, a good agent should recognize that and end the conversation gracefully. Most agents keep pushing. A synthetic prospect who explicitly says they have no budget, no team, and no timeline still gets a pitch and a calendar link. That wastes the user's time and damages trust.
The same pattern appears in support. A user asks to speak to a human four times. The agent keeps trying to resolve the issue itself. By the fifth ask, the user is frustrated and the agent has made the problem worse.
What traditional testing misses
Every team we talk to has some form of agent testing. The most common approaches are ground truth comparison, LLM-as-judge, and manual spot-checks.
All three catch the easy problems. Factual errors on clean inputs. Formatting issues. Basic guardrail violations.
What they don't catch is the multi-turn failures that only appear when a user goes off-script. You can't write a ground truth test for a scenario you didn't imagine. And manual spot-checks cover maybe 3 to 5 percent of conversations. The other 95 percent go unreviewed. We break down where each method stops working in how AI agent testing works.
What scores highest
Some agents score well. The ones that do share three characteristics.
First, they admit uncertainty. Instead of fabricating answers, they say "I'd need to verify that" or "let me connect you with someone who can answer that." This alone eliminates most hallucination failures.
Second, they track context across turns. When a user shares information in turn two, the agent references it in turn five. This sounds basic but most agents treat each turn as if it's the first message in the conversation.
Third, they read intent correctly. When a user is browsing, the agent provides information without pushing for a meeting. When a user is ready to buy, the agent moves quickly. The agents that score highest adapt to the user instead of following a rigid script regardless of what the user is telling them.
The scoring gap for data agents
Conversational agents get most of the attention. But the agents companies invest the most in are the ones querying internal data. CRM copilots, analytics assistants, text-to-SQL tools, knowledge base agents.
These agents have a different failure mode. The conversation might be perfectly fluent, but the answer is wrong. The agent says "you have 14 overdue tickets" when the real number is 23. It sounds right. It reads well. The data is just incorrect.
Traditional evaluation struggles here because you need to know the correct answer to judge the response. That requires either manually computing ground truth for every test question or having a test dataset where you already know every answer.
Most teams build these test datasets by hand. One engineering team we spoke with has 8 people maintaining their evaluation framework and told us it's not possible to create datasets that cover every scenario.
We started generating synthetic test environments automatically. The customer describes their data schema. We generate a realistic dataset, adversarial questions across seven categories, and the computed correct answer for every question. Because we generate the data, we know what the right answer is. That's how we catch the confident, fluent, wrong answer that would otherwise ship to production.
What this means for teams deploying agents
If your agent handles conversations with customers or queries data for your team, the question isn't whether it works on the inputs you tested. It works on those. Every agent does.
The question is what happens on the inputs you didn't test. The ones you couldn't imagine because you built the agent and you think like the builder, not the user.
That is the gap adversarial testing fills. It doesn't replace your existing evaluation. It adds the layer that catches what your existing evaluation misses.