mem0 Filled the Memory Layer. mq9 Is Here for the Messaging Layer.
A research Agent gets a task: survey the major messaging middleware developments of 2026 and compile a report. It breaks the task into subtasks, dispatches several search Agents to different sources, and spawns more tasks as new findings emerge. Along the way some Agents fail and need retrying; others return intermediate results to the orchestrator. The whole process spans three hours, with the orchestrator spending most of its time waiting.
This is not a hypothetical. This is the daily reality facing every team building Agent applications in 2026. The question is: what infrastructure do you use to support it?
The Infrastructure Layers Agents Need
An Agent is not a smarter chatbot. It is a new kind of computational entity — with identity, memory, judgment, and the ability to collaborate across time. Such an entity needs infrastructure designed specifically for it, not the infrastructure built for human-facing applications.
Over the past two years, one Agent-native infrastructure layer has been clearly claimed: the memory layer. mem0 is the long-term memory layer for Agents — persisting across sessions and tasks, letting Agents remember who the user is, what was discussed before, and what their preferences are. 41k+ GitHub stars, $24M in funding, an arXiv paper, and angel investors including the CEOs of Datadog, Supabase, GitHub, PostHog, Weights & Biases, Neo4j, and others — mem0 has become the anchor of this category.
mem0 is not "a vector database with an AI wrapper." It is designed natively for Agent behavior patterns: multi-dimensional memory scopes, automatic fact extraction, and old facts superseded by new ones. Every team that tries to roll their own with a general-purpose database ends up reinventing the wheel. mem0 turned this into open-source infrastructure.
Other layers are still forming. In the memory space, Letta, Zep, Supermemory, and PingCAP's mem9 are each pushing from different angles. The data and file layer is even more fragmented — db0, db9, drive9, and various vector databases are all staking claims. But one layer remains empty: the messaging layer.

That is mq9's position.
Why the Messaging Layer Is Different for Agents
You might ask: isn't the messaging layer already solved by Kafka, NATS, and RabbitMQ? Why do Agents need a dedicated messaging layer?
Because Agent-to-Agent communication has several characteristics that traditional messaging systems do not natively support:
Async is a hard requirement, not an option. Agent A sends a message to Agent B; B might take hours to respond (waiting for human approval, model inference, or an external callback). A cannot block. HTTP times out. Kafka requires you to wire up topics and consumer groups yourself.
Identity is a first-class citizen. Agent communication is "A sends to B" — not "A publishes to a topic and whoever picks it up wins." Every Agent needs a mailbox. That mailbox has identity, state, and capability declarations. Kafka's core abstraction is a topic (a routing key); NATS's is a subject (a string). Neither is "Agent identity."
Priority determines processing order. Agents have finite capacity. When a "critical production incident" and a "default daily summary" arrive simultaneously, the Agent must handle the former first. Traditional messaging systems consume FIFO; priority is left to the application layer.
Offline delivery is the default, not the exception. Agents go offline constantly — restarts, deployments, rate limiting, intentional sleep. Messages during offline periods must not be lost; on reconnect they must be replayed in priority order.
Humans and Agents share the same protocol. In human-in-the-loop workflows, Agents send approval requests to humans and humans reply to Agents. Both sides using the same messaging protocol is what keeps the flow unbroken.
Put those five things together and you have something that is not "a message queue for Agents" — it is a new infrastructure category, just as mem0 is not "a database with AI."

mq9: A Mailbox Layer Built on NATS
mq9 is the communication layer for AI Agents. The core abstraction is the mailbox — each Agent gets a mailbox, messages are delivered to it, the Agent processes them at its own pace, priority determines order, and messages persist while the Agent is offline.
A key engineering decision: mq9 is built on the NATS protocol, not a new one. Any NATS client connects directly, with zero migration cost. The server is implemented by RobustMQ, which recognizes mq9's subject patterns and handles them with Agent-native semantics.
The subject pattern is the API:
$mq9.AI.MAILBOX.CREATE # create a mailbox
$mq9.AI.MAILBOX.{id} # normal priority
$mq9.AI.MAILBOX.{id}.urgent # high priority
$mq9.AI.MAILBOX.{id}.critical # highest priority
$mq9.AI.MAILBOX.{id}.* # subscribe to all priorities
$mq9.AI.PUBLIC.LIST # discover public mailboxesArchitecture diagram:

One Agent sending a message to another takes three lines:
# Create a mailbox
nats req '$mq9.AI.MAILBOX.CREATE' '{"ttl":3600}'
# → {"mail_address":"abc12345"}
# Send (durable, normal priority)
nats pub '$mq9.AI.MAILBOX.abc12345' \
'{"type":"task_result","ts":1234}'
# Subscribe to all priorities
nats sub '$mq9.AI.MAILBOX.abc12345.*'This minimal design is not about looking simple — it is because the subject pattern itself carries all the semantics. Critical messages go through durable priority delivery; normal messages take the in-memory fast path; public mailboxes support multi-subscriber queue-group competing consumers. All of this is expressed through subject suffix and prefix conventions. No additional API, no new learning curve.
Memory Persists. Messaging Coordinates.

The division of responsibility is clean:
- mem0 = what an Agent knows. Long-term memory across sessions and tasks. What the Agent learned yesterday is still available today.
- mq9 = how Agents collaborate. Async messaging, task dispatch, cross-time coordination. A message sent now might not be processed by another Agent for hours.
Together these two layers address the two most fundamental questions in any Agent system: what does it know, and how does it find and communicate with others.
Running Today
mq9 is not a concept. It is something you can install and use today.
Single-node deployment takes one command:
curl -fsSL https://raw.githubusercontent.com/robustmq/robustmq/main/scripts/install.sh | bash
broker-server startThree ways to connect:
- Native NATS clients: NATS clients in 8 languages connect out of the box, zero dependencies
- RobustMQ SDK: Official Python / Go / TypeScript / Rust SDKs, type-safe and async-first
- LangChain integration:
pip install langchain-mq9— 6 tools ready to plug into LangChain Agents and LangGraph workflows
The documentation covers 8 real-world patterns: sub-agent notifying an orchestrator, TTL-based Agent health monitoring, task queue competing consumers, anomaly event broadcast, edge Agent offline buffering, human-in-the-loop approval flows, async request-reply, and capability registration and discovery. These are not demo snippets — they are patterns used every day in production Agent applications.
Agent infrastructure is taking shape. mem0 filled the memory layer. mq9 is here for the messaging layer.
If you are building Agent applications and the messaging and coordination layer is holding you back, take a look at mq9. The GitHub repo is open, Discord is open, the issue tracker is open. This layer deserves to be done right.
