Skip to main content

The Agent That Deadlocked Waiting on Another Agent

· 9 min read
Tian Pan
Software Engineer

A researcher agent asks a retrieval agent for a document. The retrieval agent, mid-task, decides it needs the researcher to clarify the query before it can search. The researcher, waiting on the document, won't respond until it has the document. Neither one is broken. Neither one is looping. They are both politely, indefinitely, waiting for each other — and your orchestrator, which has no concept of "both of these are blocked on each other," will happily hold that state until a timeout you never configured finally fires, or until a human notices the run has been "in progress" for forty minutes.

This is a deadlock. It is one of the oldest failure modes in computing, and it has nothing to do with how smart your model is. It is a property of how work is coordinated, not how work is done. The uncomfortable finding from the last year of multi-agent research is that most of what breaks in agent swarms breaks here, in the coordination layer, not in the reasoning of any single agent.

Single-agent thinking never surfaces these bugs. When one model runs a loop of tool calls, the worst it does is spin — and a spinning loop is at least visibly spinning. The moment you have two or more agents that can wait on each other, you have inherited the entire back catalog of distributed-systems pathologies: circular wait, livelock, lost messages, premature termination, races on shared state. Nobody sat down and decided to build a distributed system. You built one anyway the day you added a second agent.

Coordination Is Where the Failures Actually Live

The instinct when a multi-agent system misbehaves is to reach for a bigger model. That instinct is usually wrong. The large-scale trace studies published over the past year keep landing on the same split: system-level failures cluster in coordination and specification, not in raw capability.

The most cited of these — a taxonomy built from over 1,600 annotated execution traces across seven popular agent frameworks, with strong inter-annotator agreement — sorts fourteen distinct failure modes into three buckets. Specification problems account for roughly 42% of failures: ambiguous roles, undefined tasks, missing constraints. Coordination breakdowns account for another 37%: communication failures, state desynchronization, agents unaware of when to stop. Verification gaps make up the remaining 21%. Notice what is not on that list: "the model wasn't good enough." Production multi-agent systems have been measured failing somewhere between 41% and 87% of the time depending on the task, and the dominant cause is that the agents cannot reliably coordinate — not that they cannot individually think.

Deadlock is the sharpest instance because it is the one distributed-systems engineers recognize on sight. A contention benchmark that put five agents in a room and made them compete for shared resources with no inter-agent communication measured deadlock rates ranging from 25% to 90% across frontier models on the same task. The spread across models tells you this is partly behavioral. The fact that even the best model deadlocked a quarter of the time tells you it is structural. You do not prompt your way out of a circular wait.

The Four Ways Agents Get Stuck

It helps to name the specific stalls, because each one has a different fix and they are easy to conflate under the lazy label "the agent hung."

Deadlock is the circular wait. Agent A holds resource X and needs Y; Agent B holds Y and needs X. Neither yields. In agent systems the "resource" is rarely a database lock — it is more often a piece of context, a decision, or a turn in the conversation. Agent A won't answer until B confirms; B won't confirm until A answers. The classic Coffman conditions still apply: mutual exclusion, hold-and-wait, no preemption, and circular wait must all be true. Break any one and the deadlock cannot form.

Livelock is worse to debug because the system looks busy. Two agents keep responding to each other, keep taking actions, keep burning tokens — but the global state never advances. A planner hands work to a critic, the critic bounces it back with a note, the planner reformulates and hands it back, forever. Every span looks healthy. Your token bill is the only symptom, and it arrives at the end of the month.

Cyclic handoffs are the routing version of the same disease. Agent A decides this task belongs to B, B decides it belongs to C, C decides it belongs back to A. Each handoff is locally reasonable. The cycle is only visible if someone is tracking the whole path. Step repetition — the same action re-executed because history got lost between hops — shows up in traces as one of the single most common failure modes, on the order of one in six failing runs.

Both-waiting-for-a-tool is the resource-contention flavor. Two agents need the same rate-limited API, the same file lock, the same downstream service that only allows one caller. Without an allocation discipline, they either collide or they each back off waiting for the other to go first, and the polite version of collision is a stall.

Why Your Orchestrator Doesn't Notice

Here is the part that catches teams off guard. The reason these stalls run for forty minutes instead of failing fast is that most agent orchestrators have no model of "blocked."

Loading…
References:Let's stay in touch and Follow me for more thoughts and updates