RabbitMQ vs Kafka vs NATS for AI Agents

Agent protocols do not replace the broker. The Model Context Protocol defines two standard transports, stdio and Streamable HTTP, and allows custom ones, so tool calls between an agent and an MCP server normally travel over stdio or HTTP rather than through a broker. The broker carries what sits around them: jobs queued for workers, results returned to the agent that asked, events fanned out to other agents, and a record of what happened. Each of those maps to a broker property: acknowledgement and redelivery, request-reply, routing, and retention with replay.

Agent tasks are slow, because a single step may wait on a model for minutes. RabbitMQ keeps a delivery until the consumer acknowledges it and returns it to the queue if the consumer disappears or exceeds the consumer timeout, which RabbitMQ 4.3 lets you set per queue or per consumer on quorum queues. Prefetch limits how many jobs one worker holds. Python teams usually reach this through Celery; our Celery and RabbitMQ guide for LLM task queues covers the settings.

Kafka consumer groups track one committed offset per partition, so a slow record usually delays the records behind it in that partition. Share groups, production-ready in Kafka 4.2, let several consumers work the same partitions with per-record acknowledgement and delivery counting; the record lock is 30 seconds by default, configurable up to an hour, and 4.2 added a renew acknowledgement for longer processing. NATS JetStream redelivers after AckWait, 30 seconds by default, and an in-progress acknowledgement resets the timer for long jobs. A WorkQueue stream deletes each message after one acknowledgement.

When an agent calls a tool over a broker it needs the answer back. NATS has request-reply in its core protocol: the client creates a private _INBOX subject, the responder replies to it, and if nobody is subscribed the server signals no responders at once rather than letting the caller time out. Synadia's open-source Agent Protocol for NATS builds agent discovery, streamed replies and heartbeats on these primitives and documents its delivery as at-most-once. RabbitMQ Direct Reply-To delivers replies to the requester's channel without creating a reply queue, which keeps request-reply cheap at tens of thousands of clients. Kafka has no request-reply primitive; applications pair a request topic with a reply topic and correlate the messages themselves.

Routing decides which agent or worker pool gets a task: by skill, model, tenant or GPU class. RabbitMQ does this on the broker. A topic exchange matches routing keys such as agent.summarize.gpu against bindings with * and # wildcards, so a new specialist agent is a new binding and producers do not change. NATS subjects give similar flexibility with * and > wildcards, and queue groups spread requests across instances of one agent. Kafka routes by topic and partition key; finer selection happens in consumers or in stream processing, which suits fan-out of events better than dispatch of individual tasks.

Replay matters when a new agent must catch up on history or a run must be audited. It is Kafka's core design: records stay until retention removes them, seven days by default, and every consumer group reads at its own offset, in order within a partition. RabbitMQ streams and NATS JetStream streams both offer non-destructive reads and replay; RabbitMQ queues delete messages once acknowledged. For backpressure, RabbitMQ limits unacknowledged deliveries per consumer and blocks fast publishers through flow control, JetStream caps in-flight messages with MaxAckPending, and Kafka consumers simply pull at their own pace while the log absorbs bursts.

Vendors now ship agent tooling on top of these brokers. Described from each vendor's own pages:

• Confluent: Streaming Agents are event-driven agents that run on Flink in Confluent Cloud, with MCP tool calling and replay for debugging. Its open-source MCP server lets AI assistants work with Confluent Cloud, Confluent Platform and Apache Kafka; a fully managed version also exists.
• Synadia, the company behind NATS: the open-source Agent Protocol for NATS and agent SDKs for Python and TypeScript.
• Solace: Solace Agent Mesh, an agent development and runtime platform on Solace's event broker, with an open-source framework and support for A2A and MCP.
• StreamNative: Orca Agent Engine, in private preview, runs Google ADK and OpenAI Agents SDK agents on Pulsar and Kafka topics in StreamNative Cloud.
• Redis: Redis Agent Memory, in preview, stores session and long-term memory for agents. It is a memory service, not a broker.

Agents reach RabbitMQ through its standard clients and protocols, including AMQP 0-9-1, AMQP 1.0 and MQTT, and through task frameworks such as Celery.

Redis Streams give consumer groups, acknowledgements and claiming of stuck entries, which is enough for light task hand-off where Redis already runs; durability depends on persistence settings. Apache Pulsar offers Shared and Key_Shared subscriptions with individual and negative acknowledgements, closer to queue semantics than classic Kafka consumers. Amazon SQS needs no broker at all, but a message is invisible for at most 12 hours while a consumer works on it and is kept for at most 14 days.

1. Agents hand off long, expensive jobs that must not be lost? RabbitMQ with quorum queues, or Kafka share groups if Kafka is already the platform.
2. Tool calls and agent-to-agent requests across clouds, sites and devices? NATS.
3. Agents react to business events and new agents must replay history? Kafka.
4. Routing by skill, model or tenant without changing producers? RabbitMQ exchanges or NATS subjects.
5. A small team that wants one lightweight system for messaging, persistence and a key-value store? NATS with JetStream.

See RabbitMQ for AI workloads and the guide to RabbitMQ for AI agents for the RabbitMQ side in depth. AceMQ provides 24/7 RabbitMQ support and Kafka support, so the advice does not depend on which broker you pick.