Detecting Reasoning Loops and Agent Failures in Transcripts

Traditional software fails loudly, with stack traces, exit codes, and crash dumps that announce the moment something broke. Agent failures don't work that way. An agent can run for hundreds of steps, burn through a large budget, and never once throw an error, because the failure isn't an event — it's a process that looks like productivity from the outside.

That distinction matters because monitoring built for crashes can't see a system that's healthy by every metric except the one that counts: whether it ever finishes the job. A tool response can come back as well-formed JSON with an HTTP 200 status and still tell the agent nothing useful, and the agent will read that empty response as a green light to keep going. One documented case from Particula in July 2025 involved an agent that ran hundreds of reasoning steps at a cost of an alarming per-minute rate, endlessly refining its own logic and requesting more data, and never once produced a final answer. No crash. No alert. Just a bill that kept climbing until someone finally opened the transcript and read what had actually happened.

This piece looks at what it takes to actually watch an agent while it runs, rather than after the invoice arrives — starting with what a loop looks like in the raw transcript.

What a reasoning loop actually looks like in a transcript

The clearest signature of a loop is mechanical: the same tool gets called over and over with identical or near-identical parameters, and nothing about the system's state changes between calls. Three things tend to cause this.

First, ambiguous tool feedback. A response that says something like "more results may be available" reads to the agent as an invitation, not a status update, so it calls again hoping for something better. Second, no stopping criteria: without a hard cap on iterations or time, the agent has no built-in reason to quit. Third, a fuzzy goal. If the agent was never given a clean definition of "done," completion is a state it can't recognize even when it arrives there.

A subtler version of the same problem shows up as a semantically empty return. The tool answers with a valid structure and zero useful content, and the agent mistakes that structure for partial progress instead of a dead end. In multi-agent setups, the pattern shows up differently again: handoff latency spikes and circular exchanges, where each agent is waiting on the other to move. Research has documented exactly this kind of ping-pong, plan deadlock expressed as token-consuming back-and-forth, across multiple multi-agent frameworks.

Underneath all of this sits a basic property of autoregressive models: prior output becomes evidence for the next output. If a model already generated a plan step, that step's presence in its own context nudges it toward repeating something close to it, reinforcing the pattern rather than correcting it. Call it an attention pattern feeding on itself. The real test for telling a loop apart from ordinary iteration is simple to state, if not always simple to check: did the state change, did new information get incorporated, and did the agent move toward a genuinely different next action? Loops fail all three.

Why loop evidence in a transcript is sparse and delayed

It would be convenient if loops were obvious the moment they started. They aren't. Baidya et al. (arXiv 2606.05414, June 2026) looked across five benchmarks spanning customer support, task-oriented dialog, persuasion, tool use, and planning, and found that high-relevance failure evidence occupies only 4.7 to 11.3 percent of the turns in a given trajectory. Worse, that evidence doesn't show up early: it first appears after 59.0 to 83.6 percent of the trajectory has already run its course.

By the time the signal is unambiguous, the money's already spent, the latency's already accrued, and any downstream effects are already in motion. Assigning a success-or-failure label after the fact is the easy part. Catching the failure while it's still salvageable, from partial, sparse, ambiguous signals, is the hard part, and it's the part that actually matters operationally.

Simple rule-based checks, like flagging any tool called more than some fixed number of times, catch the blunt cases but miss loops that rotate across different tools or vary their calls just enough to look distinct while doing nothing new. Long context makes the problem worse over time: the more an agent accumulates, the more that accumulated context crowds out its own sense of the goal. The pattern is well-documented: bloated context accumulation correlates with outright failure, while leaner context designs tend to succeed. That contrast says something about where the failure actually originates.

The upshot is that detection has to work probabilistically, on partial evidence, rather than waiting for a threshold to trip.

Detection approaches that work on partial trajectories

Automated detection splits broadly into two camps. Rule-based detection sets hard boundaries: block certain calls, enforce rate limits, cap the number of iterations. It's cheap and fast, and it's blind to intent, since it can't tell a legitimate retry from a loop if both look the same on paper. Behavioral detection asks a harder question, whether the agent is still doing what the user actually wanted, which catches goal drift and quiet misuse that rules miss entirely, at the cost of much heavier compute.

The more useful approaches operate on partial transcripts as they happen, not after the run ends. Baidya et al.'s approach learns sparse turn-level failure evidence from trajectory labels, then combines those signals into an early intervention decision, with controls that let teams shift the balance between catching failures early and catching them accurately — which matters a great deal for anyone trying to run this in production rather than in a paper.

Related work on multi-agent systems explores online auditing that pinpoints the specific step where things went wrong, across a range of agentic tasks. Separately, a paper (arXiv 2608.23670) taxonomizes more than 1,600 agent traces to build out a catalog of failure modes, essentially a pattern library other teams can build detection rules against.

Each method sees a different slice of the problem and misses the rest. Rate limits catch same-tool repetition but miss semantic loops spread across tools. Similarity-based detection catches redundant calls that look different on the surface, but needs embedding infrastructure to run. Attention-based predictors catch sparse early signals but need labeled trajectory data to train on. Behavioral monitors catch drift but cost the most to run continuously. None of this is free: stronger detection means more compute, more latency, and a real decision about where a given team wants to sit on that tradeoff.

What transcript instrumentation needs to capture to make detection possible

A raw log of model outputs omits most of what a trajectory actually needs, and treating the two as interchangeable is where most instrumentation falls short before detection even gets a chance to run. Production-grade instrumentation needs four categories of data.

Prompt construction: how inputs, retrieved context, and injected instructions actually combine into what the model sees, since none of that composition shows up in an output-only log. Model invocations: input tokens, output tokens, model parameters, and latency per call, which is what lets a team spot cost accumulation and context bloat before they become a $47-a-minute problem. Tool executions: the tool name, its arguments, its response, its error state, and its latency, which is the raw material loop detection actually runs on. Decision points: the branching logic and reasoning steps that separate an intentional retry from a loop that just looks like one.

Distributed tracing frameworks can capture this kind of structured data, giving teams a common schema for spans across all four categories and a path to export that data into observability backends. Structured trajectory formats, breaking each step into "think," "action," and "observation" components, make it possible to run detection logic against the data programmatically instead of having a person read through logs by hand.

Telemetry earns its keep twice: once in the moment, for troubleshooting a run that's currently misbehaving, and again over time, as the same data trains better detection for the next run. Most teams' actual gap is narrower than it sounds: they log model outputs just fine, but they don't capture tool arguments and responses at the call level, so the loop signature exists somewhere in the system, in tools like Vex that surface how agents are actually using their skills, and is simply never written down anywhere anyone can query it.

How loop signatures expose harness design problems, not just model problems

The instinct when an agent loops is to blame the model. The transcript often points elsewhere: at the harness, meaning the code wrapped around the model — which tools it can see, how those tools are described, what context gets assembled into each prompt, what happens to the agent's own prior output. That layer is where most of these failures actually originate.

Lee et al. found accuracy gaps of up to roughly sixfold across different harnesses, with the same underlying model performing very differently depending on how the harness presented information to it. That's a striking number, and it suggests the harness carries a large share of the work itself, for better or worse, rather than serving as a thin wrapper around the model.

Transcripts make specific harness defects visible. Tool descriptions that never specify when a tool's job is actually finished invite the agent to call it again just in case. Tools that get called often but never contribute to a completed task are dead weight that adds noise without adding value, and they show up clearly once someone looks at which tools appear in successful runs versus which appear in loops. Missing verification gates between plan steps mean the agent has no checkpoint to confirm it's actually made progress before charging ahead. And context assembly that re-feeds the agent its own failed attempts turns the loop self-reinforcing, because the evidence of failure becomes, perversely, the context for trying again.

Bloated tool sets compound all of this: every additional exposed tool is more surface area for the agent to loop across, and pruning unused tools shrinks that search space directly. Newer harness safety layers, build pre-execution checks and runtime enforcement directly into the harness. Those systems need an evidence base to act on, and the transcript is that evidence base.

Turning transcript patterns into an ongoing feedback loop for harness health

One transcript catches one failure. A corpus of transcripts, read as a set, reveals a structural problem with the harness itself, and that's a different and more valuable kind of finding.

The patterns worth tracking span runs, not single runs in isolation: which tools show up most often inside loop segments across many trajectories, which specific tool responses tend to precede a loop starting, roughly how deep into a trajectory loops tend to begin, and whether loop rates track with task type, prompt structure, or context length. Each of those, once known, points directly at a fix, whether that's rewriting a tool description, adding a verification gate, or capping context earlier for a particular workflow.

This is agent transcript analysis treated as an ongoing discipline, run on a regular schedule rather than triggered only after something visibly breaks. The scale argument for doing this is not abstract: AI-opened pull requests went from roughly 4 million in September 2025 to more than 17 million by March 2026, and at that volume, even a modest per-run loop rate turns into real disruption across CI systems and review queues. Harness tuning belongs on the same maintenance cadence as dependency updates, folded into routine practice rather than reserved for after an incident report.

The end state worth aiming for is a harness that fails fast and visibly instead of spinning quietly: tight tool descriptions, explicit stopping criteria, verification gates between steps, and a transcript layer built to catch drift before it turns into a production incident. Teams that read transcripts only when things go wrong are running blind between incidents. Teams that fold transcript analysis into the regular harness review cycle are running something closer to an actual software factory, one where the model is a component, not the whole system.