When an agent stops and asks

Every other agent in a factory is allowed to be uncertain because there is somewhere for the uncertainty to go. Take that away and each one has two options left: guess, or fail the run. The escalation path is what puts a third option on the table — and it is the piece most teams find they have not built on the day the first agent needs it.

What makes an agent stop, and what it writes down#

Four things block a run and only one of them is a failure. Requirements that contradict each other, where the work item asks for one behaviour and its acceptance criteria describe another. A product decision the agent has no standing to make: when a cancellation rule changes, what happens to the orders already shipped is not a question about code. Missing access — a credential, a schema, a test account nobody seeded. And the plain case of having failed too many times.

That last one is why a repair loop needs a cap and the cap needs somewhere to point. A builder rewriting the same failing test has usually learnt nothing by its fourth attempt that it did not know by its second. A cap with nowhere to escalate to is just a run that gives up, which is worse than one that fails loudly, because nobody is told.

Whatever the trigger, the agent records the same four things, and the structure is doing most of the work. Why it stopped, in a line. The specific question — not the area of doubt, the question. The options it can see, each with what it would cost. And the context needed to answer without going and finding it: the file, the failing assertion, the two sentences that contradict each other, a link to the run.

The options field is the one that gets dropped and the one that earns its keep. A question with nothing attached is a request for somebody else to do the thinking, and it lands on a person holding less context than the agent that asked. Should orders shipped before the change be treated under the old rule?, with two options and their consequences underneath, is a thirty-second answer typed on a phone. The same question alone is twenty minutes of archaeology.

How much of this to expect is worth knowing in advance. The most thoroughly documented public factory — ten streaming days, several hundred merged changes, most of them executed with nobody in the loop — reports unclear requirements as its single biggest cause of failure, and that was a greenfield product with no history behind it.

The resume is the half nobody builds#

Asking is the easy half. Most teams that build an escalation path build the question and stop there, then find out a month later that answers have been sitting in the tracker with nothing reading them. The resume is separate software and somebody has to write it.

It should be unremarkable to use. A person answers in the tracker exactly as they would answer a colleague: a comment, a transition back to ready, nothing ceremonial and nothing they needed training for. A small automation notices, appends the answer to the item’s context, clears the block, and puts the work back in flight.

That is not free; it follows from where a run’s state lives. If a run is a process holding its context in memory, blocking means either keeping that process alive for three days or throwing the work away. Put the state where the orchestrator can find it and the process becomes disposable. A factory where escalating means losing the run is a factory where nobody escalates, and the pressure goes straight back onto the agent to guess.

An escalation with no named recipient is a message to nobody. It goes to the team owning the affected service, or to whoever owns the product decision — a lookup, not something the agent infers from the shape of the question. That table is a prerequisite rather than a detail: without it every question lands in one general queue and the queue becomes the bottleneck. Attach a window as well — if nobody answers inside an agreed time the item escalates further, to a named person rather than a wider audience.

The person answering must never have to understand the factory. They are answering a question about the product or the code, and that is the whole of it. Which agent asked, what a lease is, how anything gets restarted: none of it should reach them. If answering requires knowing how the machine works, the machine has pushed its complexity onto the people whose time it was built to save.

And the requeue decides nothing. It routes, and it resumes. The moment it starts inferring an answer to unblock itself — reading a vaguely approving comment as a yes, defaulting to the first option after a timeout — every guarantee resting on it is gone, because no point in the system now requires a person’s judgement rather than merely inviting it.

How a fleet stops asking#

The first failure is cultural and it kills the mechanism outright. Escalations get treated as delays — a bar on a dashboard to be driven down — rather than as findings about work nobody specified well enough to build. The fleet then learns, though not in the way the word suggests: somebody adds be decisive to the instructions, somebody widens what an agent may assume, and within a month the questions stop. The ambiguity is still there, resolved silently now, one run at a time.

Three measures are worth keeping and one of them is a trap. Escalation rate per agent shows which step is asked for more than its inputs support. Time to answer shows whether the routing works. Repeat-escalation rate — the same question again next week — shows whether answers get written back into the instructions or thrown away. The trap is the first: a falling escalation rate looks like improvement and is achievable by making agents more confident rather than more correct. Read it against change failure rate, because fewer questions and more broken changes in the same quarter is a fleet that stopped asking. DORA’s 2025 report describes that shape at industry scale: throughput and instability rise together as adoption grows.

Then there is the question that costs more to answer than to ignore. The requirements here are unclear names a feeling rather than a decision. By the time somebody has opened the branch, re-read the item and worked out what the choices were, they have done the work the agent was given and paid a context switch for it. Questions like that get answered late, answered badly, or quietly closed.

A queue with no owner is the third way this fails, and the quietest. Escalations arrive somewhere plausible — a channel, a board column, a label — and nobody is accountable for that column being empty on Friday. Items age there. Nothing alarms, because an unanswered question is not an error state; it is an absence, and absences page nobody.

Fourth, and the most awkward to discover: the answer that arrives and never lands. Somebody replies, considers it handled and moves on, while the run stays blocked because the resume path was never built — or was built, then broke silently when the tracker’s webhook was reconfigured. Count the items that carry an answer and are still blocked. Above zero for long means the loop is open and nobody noticed.

The opposite failure arrives when a team over-corrects. An agent that escalates whenever it is less than certain turns a factory into an expensive way of generating questions, and the queue that results teaches people to ignore it faster than any single bad question could. The threshold belongs in the instructions, stated as consequence rather than confidence: stop when being wrong would be expensive or hard to reverse, not when being wrong merely feels likely.

None of this makes the escalation path glamorous. It ships nothing, and the artefact of a successful escalation is a run that carried on. But every other agent here is trusted on one condition — that it stops when it should — and the next place that condition is exercised is the step that reads a change and declines to approve it. The stopping is the feature. The asking is only how it is spelled.