Is mailbox the right abstraction?
One question keeps coming back while building mq9: is mailbox the right abstraction?
Not questioning whether agents need async communication — that part has never been in doubt. Agents go offline, restart, collaborate with other agents across time. Async is a hard requirement, not an option. What I keep questioning is the core abstraction I chose for agent communication. Did I get it wrong? Is there a better option I haven't thought of?
I've been turning this over for a long time. Writing it out today, partly to think it through, partly because someone else might see it more clearly than I do.
In infrastructure work, getting the abstraction wrong is a foundational mistake. Bugs can be fixed, performance can be tuned, docs can be improved — but if the core abstraction is wrong, everything built on top of it sits on a bad foundation. So I've taken this seriously. I actually listed out every plausible alternative and asked myself, one by one: why not this?
Event/EventBus was the first candidate. Agents emit events, other agents subscribe to what they care about, loosely coupled, sender doesn't need to know the receiver. Looks reasonable on the surface, but there's one thing I can't get past: events have no identity. A message doesn't belong to anyone. "Send a message to Agent B" and "broadcast an event type" are two different things. The first treats B as a communication target; the second treats B as an interested listener. These are different semantics in agent collaboration, and events only cover the second.
Channel was the second. A dedicated channel between two agents, point-to-point, intuitively clean. But a channel requires an established connection upfront, and if the agent goes offline, the channel breaks. Agents restart frequently, get redeployed, go dormant — the channel lifecycle and the agent lifecycle don't align.
Inbox/Outbox was the third — a database pattern where each agent has its own inbox table, messages get written in, the agent polls. Durable, reliable, but no push semantics, no priority, and every team using it ends up rebuilding the same scaffolding. Hard to turn into an infrastructure-layer abstraction.
The closest match is Actor mailbox, from the Erlang/Akka model. Each actor has a mailbox, messages are delivered into it, the actor processes them at its own pace. This model has been in use for forty years. mq9's design is most similar to this — the difference is that Actor mailbox lives in process memory. When the actor dies, the mailbox is gone. mq9's mailbox lives in persistent storage. When the agent goes offline, the messages wait.
After going through all of that, I keep arriving at the same place: every other abstraction describes how messages flow. mailbox describes the existence of an entity that has an address.
But I'm not sure if that's a genuine insight or just confirmation bias after already committing to the idea.
Sometimes you consider every alternative and still come back to where you started. That might mean the starting point was actually the best answer. Or it might mean you never thought of the real alternative. From the inside, these two situations are hard to tell apart.
After all of this, the best answer I can give myself is: every other abstraction describes the movement of messages. Only mailbox describes the existence of an agent.
The most essential characteristics of an agent are that it has identity, memory, and intermittent presence. Event can't capture that. Channel can't capture that. Inbox/Outbox gets part of it, but not all. mailbox is the only abstraction I've found that naturally carries all three — mail_address as identity, message persistence as memory, offline buffering and ordered replay as the handling model for intermittent availability.
But I'm still not sure whether that's a real insight or self-justification. Sometimes you think through every alternative and come back to the same place — either because it genuinely is the best answer, or because you never imagined the real alternative. Hard to tell from the inside.
Maybe someone thinks about agent communication from a completely different angle. Maybe there's a better design somewhere that I haven't come across.
If you think mailbox is wrong, or if you have a better idea, I'd like to hear it.