Reading a long agent run

A coding agent ran overnight and opened no pull request. You open its transcript in the morning. It holds 500 steps. Somewhere in there is the reason it stalled, and the only way to find it is to scroll. Much later you learn that steps 118 to 137 were the same failing test, run again and again with the same result.

That scroll is the cost of reading a long run. The answer was in the record the whole time. Nothing pointed at it.

Oxagen 5.5 changes what the Run page shows first. A run's loops, repeated refusals, setup failures, and failing MCP tools sit in their own panel, each with a link to the step where it began. A wrapped agent that loops is told so once, while the run can still change course.

#Why long runs fall into loops

Loops are a known failure. Cemri and colleagues read more than 150 traces from multi-agent systems and sorted what went wrong. Step repetition, an agent doing the same step again with nothing gained, is one of the failure modes their taxonomy names.¹

Loops also feed themselves. Sinha and colleagues found that once a model's context holds its own earlier errors, the model gets more likely to make new ones.² Every failed retry adds another copy of the failure to the context the agent reads next. Backlund and Petersson saw the long form of this in their longest runs. Agents fell into loops they rarely recovered from.³

So the agent inside a loop is the reader least able to notice it. The person reading the transcript afterward can notice, but only after finding it. Both readers need the loop pulled out of the step list and named.

#How the Run page is laid out

The Run page now draws in two columns on a wide screen. The header and the transcript take the left three quarters. The side panels take the last quarter and scroll on their own. The header sticks to the top as the transcript scrolls, so the run's name, state, and controls stay in view at step 400. On a narrower screen the page is one column.

The side column stacks its panels in a fixed order: Run details, Problems, Context, Tasks, Changes, and Subagents. A panel with nothing to show is not drawn. A run with no problems has no Problems panel, and a run that dispatched no subagents has no Subagents panel.

Tasks holds the agent's own plan, the task list it wrote for itself. It sits under Run details and above Changes. The plan says what the agent meant to do, so you read it before you read what the agent changed. A run whose agent wrote no plan shows no Tasks panel.

#How to read and replay a transcript

The transcript has three styles. Terminal reads like the agent's own console. Standard draws each step as a row. Conversation draws the run as an exchange, with each step on its own line and a subagent's steps inside the call that started it.

Replay plays the run from its first step. The timeline under the header splits the run into turns, one for each prompt or steer a person sent. You can jump to a turn, pause, or change the speed. A long run reads as a sequence of decisions instead of a wall of rows. You see where the person spoke and what the agent did next.

#How the Problems panel ranks failures

The Problems panel lists up to five problems, the most costly first. Each row names what went wrong, then its steps and its cost on one line. The steps are a link. A press scrolls the transcript to the problem's first call and opens that row.

The panel finds four kinds of problem in the run's own steps.

• Loops. The same call with the same result three times. The same failing call three times. Two or three calls repeating in order for three full cycles. Or one built-in tool given six inputs that only return results it already gave. A loop that the agent's own engine reported, as Stella's engine does, shows up too.
• Refusals. The same kind of call refused twice. The agent asked again after the first answer was no.
• Setup failures. A command not found, a missing dependency, a denied permission, or a service the run could not reach. One is enough, because the next run on that machine will hit it too.
• Failing MCP tools. An MCP tool that failed at least twice in the run, on at least 20 percent of its calls. The protocol reports a tool's own failure as a result marked as an error, not as a crash.⁴ So an agent can read the failure, retry, and fail again without anything stopping it.

The rules are the same ones the workspace's findings use across many runs. The panel and the findings never disagree on what counts as a refusal or a setup failure.

A refused model call now shows in the transcript with the model it asked for and one sentence of reason. Examples include a model the mandate does not allow, a run that reached its spending limit, or a call that carried an expired run token. You learn why the agent got no answer without opening the gateway's logs.

#How the agent learns it is looping

Finding a loop after the run ends saves the reader's time. It does not save the run. So the recorder also tells a wrapped agent when it starts to loop.

A hook can answer a tool call with text the agent reads before its next step.⁵ When the agent's recent calls reach a loop's start length, the recorder puts one notice in that answer. The text names the tool, how many times the agent ran it with the same input, and that the result never changed. It then asks the agent to change the input or the approach before it runs the call again.

Each loop gets one notice per session. A loop that goes on does not get a second, and a different loop gets its own. Claude Code and Codex read the notice in the answer to the call they just made. Cursor's answer after a call carries nothing to the agent, so Cursor reads the notice as the refusal of its next call, and only when that call is the one the loop would run next. Stella is never sent a notice, because its engine already tells its own agent and stops a loop that persists.

#What this release does not cover

The notice tells the agent. It does not pause the run. Pausing stays with the workspace's no-progress limit, and in observe mode nothing pauses.

The loop rules read a chain's last 32 calls. A loop that repeats more slowly than that can fall outside the window. A failing retry earns a row in the panel but no notice, because a failing call's results need not match. An MCP tool never counts as stagnating, since a server may answer every call with the same text by design.

The notice state lives in the recorder's memory. A restart starts it over, so the worst case is a second notice for the same loop.

These records come from the hooks on the agent's machine. Oxagen's docs state that hook-based records are vouched for only by the machine that sends them, and that the person who owns that process can remove the hooks.⁶ A run you read on the Run page is as complete as the hooks that reported it.

The release post for Oxagen 5.5 lists the other changes in this version.