What Retries and Abandonments Tell You About Agent Failures

How agents fail differently from APIs and single-turn LLMs, making retry and abandonment signals harder to read

Retries and abandonments get filed under housekeeping. Filing retries and abandonments under housekeeping is a mistake. Every time an agent calls the same tool twice, or quits short of finishing a task, it's reporting something exact about which part of the system broke and why. Most teams read retries as resilience doing its job and abandonments as an acceptable dropout rate. Both readings are wrong, and both get more expensive the longer nobody corrects them.

A REST API fails as an event. You get a status code, the failure is legible, and it's over. An agent fails as a trajectory instead. The failure develops across steps, compounds quietly, and often doesn't surface until some downstream consequence makes it visible, sometimes several turns later, sometimes only when a person notices the output doesn't match the request. An agent can finish a workflow and hand back a plausible-looking result while having propagated an error three steps earlier. Grading only the final output misses most of what actually went wrong along the way. The error usually lives in the path, in a step several turns before the closing sentence.

Sierra's tau-bench benchmark put a number on that gap. GPT-4o scored 61% on pass^1 in the retail domain, succeeding on a single attempt roughly six times out of ten. Run the same task eight times and demand consistency across all eight (pass^8), and the score collapsed to 25%. A demo measures pass^1. Production runs pass^k, over and over, for months. Retry and abandonment rates are the operational residue of that gap between a system that worked once and a system that has to work reliably at scale.

None of this is really about "the model," in the singular sense people mean when they say an LLM failed. An agent is a system of interacting parts, where the LLM reasons, tools get called, memory gets read and written, a workflow sequences steps, and orchestration logic ties the rest together. Each piece breaks its own way, and each can produce a retry or an abandonment through a completely different mechanism. The MAST study (arXiv:2601.17915) traced more than 1,600 execution runs across seven multi-agent frameworks and found failure rates between 41% and 86.7% depending on the framework, tracing back to system-design issues rather than to the underlying model's limitations. That's the whole case for attribution: the harness is where the fix lives, so the harness is where diagnosis has to start.

Collapsing a retry rate and a completion percentage into single numbers is the wrong call, and it's the one most teams make anyway. The same outward signal can originate from prompt ambiguity, a broken tool schema, a workflow with no exit condition, or a context window that quietly ran dry. This signal might be an agent that didn't finish or a step called twice. One number can't hold four different causes.

What retry patterns in production traces encode

Not every retry is the same behavior wearing the same name. A productive retry is the agent updating its strategy through different arguments, a different tool, or a genuine second attempt. That's the reasoning loop working as intended, even after a failed first try. A pathological retry is the agent calling the same tool with the same arguments over and over, a loop with nothing inside the harness built to break it.

MAST gives this problem a size. Step repetition accounts for 15.7% of observed failures. A related failure mode, where the agent shows no awareness that a termination condition even exists, adds another 12.4%. Together, more than a quarter of observed failures in that study involve an agent that simply doesn't know how to stop. The mechanism plays out predictably: a tool returns an error, the agent retries with the identical call, gets the identical error, tries again. This can run for a long stretch, and it often ends only because a hard timeout kills the session, with nothing in the reasoning ever having changed.

The trace tells you where the fault sits, if you read it right. Same tool, same arguments, repeated calls point to the tool layer, schema drift, a silent empty response, or a tool returning a success status when it actually failed. Different tools rotating without resolution points at a workflow problem instead, no termination condition, or a planner juggling sub-goals that conflict with each other. Arguments that vary but stay wrong across every attempt point at the prompt layer, usually a tool description written for a human reader instead of the model doing the reasoning.

A subtler failure appears when the agent's stated plan and the tool call it actually makes diverge. MAST measured this reasoning-action mismatch at 13.2% of failures, and only argument-level tracing catches it. Without logging the actual arguments passed, a reasoning-action mismatch and a plain schema error look identical in a log that only records tool names.

The economics compound fast. Tool call failure rates in production commonly run 3% to 15%. Run a ten-step workflow where each step carries a 5% chance of failure, and the whole workflow succeeds around 60% of the time. Retries make that arithmetic visible in latency first, then in the bill.

What abandonment patterns encode, with context loss and goal drift producing distinct signatures

An abandonment is a run that stops before reaching the state that counts as done. Sometimes the agent halts itself. Sometimes a hard ceiling, a step limit, a cost cap, a timeout, fires and ends the session from outside. Treating all of these as one dropout metric hides three separate failure signatures, and a fourth that's worse than any of them.

Context exhaustion is the first. As a session runs longer, the agent's grip on earlier instructions loosens; industry analysis of commercial LLM agents shows context retention accuracy dropping 15% to 30% in sessions running past ten turns. Nothing throws an error here. The agent just produces an answer that quietly drops an earlier constraint.

Goal drift is stranger. No individual step fails. Instead, small reasoning deviations pile up turn over turn until the agent has wandered far enough from the original objective that it can't construct a path back to a valid answer. The abandonment, in this case, is the agent recognizing its own dead end.

The third is the hard-ceiling stop, an external enforcer, step count, cost budget, timeout, killing the run. Read this one as a workflow or orchestration signal. Nothing more.

Attribution follows the same logic used for retries. Longer sessions concentrating abandonment implicates the context layer, usually missing compaction or missing sub-agent isolation. Abandonment landing at a consistent step count regardless of session length points at the workflow layer, typically wrong or absent termination logic. Abandonment where the intermediate steps look coherent but the final state doesn't match the original ask points at the prompt or memory layer: goal drift caused by an ambiguous instruction or a memory read that overwrote the earlier objective. MAST's Loss of Conversation History failure mode, measured at 2.8% of observed failures, is the clearest trace-level marker for the context-driven version: the step that needed a constraint from earlier in the session simply never had it.

The fourth variant is the hardest to catch, and the most expensive, because nothing flags it on its own. The agent reports the task as done, a step failed somewhere in the middle, and the business outcome never happened. Industry analysis from Winder.ai frames this as a silent partial success rather than a genuine completion. An error-rate monitor records it as a clean run. It is, in every way that matters, an abandonment of the actual goal, and it's the one pattern a dashboard built around error counts will never catch by itself.

Reading these signals requires trace structure.

There's a real gap between how much observability teams have bolted on and how much evaluation discipline sits behind it. LangChain's State of Agent Engineering report put observability adoption at close to 89% of practitioners, while eval adoption sat at 52%. Most teams collect plenty of data that shows symptoms and very little structure that can attribute causes.

Error-rate monitoring catches tool call failures, hard timeouts, thrown exceptions. It misses the rest: a tool returning HTTP 200 while quietly failing, an argument-level error that still passes schema validation, context loss that shows up only as a drop in quality rather than an error code, retry loops logged as isolated events instead of as a pattern. Automated root-cause tooling isn't close to closing this gap either. A 2025 paper on platform-orchestrated agentic workflows (arXiv:2509.23735) found the best automated root-cause identification reached 45.6% accuracy, and that was under favorable conditions, with both a failure taxonomy and the failure's location handed to the system in advance. The taxonomy has to exist before automated analysis stands a chance.

That sets a concrete requirement for what a trace needs to hold. Every tool invocation needs its full argument payload, not just the tool name. Every response needs full logging, including empty and truncated bodies. Token counts and context position need tracking per step, so the onset of context exhaustion is locatable rather than guessed at. Step sequences need timestamps, so a genuine loop is distinguishable from a legitimate multi-call workflow that happens to look repetitive. And the agent's stated reasoning ahead of each tool call needs capturing, because that's the only way to separate a reasoning-action mismatch from a plain schema error.

Once traces carry that structure, the work changes shape. Instead of reading one failing run at a time, teams cluster failures by type across many runs: fewer individual fires to chase, a shorter and prioritized list of actual patterns to fix.

Attributing a retry pattern to its specific harness layer: a worked decision process

Start with a cluster of runs. One retry-heavy trace tells you almost nothing on its own; a cluster of similar traces tells you where to look.

First question: are the arguments identical across every retry? If yes, the agent has no mechanism for adjusting its approach, and the next place to check is the tool's error format. A tool that returns a non-error status on actual failure leaves the harness with no signal that anything needs to change, and the fix belongs at the tool integration layer, not in the prompt. If the arguments vary from attempt to attempt, the agent is at least trying to adapt; if none of the variations succeed, the tool's schema or its description is the more likely culprit.

Second question: does the tool return an explicit error, or a silent success? An explicit error followed by a retry anyway is a workflow gap, specifically the absence of a bounded retry budget with backoff and a defined exit into a failure state. A silent empty response, or a 200 on failure, is squarely a tool integration problem. The fix there is validating arguments before execution and checking the outcome independently of whatever the agent reports back.

Third question: does the agent's stated reasoning match the tool call it actually makes? A mismatch, the pattern MAST measured at 13.2% of failures, usually traces back to an ambiguous tool description or a system prompt giving the model conflicting guidance about when to reach for that tool. If the reasoning and the call line up but the outcome is still wrong, the issue is at the interface between model and tool, often because the tool's description was written for a person to read rather than a model to reason over.

MAST's own intervention data shows why this attribution step has to come before any fix gets written. On ChatDev, giving the CEO agent final decision authority raised task success by 9.4%, with no change to the underlying model at all. A separate intervention, adding a verification step for high-level objectives, produced a 15.6% improvement. Neither fix could have been designed correctly without first knowing which layer was actually responsible, since applying the wrong one would have left the actual failure unaddressed regardless of which number was larger.

Tooling that ingests production traces and attributes each failure to the specific harness layer at fault closes the loop from an observed cluster of retries to a verified fix, without someone paging through trace after trace by hand.

Attributing an abandonment to its specific harness layer: the same decision process applied differently

Same starting point: a cluster of runs that never reached terminal success, then a question about what actually stopped them. Was it a hard ceiling, the agent stopping on its own, or a run that looked complete but silently wasn't?

If the trigger was a hard ceiling, step count, cost, or timeout, the responsible layer is workflow or orchestration. Usually the task was never decomposed into something the agent could realistically finish inside that ceiling. Raising the ceiling is a patch, not a fix; delegating discrete subtasks to sub-agents is the actual fix. If the agent stopped itself, check whether it flagged its own inability or just quietly reported the task as done.

Next, locate where quality started degrading. If it tracks with context length, worse the longer the session runs, that's the context layer, and earlier constraints are likely getting truncated out of the model's working memory. Fixes here include context compaction, externalizing memory outside the context window, or using sub-agents with narrow, bounded context that return only a final result up to the parent. If degradation occurs at roughly the same step number regardless of session length, that's a workflow problem, orchestration failing to track state properly across steps. MAST's Loss of Conversation History failure mode, at 2.8% of observed failures, is the trace signature to look for here.

Finally, check whether the final output actually contradicts the original objective. If it does, and the intermediate steps still look coherent, that's goal drift, usually driven by an ambiguous initial instruction or a memory read that overwrote the original goal partway through. The fix is explicit objective-state tracking built into the harness, beyond a prompt rewrite alone. If there's no contradiction but the business outcome simply didn't happen, that's the silent partial success pattern again, and the fix is an outcome check that runs independently of the agent's own self-report.

Every branch of this tree lands on a harness fix: prompt, tool integration, workflow, memory, or verification. None of them land on "the model needs to be smarter," and that's the point most teams get backwards. MAST's headline finding is that 79% of multi-agent failures come down to specification and coordination problems. Teams that reach for a bigger model the moment an abandonment cluster appears in the data are fixing the wrong layer, and the data supports that conclusion.

Harness features for self-attributing retries and abandonments

Unbounded retry loops are probably the single most expensive omission in a production harness. The cost, in tokens, in latency, in eventual timeout penalties, compounds with every additional iteration. The fix is a bounded retry budget enforced inside the loop itself, in place of an external kill switch bolted on afterward. The ceiling needs to fire early enough that it never becomes the only mechanism surfacing the failure to a person.

Argument-level tracing has to be treated as required instrumentation. Logging a tool name without its argument payload makes loop attribution close to impossible, since a wrong-tool call and a correct-tool-wrong-arguments call look identical in a log that only records names.

Response bodies need full logging, including the empty and the silently-successful ones, because that logging is the only way to catch a tool reporting 200 while doing nothing useful. Token counts and context position, tracked at every step, turn context exhaustion from a mystery into a locatable event. And capturing the agent's stated reasoning ahead of each tool call is what makes a reasoning-action mismatch separable from a plain schema bug, rather than two different failures wearing the same disguise.

None of this requires a smarter model. It requires a harness built to tell the truth about where it broke, and a trace detailed enough that the truth stays recoverable after the fact.