Agent Message Bus: Communication Infrastructure for 16 AI Agents
Source: Dev.to
Agent Message Bus Born: Communication Infrastructure for 16 AI Agents
When your AI Agent count grows from 3 to 16, communication becomes urgent business.
Why a Message Bus?
OpenClaw’s built-in agentToAgent communication has a critical limitation: it only works within the same Gateway instance. When the main agent tries to message a learning agent on a different machine, an instant error occurs.
- Telegram group relay and Redis Pub/Sub were both considered.
- The former lacks format control, the latter is overkill.
Final decision: build a lightweight message bus with the following requirements:
- HTTP API
- Multi‑Agent registration
- Message persistence
- Simplicity
Tech Stack: Flask + SQLite
- Flask – chosen for familiarity and lightness.
- SQLite – zero additional services, single‑file storage, easy backups.
Deployed on a T440 (192.168.x.x:8091).
API Design
Six endpoints, keeping it minimal:
POST /send # Send messages (specific recipient or broadcast)
GET /inbox # View inbox with unread filtering
GET /history # View history with time‑range queries
POST /ack # Mark messages as read
GET /agents # List registered agents
GET /stats # System statistics
Key Features
- Broadcast: Omit the
tofield to send to all registered agents. - Reply chains:
reply_tofield tracks conversation context. - Priority: normal / high / urgent levels.
- Read receipts: Confirm processing via
ack.
Pitfalls
- SQLite concurrency: Setting
journal_mode=WALsolved occasional lock issues. - Message accumulation: Auto‑archive read messages older than 7 days.
- Heartbeat: Agents inactive for 5+ minutes are marked offline; queued messages are auto‑pushed on reconnect.
Reflections
An AI Agent’s value isn’t in individual strength but in efficient collaboration.
Flask + SQLite may look “primitive,” but for a dozen agents on an internal network it is simple, stable, and maintainable. The smallest solution that solves the problem is the best solution.