Agent Communication Inside a Company: Real Scenarios for mq9

Picture a Scenario

Imagine a company with many Agents.

There are Agents for data analysis, Agents for report generation, Agents for customer service, Agents for approvals, Agents running on edge devices, and an Orchestrator Agent for coordination and scheduling. Each has its role; they need to collaborate.

Communication between these Agents comes in two forms:

Real-time communication — I ask you a question, you answer immediately. Both parties are online, one question and one answer.

Async communication — I send you a task, you reply when you're done. It's fine if you're not online; the message waits for you.

How do most companies handle this today? Real-time goes over HTTP, async is stitched together from Redis + Kafka + a custom queue. Two separate systems, each operated independently, with glue code in between to connect them.

---

With mq9

Deploy one RobustMQ instance, mq9 is ready. All Agent communication runs on a single protocol.

Orchestrator distributes tasks to Worker Agents:

nats pub '$mq9.AI.INBOX.worker-001.normal' '{"type":"task","content":"Analyze Q3 data"}'

If Worker is online, it receives the message in real time. If it's offline, the message waits in the mailbox. The Orchestrator doesn't need to know or care — send it and move on.

Worker completes the task and returns the result:

nats pub '$mq9.AI.INBOX.orchestrator.normal' '{"type":"task_result","result":"anomaly rate 2.3%"}'

The Orchestrator is subscribed to its own mailbox. When the result arrives, it processes it.

Critical alert broadcast:

A monitoring Agent detects an anomaly. It doesn't know who should handle it, so it broadcasts:

nats pub '$mq9.AI.BROADCAST.system.anomaly' '{"level":"critical","detail":"payment timeout rate 15%"}'

Every Agent subscribed to $mq9.AI.BROADCAST.*.anomaly receives it automatically and responds as appropriate.

Requires human approval:

An Agent encounters something that needs a human judgment call and sends it to the approver's mailbox:

nats pub '$mq9.AI.INBOX.approver-zhang.urgent' '{"type":"approval","content":"requesting access to external API"}'

When the approver has time, they open their mailbox, make the decision, and send the result back to the Agent's mailbox. Humans and Agents use the same protocol.

Edge device goes offline:

The cloud sends a command to an edge Agent while the edge device is disconnected:

nats pub '$mq9.AI.INBOX.edge-001.urgent' '{"command":"emergency_stop"}'

The message is persisted in the mailbox. When the edge device reconnects, urgent messages are processed first, normal messages follow. QUERY provides a fallback pull to ensure nothing is missed.

Capability discovery:

A new Agent arrives and doesn't know who in the company has data analysis capabilities:

nats pub '$mq9.AI.BROADCAST.capability.query' '{"need":"data.analysis"}'

Agents with that capability respond to the requester's mailbox. Decentralized — no registry needed.

---

One Protocol for Everything

You'll notice that all the scenarios above — real-time, async, point-to-point, broadcast, human-Agent hybrid — are handled by the same mq9 protocol, with four command words:

MAILBOX.CREATE              — request a mailbox
MAILBOX.QUERY.{mail_id}    — check for unread messages
INBOX.{mail_id}.{priority} — point-to-point communication
BROADCAST.{domain}.{event} — public broadcast

No need for HTTP for real-time, Kafka for async, and Redis for broadcast. mq9 covers all of it.

Why is this possible? Because mq9 is built on a pub/sub push model — if the recipient is online, the message is pushed immediately with millisecond latency; if offline, the message is written to storage first and pushed when the recipient comes online. Real-time and async are not two separate mechanisms — they're the same mechanism behaving differently depending on state.

Business logic doesn't need to decide "should this be sync or async?" Just send the message. mq9 handles the rest: push in real time if online, store and wait if offline.

---

The Relationship with A2A

If the company uses A2A (Google's Agent2Agent Protocol) to define the conversation semantics between Agents — Task structure, capability declarations, status updates — then mq9 serves as A2A's transport layer.

A2A defines how Agents talk. mq9 ensures the conversation arrives.

A2A decides when to go synchronous and when to go asynchronous — mq9 doesn't care. A2A's Task JSON is just the payload inside an mq9 mailbox; mq9 doesn't parse it, only delivers it.

It can be even simpler: if mq9's real-time push latency is sufficient for business requirements, all internal Agent communication can run entirely over mq9 without ever needing A2A over HTTP. One transport layer covering both sync and async — the simplest possible architecture.

---

The Essence

Back to first principles.

What message queues have been doing for twenty years is, at its core, async communication. mq9 is not inventing something new — it's taking that most basic thing, async communication, and doing it right for the Agent scenario.

Send it out, the other side receives it. No loss when offline, priority-aware, auto-cleanup when done. Real-time push when online, stored and waiting when offline.

mq9 is simply about doing Agent async communication well.

mq9 exists to solve the async communication problem for Agents.