Chapter Eight · Failure Modes

Failure Modes

Three weeks after launch Vera has a folder of incidents: an agent that called track_parcel nine times on a parcel nobody had scanned, a refund issued against an order belonging to a different customer, and a run that started a return, reserved a replacement and died before the money moved. Five topics on the failures an ordinary service does not have — how to sort them, how to detect them inside the loop, and what to build for each.

5 topics

Chapter 7 gave the loop four ways to stop and four names for how it ended: answered, escalated, exhausted, stuck. Those names say what happened to the run. They say nothing about what went wrong, and the uncomfortable number is that 74% of Sundry's failures ended answered — a fluent reply, a clean trace, a satisfied metric, and a customer who was told something untrue. This chapter is about the failures underneath the endings.

Five classes, cut where the defence differs rather than where the symptom does: control flow, grounding, judgement, boundary, and adversarial. Four of them are built for here; the fifth has its own chapter, because the input is written by somebody who wants your agent to misbehave. The chapter also closes the first wound properly. Chapter 3 stopped a retried refund from paying twice with an idempotency key, and Topic 45 generalizes it into the case the key cannot help with: a run that dies between two writes was never retrying anything, and there is no transaction spanning a returns service, a warehouse, a payment provider and an email.

What every guard in this chapter costs is small — a hash and a counter for repetition, eighteen lines of provenance checking before each write, an intent row committed before each side effect — and what they leave untouched is the largest class of all. Judgement failures were 44% of Sundry's 400 classified incidents and produced not one alert, because the tools were right, the arguments were valid, the run terminated cleanly and the decision was wrong. Nothing inside a loop detects that. Chapter 9 builds the instrument that does.

Five classes, cut where the defence differs — and only one of them reliably makes a noise
Control flowloud
Nine identical calls, ending at the turn limit. A hash and a counter catch it, and a limit is a metric.
Groundingmostly silent
A refund against an id nobody had looked up. Provenance against run state refuses it before the call leaves.
Judgementsilent · 44%
Right tools, valid arguments, clean ending, wrong decision. No guard fires; only a graded set sees it.
Boundarymostly silent
A return started, a replacement reserved, the run dead before the refund. Intent written down before each write.
Adversarialsilent by design
An instruction arriving as data and being followed. Somebody chose that input, so it gets its own chapter.

Topics in This Chapter

Topic 42
The Taxonomy of Agent Failure
Five classes with a Sundry incident each, and the reason the split is by defence rather than by symptom: a repetition guard cannot see a wrong decision, and argument validation cannot see a dropped subtask. Includes the measured distribution across 400 failed tickets, where judgement dominates at 44% and the loud control-flow failures alerted on every one of their tickets, 12% of the volume.
Failure Classes
Topic 43
Loops, Thrash, and Repetition
Three shapes — the same call twice, two tools alternating, and re-asking the customer something they already answered — detected by hashing the tool name with normalized arguments and acting on the second occurrence, not the ninth. The response that works adds information to the context rather than an instruction, and the per-tool repetition histogram turns out to be a product backlog nobody had to write.
Repetition
Topic 44
Hallucinated Tools, Arguments, and Facts
A tool that does not exist, an order id that was never looked up, and a delivery date nobody promised are one behaviour on three surfaces, each caught at a different boundary. Why a well-formed id that exists in the database is still the wrong check, and why the confident tone of a wrong answer makes human transcript review close to useless as a detector.
Grounding
Topic 45
Partial Failure and Rollback
Three actions, two committed, and four systems that never agreed to share a transaction — so the answer is intent recorded before acting, compensating actions with an honest list of what cannot be undone, and a per-task choice between resuming and compensating. Plus the test nobody writes: killing the process between two write calls, on purpose, in the suite.
Partial Failure
Topic 46
Timeouts, Rate Limits, and Backoff
The ordinary-backend page, said once and kept short: timeouts, jittered backoff and queues work here exactly as they do anywhere else. What is genuinely agent-specific is deadline propagation through a loop nobody wrote as one request, and the third retry layer no counter sees — the model asking again, which arrives looking like a new decision.
Resilience