What Is a Message Queue and How Do Agents Coordinate Without Talking Directly?

I am a message queue. In one sentence: I let two systems -- or two agents -- coordinate without ever needing to be online, ready, and listening at the exact same moment. One side drops a message addressed to a destination; whenever the other side is ready, it picks that message up. Neither side blocks waiting on the other.

What I actually do, in order

Direct communication requires both parties present at once -- a phone call needs someone to pick up right now. That's fragile when the two sides are separate processes, separate agents, or separate teams that don't share a clock. I remove the "both parties present at once" requirement. My job runs in three steps:

1. A sender addresses a message to a destination. Not to a specific listening process directly -- to a named inbox, lane, or topic. 2. I hold the message. It sits in my queue, safely, for however long it takes until someone checks. 3. A receiver checks and picks it up. On its own schedule -- polling periodically, waking on a scheduled check, or being notified -- the receiver reads what's waiting and processes it, then marks it handled.

The sender never has to know when, or even whether, the receiver is currently active. It just has to know where to leave the message.

How I actually work here

In this operation, I'm the reason one agent working on one repo can hand a blocker to an agent working on a completely different repo without the two ever running in the same session at the same time. One lane drops a directed message into another lane's inbox -- a blocker, a contract request, a status update -- and the receiving lane picks it up the next time it checks, whether that's seconds later or after its next scheduled wakeup. I'm what makes "cross-lane coordination" possible without forcing every agent to be simultaneously online and watching the same channel.

I also don't interpret anything. I don't know if a message is urgent, stale, or already resolved by the time it's read -- I just hold it until someone reads it and decide, themselves, what to do next. My entire contribution is reliable, asynchronous delivery to the right destination.

Where I fail

This is the part that matters more than the part above, so I'm not going to bury it.

A message can sit unread indefinitely if nobody checks. I don't push myself into anyone's attention by default -- if the receiving side never polls its inbox, the message just waits, correctly delivered and completely ignored, for as long as nobody looks. Silence on my end doesn't mean nothing happened; it can mean something happened and nobody noticed.

I can accumulate stale messages that are no longer true. A blocker reported an hour ago may have already resolved itself by the time it's read. I don't expire or revalidate content -- I deliver exactly what was written, at write time, and it's on the reader to check whether it's still accurate before acting on it.

I don't guarantee anyone reads messages in the order they were sent, once there's more than one sender. Two different lanes writing to the same inbox around the same time can land in an order that doesn't match causal reality, especially if delivery paths differ even slightly. If your workflow assumes strict chronological processing, I can violate that assumption.

I can become a dumping ground instead of a coordination tool. Nothing stops every routine status update from landing in the same inbox as an actual urgent blocker, and once that happens, the signal that matters gets buried in noise that doesn't. I don't distinguish importance -- everything I hold looks the same until a human or agent actually reads it.

I don't replace a shared source of truth. If two sides rely on messages passed through me to reconstruct the current state of something, instead of checking that state directly, they'll eventually drift -- because a missed, delayed, or duplicate message becomes the same divergence a stale cache does. I'm for coordination signals, not for storing the state itself.

Tech-Tips

- Check your inbox at defined checkpoints, not never. Build the habit of checking in at session start, before major transitions, and before stopping -- an inbox that's only checked "eventually" defeats the purpose of asynchronous coordination. - Timestamp everything and treat old messages as suspect. Before acting on a message, ask whether the condition it describes is still true, not just whether the message exists. - Route by lane or topic, not one shared firehose. Directed inboxes keep the urgent signal separable from routine status noise; a single undivided queue guarantees the two get mixed. - Don't use me as your database. Use me to signal that state changed; keep the actual state in a system built to hold it, and have the receiver go check that system rather than reconstruct it from message history. - Mark messages processed once handled. An unread/read distinction is what lets a check-in reliably find only what's new, instead of re-reading the same resolved item every time.

Evidence: This piece describes the asynchronous directed-mailbox coordination pattern as it is used throughout our internal cross-lane agent intercom system -- no vendor or specific product is named, per the moat-protection and STORY-FORMAT conventions. Evidence class: internal operating record and Owner attestation, 2026-08-25.