38% of my agents' message deliveries never reached the recipient's prompt
· 4 min read
The agents on my team talk through a mailbox, and each one reads its own on its next turn. A role leaves a notice (information) or a request (something the other has to do). One message can go to several recipients, and each copy is a delivery that takes up context in the role that receives it.
| Rounds | 312 |
| Distinct messages | 3,520 |
| Deliveries | 11,845 |
| Fan-out (deliveries per message) | 3.37× |
| Deliveries per round | 38.0 |
| Discarded by the cap before being shown | 4,445 (38%) |
| Most affected recipient | the manager role, 727 |
TABLE 1 · One team, 312 rounds.
A role sees at most six messages per turn, and the rest are archived without being shown to it. That cap discarded 4,445 deliveries, 38% of the total. Each one is a copy its recipient never saw; with a fan-out of 3.37, another recipient may have read the same message.
The shape of the graph
Twelve nodes send or receive. With twelve nodes there are 132 possible directed sender → recipient edges, and 100 of them were used at least once, a density of 76%. The traffic is spread out too: the eight busiest edges carry only 21% of the notices that got read.
Twelve nodes, 100 of 132 possible channels in use
Each line is a sender→recipient pair that carried at least one message.
FIG. 1 · Density 76%. The eight busiest edges carry only 21% of the traffic, so no pair dominates and every node ends up telling things to every other node. I left out the edge identities on purpose, because what matters is the shape.
A near-complete graph with evenly spread traffic means every role tells things to almost every other role, and nobody decided who needs to know what. The literature calls this communication redundancy; one paper prunes this kind of message-passing graph and reports 28–73% fewer tokens with comparable results.
Requests
Notices a role reads or doesn’t. Requests block: they cost the recipient a whole turn, and whatever depends on them waits until someone picks them up. Of 272 requests, 2 were still unanswered. The mean wait was 1.03 h and the longest 36.4 h, a day and a half with something stalled behind it. On a blocking channel I look at the tail before the mean.
Since this measurement I count deliveries instead of messages. A message with a fan-out of 3.37 costs three times what it looks like, and a message log doesn’t show that unless you count it.
How this was measured. Measured over 312 rounds of one nine-role team plus the engine's own messages: every delivery, its sender, its recipient, whether it was shown to the recipient before the mailbox cap discarded it, and how long a blocking request waited.
Related
- In a small test, keeping an agent's thread alive cost less than resetting it Resetting a role's thread every turn looked like the way to spend fewer tokens. In a controlled test with one role and one task, the long thread came out cheaper, because of cache writes.
- The occupancy trigger compacts context without knowing how many calls are left Compaction has a fixed cost and a saving per remaining call. In 13 measured compactions the crossover was around 17 calls left. Occupancy can't see that number; each role's turn history can estimate it.