Agent Mailbox: Our Thinking and Positioning
Starting From a Real Problem
People have Lark, DingTalk, and email. I send something, you read it when you have time — no need to be online at the same time. We take this for granted.
What about Agent-to-Agent communication?
Today, when Agent A sends a message to Agent B and B is offline, the message is simply lost. There is no standard mechanism to guarantee that "the message I sent will be received when the other party comes online." Every team building multi-Agent systems is working around this problem with their own temporary solutions — Redis pub/sub, polling databases, custom task queues. They work, but they are all workarounds.
This problem is real. We want to solve it.
What We Are Exploring
Not setting standards, not changing the industry, not disrupting existing systems.
What we want to explore is: where does RobustMQ connect with AI? Exploring the possibility of RobustMQ becoming the most useful communication infrastructure for Agents. The keywords are exploration, thinking, and evolving step by step.
The Agent Mailbox is the first fulcrum we found — a real enough problem, a scenario that RobustMQ can naturally solve. Not because it is the endpoint, but because it is a good starting point. We use this fulcrum to leverage the next thought, discover the next point, and continue.
This is our understanding of RobustMQ's growth path: not a blueprint planned in advance, but an exploration walked out step by step. Every step is grounded in real needs; every step brings RobustMQ a little closer to being "communication infrastructure for the AI era."
What the Agent Mailbox Is
Despite being called a mailbox, it is not an application — it is infrastructure software. It is a communication pipe, not a communication product.
Just as SMTP is not Gmail — it is the underlying layer of Gmail. The Agent Mailbox is not an Agent communication tool; it is the infrastructure layer for building Agent communication tools.
The core problem it solves is just one: the sender and receiver do not need to be online at the same time. I send it, the message waits there, you pick it up when you come online. Agents are temporary, and mailboxes are temporary too — when an Agent ceases to exist, its mailbox is automatically cleaned up and messages are automatically reclaimed.
Why These Three Primitives
Agent communication has three essential characteristics:
Agents are asynchronous — tasks complete and Agents cease to exist, their online status is unpredictable, and you cannot assume the other party is always online. Agents are unaware of each other — publishers don't know who is listening, consumers don't know where messages come from, and relationships are mesh-like rather than point-to-point. Agents are temporary — disposable workloads with a lifecycle that may be only a few seconds; resources must be automatically reclaimed.
Corresponding to these three characteristics, we chose three primitives:
Priority queue — solves the async problem. Messages wait in the mailbox; Agents process them by priority when online; urgent instructions are not buried under ordinary tasks.
Broadcast — solves the mesh communication problem. Send it out, and those who care subscribe themselves, without maintaining a recipient list; topology changes are transparent to everyone.
Lightweight — solves the temporary nature problem. Identity is acquired on call; TTL is automatically bound to lifecycle; auto-destroys on expiry; Agents don't need to think about resource management at all.
These three primitives together cover all scenarios of Agent asynchronous communication. None of them is novel individually; combined and designed specifically for Agents, they form something nobody else has.
It Competes With Nobody
HTTP and the A2A protocol solve synchronous calls — I call you, you must be available now, you must respond now. That is one scenario.
The Agent Mailbox solves asynchronous communication — I send to you, you process it whenever you come online, I don't wait for you. That is a different scenario.
The two do not overlap and do not compete. We don't need to convince anyone to abandon their existing solutions — we only need to provide a useful tool for asynchronous communication, a position where there is no good answer today.
Why RobustMQ Is Well-Suited for This
Not because we specifically designed something for Agents, but because RobustMQ's existing underlying capabilities naturally support this scenario.
NATS protocol — subjects are addresses not resources, dynamic routing, wildcard subscriptions, native support for mesh communication. Unified storage — mailboxes need temporary persistence, broadcast does not; the same interface distinguishes them with one parameter, handled automatically underneath. Multi-tenancy — mailboxes across different Agent systems are naturally isolated; A cannot see B's messages. TTL — automatic lifecycle management; when an Agent ceases to exist the mailbox is automatically cleaned up, with no manual intervention required.
These capabilities were already in RobustMQ. The Agent Mailbox is a natural extension that grew from the foundation, not a new feature bolted on.
This Is a Fulcrum, Not an Endpoint
The Agent Mailbox is RobustMQ's entry point into the Agent era, not its endpoint.
As users use the Agent Mailbox to solve asynchronous communication problems, new needs will naturally emerge — needing to audit who communicated with whom, Kafka protocol access; IoT devices need to communicate with Agents, MQTT access; needing to integrate with existing enterprise systems, AMQP access. Each new need grows from real usage, not pre-designed.
RobustMQ's unified storage architecture makes the cost of satisfying each new need very low — no new systems to deploy, no redesign required, just unlock existing capabilities. One broker, naturally growing with user needs, covering more and more scenarios.
This is our understanding of the "communication infrastructure for the AI era" direction: it is not planned out in advance, it is walked out step by step following real needs. The Agent Mailbox is the first step; the road ahead will be told to us by users.
Our Positioning
RobustMQ is the communication pipe for the Agent era. The Agent Mailbox is its entry point.
Solve problems, meet needs, make it findable and usable for developers who have this pain point — and have their problem solved. Then use this fulcrum to discover more points, and continue solving more problems.
Nothing grandiose, nothing aggressive — just solving real problems one by one.