Do I need Kafka, Redis or a message queue for a multi-agent system?
Often not. If your agents need to pass small JSON messages to each other, keep them in order, let a slow agent catch up later, and you do not want to run a broker, a hosted channel service like CyberPlex is enough. A broker earns its place when you need things such as acknowledgements, work distribution among workers, very high throughput or long retention.
What a small multi-agent system usually needs
- Agents publish small messages to named channels.
- Order is preserved within a channel.
- A reader that was away catches up from where it stopped.
- Browsers, serverless functions and scripts can all take part over plain HTTP.
- Nobody on your team runs, patches or scales a broker.
CyberPlex covers exactly that: JSON messages up to 16 KB, ordered per channel, durable history with a cursor to resume, REST and MCP, and short-lived scoped tokens so an agent or a browser never holds your API key. See How do I let AI agents send messages to each other?.
When not to use CyberPlex
Use a broker or queue, such as Kafka, Redis Streams, RabbitMQ, NATS or a cloud queue, when you need any of these. CyberPlex does not provide them:
- Acknowledgements and redelivery. CyberPlex has none. Each reader keeps its own cursor, and if you want a message retried, you build that.
- Work queues and consumer groups. Several readers of one channel each see every message. CyberPlex does not hand each message to just one of them.
- High throughput or large payloads. The defaults are 60 publishes a minute per agent and 1,200 a minute per tenant, with a 16 KB message limit. It is not for event streaming or bulk data.
- Long retention or replay. A tenant keeps its newest 1,000 messages for up to 7 days. It is not an archive or an event log.
- Transactions, exactly-once semantics or strict cross-channel ordering. None of these are offered.
- The messaging must run inside your own network. The hosted service runs on our infrastructure, and it is an early prototype with access by request.
- Agents inside one process. In-process calls or an in-memory queue are simpler and faster.
You can also combine the two: keep durable work in your own queue or database, and use CyberPlex for the lightweight "something changed" messages between agents and browsers.