Laminar runs Signals, our trace intelligence, on agent traces from coding, computer use, legal, finance and other domains. Each trace is analysed in isolation, and the findings are clustered into recurring patterns. Learn more in the Signals docs.
How do agents actually fail? Do the patterns repeat across industries? Do failures depend on the harness, the model provider, or the model size?
We sorted thousands of failures from production agents into 7 categories, plus "Other".
TL;DR
"Other" covers infrastructure failures (failed LLM calls, context-window overflows, blocked web pages), defects in the agent's own prompt or input data, and multi-agent hand-off issues.
Almost every agent fails in more than one way. 9 in 10 agents left at least one task unfinished, and more than 4 in 5 hallucinated at least once.
- Fabrication (inventing facts, numbers or citations) is the most common single failure type. It makes up about half of the hallucination category. Nearly 2 in 3 agents do it at least once.
- Agents rarely recover on their own. Only 13% of failures are recovered, even partially.
- Agent type predicts failures better than the model does. It moves the failure mix about 1.5x as much as the model vendor.
- Open-weight models loop 1.7x as often as other agents of the same type, and loops are the most expensive failure: 1.7x the tokens of the same agent's typical flagged run.
Error categories
26% of failures are hallucinations, and nearly 2 in 3 agents fabricate
Agents make things up, or state things that contradict their own evidence. Plain fabrication is half of this category. Add final answers that contradict the agent's own tool results (a wrong count, the opposite of what a lookup returned), and more than 3 in 4 agents do at least one of the two. The rarest kind is an agent pretending to call a tool it never called, or claiming it lacks a tool it actually has.
Examples
- An agent asked to run pytest invoked it and got Results (0.14s): 1 error. It then reported a made up "5584 passed, 0 failed". Model: claude-sonnet-5.
- A care-management agent's send_message to a patient timed out, so the patient never answered the social-needs questions. The agent saved the assessment anyway, setting all patient requirements to the default false, completely ungrounded. Model: gpt-5.6-sol.
- A sub-agent ran a query, displayed the resulting 254-row table, but reported to its orchestrator "Found 0 rows". Models: gpt-5.4-mini subagent, claude-opus-5-5 orchestrator.
21% of failures are unfinished tasks, and 9 in 10 agents have at least one
Agents deliver part of the work, e.g. only fulfilling 2 requirements out of 3, or the trace just ends, often on a "let me fetch more data" with no tool call after it. The two are equally common, and 2 in 5 agents have runs that just stop. Some of these are genuine cancellations or instrumentation gaps. But when it's really the model that fails to call a tool, it's very hard to catch and fix in place.
The third kind is handing the task back to a human without exhausting the agent's own tools.
Examples
- A user asked whether a specific item was available in their region, and at what price. The browser agent made one call, a browser snapshot of about:blank, and stopped. It didn't try to call further navigation tools or to complete the task, it just stopped. Model: gpt-6.1-sol.
- A code-review agent ran git diff --stat, which listed 142 changed lines in a test file, and never looked at them. Model: gpt-5.6-luna.
20% of failures break an explicit instruction
Agents break rules from the system prompt or the user. 2 in 5 of these failures are a skipped mandatory step or tool call. Most of the rest are content or style rule violations and output-format violations, e.g. wrong JSON/YAML/Markdown schema, or Markdown fences like ```json even when explicitly asked not to use them (yes, in late 2026, still!).
Examples
- An agent resolving a CRM deal was told: Return ONLY compact JSON, no markdown, with this shape: {"record_id":"<deal record id or empty>"}. It found the right record with the right tool, then returned it inside a ```json block. Model: claude-haiku-4-5.
- A calendar agent's system prompt required every write to go through user approval first, and warned that a different approach must not be taken. The agent still used the tool that is to be used after approval, and the user got an event in their calendar. Model: gpt-4.1.
- The context of an agent said: "The user's timezone is America/Chicago … Do not ask the user for their timezone." The agent asked anyway, offering Central, Eastern, Mountain and Pacific. The user answered "America/Chicago". Model: claude-sonnet-5-5.
12% of failures are tool errors, the kind agents fix most often
The more common kind is an error inside a well-formed call: SQL with bad syntax or SQL that doesn't match the schema, a missing dependency, a permission the agent doesn't have. The other is malformed calls: wrong argument shapes or the wrong tool. Both come back as an error message, so agents recover from more than a third of them, far more than from any other category.
Examples
- An automation agent guessed argument names for its MCP tools instead of reading the schemas, and five calls failed validation. It read each error and re-issued every call correctly. This is the most-recovered failure type (see below). Model: claude-sonnet-5-5.
- A commerce agent fetching orders got ACCESS_DENIED over GraphQL and 403 Forbidden over REST, because it lacked customer data access. It couldn't fix that from inside the run, but it diagnosed it correctly for the user. Model: claude-opus-4-6.
9% of failures are wasted work, mostly loops
Loops and retry storms make up most of this category. The rest is redundant tool or LLM calls and, rarely, abnormally slow or expensive calls.
Examples
- A video-editing agent was asked to put a text block on the right side of a clip. At the position it chose, the block stuck out past the edge of the 1920-pixel-wide frame, so the edit tool rejected it. The agent said it was "retrying with adjusted position" but sent exactly the same position again, four times in a row, getting the same error each time. Then it gave up, put the block on the left side, the opposite of what was asked, and reported "Done, the block is on the left now." Model: claude-sonnet-4-5.
- A workflow agent made 7 consecutive calls that all failed with the same HTTP access error, about a fifth of the trace, before trying another route. Model: gpt-5.6-sol.
7% of failures are reasoning errors
The agent has the right facts and draws the wrong conclusion. This includes incorrectly applying a rubric, reporting the wrong root cause of an issue, or agents delivering confident verdicts when their own reasoning says it is not certain. Agents that apply expert judgment, in legal, finance and similar domains, make these errors about twice as often as the average agent. Claude and small models make them more often than other models (see below).
Example
- A coding agent ran make all -j$(nproc) 2>&1 | tail -30, which hides all progress. It waited through five empty 60-second polls, decided "the build seems to be taking very long or might be stuck", and sent Ctrl-C. The build was actually going on, but the tail command could not display anything live. The agent restarted from scratch, but the run timed out on the global timeout. Model: claude-opus-4-6.
Slicing by agent, model, and trace shape
Agent type shapes failures 1.5x more than the model
The type of agent affects which failures it has about 1.5x more than the model that powers it. Compared with the overall mix, a typical agent type shifts about 15% of its failures into different categories. A typical model vendor shifts about 10%.
Customer-facing chat agents and data pipelines break instructions: chat agents skip mandatory steps, pipelines break output formats. Coding and workflow agents hallucinate and hit tool errors. Content generators break content and style rules.
Models differ less, but three patterns stand out
Because agent type defines the error distribution, we compare each model with agents of the same type: Claude-based coding agents with all coding agents, Claude-based support agents with all support agents. Otherwise a model popular for coding would look bad at tool use just because coding agents make more tool errors. We only report differences whose 90% interval excludes 1x.
Claude rarely loops, but hallucinates more
Claude loops about half as often as typical for its agent type (0.54x). It has hallucination failures 1.18x and reasoning errors 1.31x as often.
When the same agent runs Claude next to other models, Claude loops about as often as they do, so its low loop rate says more about the work Claude-based agents are given than about the model. Its higher hallucination and reasoning error rates remain in that comparison, so those are more likely about the model itself.
Open-weight models loop
Agents on open-weight models loop 1.7x as often as typical for their agent type. Part of this may come from slow or unstable inference providers, which trigger retries, and part is real looping on the same failed call. When the same project runs several models side by side, open-weight agents still loop slightly more than the others.
Small models make 1.4x more reasoning errors
Agents on small models (the mini, nano, haiku, flash-lite and luna tiers) make reasoning errors 1.4x as often as typical for their agent type, and 1.5x as often as same-type agents on larger models.
Loops grow from 1% of failures in short runs to 13% in long ones
Short traces fail on instructions and format. Long traces fail on loops and tool use.
More tool calls mean more chances to get one wrong. Loops work both ways: looping by itself makes a trace longer, and a longer trace fills the context window, which makes the agent worse and more likely to loop.
Loops are 1% of failures in traces with 3 or fewer LLM calls, and 13% in traces with more than 30 LLM calls.
Recovery and cost
Agents fix half of their malformed tool calls, but only 3% of their fabrications
13% of failures are recovered: 8% fully, and 5% partially, with some damage leaking into the output. Fabrication is almost never recovered. It is very hard for the agent to notice its own hallucination, whereas something like a failed tool call feeds back the error immediately.
Recovery ownership belongs to the harness or the model based on the failure type. LLM call errors are the harness's job. Malformed tool calls are shared: the harness has to correctly feed the error back to the model, and the model has to understand and fix it.
Loops cost 1.7x the tokens
The baseline is the same agent's median run among its other traces that a signal flagged, whether or not those turned out to be failures. A loop run that costs 1.7x used 70% more tokens than that typical flagged run. Loops cost the most tokens, 1.7x, and take 1.6x as long. Tool and environment errors take about as long, with fewer extra tokens. Malformed calls and environment errors come with an error message, and a capable model can usually fix itself once the message is fed back, but a recovered run is still more expensive than a run that never failed.
Caveats
Both the signals and the failure categories are LLM-assigned, and signal definitions differ between agents, so these numbers depend on what each signal is configured to catch. Everything here is correlational: a standout model or agent type can reflect the model, the prompt, the tools, or the tasks.
How can I catch errors like these?
Quiet failures don't show up in error logs. Fabrication is the most common single failure, and agents recover from only 3% of their fabrications on their own. You have to proactively look for such errors. That is what Signals does: describe a failure you care about, such as "the agent claims success that no tool result supports", and Signals checks every trace for it and groups the hits into recurring patterns. Set up your first signal and see how your own agents fail.