Workflow Friction

Twenty minutes into a session, a terminal scrolling steadily looks the same whether the agent is closing in on a fix or circling one. Tool calls fire, files open, diffs render — activity, continuously. It is only when someone actually reads the last fifty lines that the shape becomes obvious: the same function, rewritten a sixth time, the same test still red, the same error message with one word changed. Nobody decided to let the session run this long without checking. It simply never stopped looking active enough to interrupt.

That gap — between a session that looks busy and a session that is stuck — is not a matter of taste. It has a mechanical shape, visible in the sequence of tool calls a harness already logs: which files were touched, in what order, with what result. A team that only watches token spend or wall-clock time cannot see it. A team that watches the trace can, in principle, catch it while the session is still running, rather than after the retro asks why a three-hour session produced nothing that merged. Workflow engineering, this volume’s subject, is not just designing the steps an agent takes — it is designing the instrumentation that notices when those steps stop going anywhere.

What a stalled session actually contains

A recent taxonomy built from 142 real agent traces across multiple benchmarks found that failures cluster into recognizable categories rather than arriving as one undifferentiated “the agent got confused.” Tool repetition — calling the same action against the same target with no new information between attempts — is one of the more common and more mechanically obvious of them, distinct from failures that originate in planning or in misreading the environment. That distinction matters for detection: a repeated, uninformative action is something a harness can flag from the trace alone, without any judgment about whether the underlying reasoning was sound.

The same idea shows up from a different angle in Anthropic’s own guidance on building agents: autonomy raises the ceiling on both outcomes and cost, because the autonomous nature of agents means higher costs and the potential for compounding errors — each unproductive step is not just wasted, it becomes the input to the next step, and a bad direction that goes uncorrected tends to compound rather than self-correct. Left alone, a stuck agent does not usually stop on its own; it produces more attempts, each one billed, each one plausible-looking in isolation.

Three shapes friction takes

In practice, most stalled sessions fall into one of three recognizable shapes. Edit thrashing is the same file, or the same handful of files, being modified repeatedly within a short window without the underlying problem converging — the agent rewriting, testing, rewriting, never quite landing. Search spiral is a long, unbroken run of read, search, and grep-type operations with no edit at all — the agent looking for something it cannot find, or exploring without any evident plan for when to stop looking. Error cascade is a run of consecutive tool-call failures — commands that error, tests that fail, edits that will not apply — where each failed attempt raises the odds the next one fails too, because the agent is now reasoning from a state it does not fully understand.

Where naive detectors go wrong

The obvious first implementation of any of these three checks is a counter: increment on a matching event, reset on the opposite one, alert past a threshold. It is also the version most likely to be wrong, and wrong in a specific, avoidable way — by treating the single most common healthy behavior as the failure signal. A search-spiral detector that counts every file read as “searching” will fire on an agent doing exactly what a competent engineer does at the start of unfamiliar work: opening five or six files in a row to understand how a system fits together before touching anything. That is not a lost agent. It is the ordinary shape of orientation, and a detector that cannot tell the two apart will be wrong constantly — which, past a certain point, is worse than having no detector, because the people it is supposed to warn learn to stop reading its warnings.

That failure mode is well documented outside AI tooling. Security operations centers have spent a decade fighting the same problem with intrusion alerts: a 2025 survey of that literature describes analysts facing high volumes of low-precision warnings who begin to second-guess, skim, or ignore incoming alerts — sometimes ignoring a genuine one masked by the noise. Google’s own internal guidance on alerting reaches the same conclusion from the operations side: a page that does not demand action should not page a human at all, because every unnecessary page spends down the trust the next, real one depends on. A friction detector that cries wolf is not a safer system than no detector. It is a system that trains its users to stop looking, which is the exact failure it was built to prevent.

A detector that never fires has taught its users nothing. A detector that fires too often has taught them to stop reading.

On the cost of a false positive, in alerting and in agent harnesses alike

Three design choices separate a detector that survives contact with a real session from one that gets muted within a week. First, windowing: count within a bounded time span — a few minutes, not an entire session — so a burst of activity from an hour ago cannot silently combine with one from just now to trip a threshold neither would have tripped alone. Second, distinguish operation types that look similar but mean opposite things — a file read while orienting is not the same event as a search for something that keeps not being found, and conflating them is precisely the search-spiral false positive above. Third, and the easiest to skip: give the counter a way to clear on genuine progress, not only by timing out. A successful edit, a passing test, a check that resolves — any of these should reset the streak, because a detector that only forgets through silence will eventually flag a session that recovered on its own several tool calls ago.

Long sessions make search spirals more likely for a reason beyond the agent simply losing the thread. Independent research on long-context model behavior has found that performance grows increasingly unreliable as input length grows — the same retrieval question, asked deep into a long session, is measurably harder for a model to answer correctly than the identical question asked early. A session’s own accumulated context, the material this Library elsewhere calls context debt, is not a passive backdrop to a search spiral. It is one of the things actively working against the search resolving.

A framework for the three patterns

Put together, the three patterns and their honest failure modes reduce to a small table — the signal worth counting, the healthy behavior most likely to be mistaken for it, and the event that should clear the flag.

What a harness can actually watch for

One production implementation of exactly this design runs inside a session harness built to test these ideas against real traffic rather than benchmarks: three checks, one per pattern above, each windowed and each cleared by genuine forward progress rather than only by a cooldown timer. Its own history includes the textbook version of the false-positive problem described above — an earlier version of its search-spiral check counted file reads as searches, with an unbounded streak that only reset on an edit, which meant a normal five-file orientation read looked identical to a genuinely lost agent. The fix followed the same three principles: reads stopped counting as searches, the streak became a count of distinct targets inside a bounded window, and any successful non-search step cleared it outright. The lesson generalizes past this one tool: it is the same discipline any anomaly-detection system needs, learned the same way most of them learn it — by shipping the naive version first.

Escalation, not shutdown

Detecting a pattern and acting on it are different design problems, and the second is easier to get wrong than the first. Auto-stopping a session the moment a threshold trips imports the false-positive risk of the detector into an action that is expensive to reverse in either direction: kill a session that was one edit from converging, and the cost of the false positive is now the discarded work, not just an ignored banner. The more defensible default is to surface a clear, specific alert at the moment it would help a human decide — which file, how many times, which error, repeated — and leave the decision to interrupt with the person who can see context the trace cannot capture. A session running against an explicit flight plan, the step-by-step trajectory this volume describes elsewhere, makes that judgment cheaper still: progress can be checked against a declared plan rather than inferred from tool-call shape alone.

A two-tier severity model earns its complexity here. A first occurrence surfaces as a warning — visible, dismissible, naming the specific evidence rather than a generic “something looks off.” If the same pattern reappears after being dismissed, or continues past a second window without resolving, it escalates to a harder-to-miss state — not because the mechanism changed, but because a dismissed warning that recurs has already answered the question a first warning could only ask. That asymmetry mirrors the SRE alerting principle directly: the problem was never that an alert fired once, it is a system that fires identically every time regardless of whether anyone has already seen and acted on it.

Building one of these

1. Log tool-call sequences at trace grain — name, target, outcome, timestamp — before attempting any pattern detection on top of them.
2. Window every counter to a bounded span. An unbounded streak is not a detector, it is a number that only ever goes up.
3. Separate operation types that look similar but mean opposite things, especially read versus search — this single distinction is where most false positives live.
4. Clear the flag on real progress, not only on silence. A passing check should reset the streak faster than a timeout does.
5. Warn first, escalate second, and treat auto-termination as a last resort reserved for cases where the cost of a false positive is genuinely lower than the cost of letting the session continue.

None of this requires a smarter model. It requires treating the harness itself as a system with its own failure modes — false positives among them — and designing for those failure modes with the same rigor a team would apply to the session it is watching.