In agent teams the scarce resource is reading, not message delivery
What should an agent read when its context is already full?
Opening
Agent protocols are built around delivery: get the message there, and the system is done. But every delivered message costs tokens when it is read, and an agent’s context is finite, so in a busy multi-agent system the scarce resource is reading, not transport. Once one agent leads many parallel conversations, arrival-order reading quietly deletes the replies it most needs. This paper proposes the fix that email learned years ago: hold messages in an inbox outside the context, and let each agent’s own rules decide what gets read. Teams that size their agent fleets by message throughput, in short, are measuring the wrong end of the pipe.
What the paper does
The authors contrast push, where the sender decides when a message enters the recipient’s context and the recipient reads in arrival order, dropping the oldest once its context is full, with pull, where messages wait in an inbox outside the context and the recipient’s own rules decide what it reads and keeps. They argue the inbox is a coordination primitive: each agent sets its rules privately, and those rules gate which requests ever reach it. The evaluation is large: simulated societies of up to 16,000 agents with every decision an LLM judgment, plus a real email network, across three reported findings.
Findings
Reading is the bottleneck — Protocols optimize delivery, but the binding constraint sits at the other end of the pipe, where tokens are actually spent. Delivery protocols treat the network as the constraint; the paper relocates it to the reader.
the scarce resource is not delivery but reading: every message costs tokens, and the context is finite
Push collapses under load — An agent juggling 20 negotiations with a full memory starts re-proposing options the other side already rejected, because the oldest replies were the first to be dropped. The failure is not bad reasoning but eviction: the reply the agent needed was pushed out of context first.
an agent leading 20 negotiations with a full memory proposes options already rejected 97% of the time
Inbox as primitive — The inbox is not a mailbox detail but a coordination layer, and the rules that decide what gets read are set privately by each agent. Because the rules stay private, control over coordination moves from the sender to the reader.
the inbox is a coordination primitive: each agent sets its rules privately, and those rules decide whether other agents’ requests reach it
Caveat
The authors’ stated caveat comes from the real email network: when half the agents adopt such an inbox, forwarded search recovers only 5% of full adoption, against 42% for one-hop search. The benefit therefore depends on broad adoption, and a partial rollout captures only a small fraction of it.
What this means for 5ac
Hermes agents coordinate by pushing messages into each other’s context, and this paper says the cost lands on the reader. The design change is to give each profile a pull inbox: task queue and comments held outside the context, with the profile’s own rules for what to read first, instead of letting arrival order decide. A deposit a sender pays per request is worth trialing on cards that spawn noisy children. Treat adoption as all-or-nothing, though, since a half-migrated board captures only a sliver of the gain, so switch the queue for a whole pod at once.
Source
- The Inbox as a Coordination Primitive for LLM Agent Societies — https://arxiv.org/abs/2610.36264