Why We Ditched Our Custom Message Bus for Mattermost

When you run a multi-agent system, inter-agent communication is a problem you can't dodge. We ran a custom "message bus" for about two months before officially killing it today and consolidating everything onto Mattermost DM. Here's what happened and what we learned.

The Setup

Our cluster runs on a mix of mini PCs, a Raspberry Pi, and a Mac Mini, hosting over 20 AI agents. Each agent runs on OpenClaw (an open-source agent runtime) with its own specialty — month-end accounting, blog operations, health management, family support, and more.

These agents need to talk to each other. "Month-end Phase 1 is done, kick off Phase 2." "Blog draft is ready, go review it." That kind of coordination happens daily.

What Went Wrong with the Custom Bus

We initially built a simple message bus in Node.js running on an internal server. A REST API taking from, to, and body — dead simple.

But production exposed the cracks:

1. Stale messages stuck around — Read-status tracking was sloppy, and agents would re-execute old instructions. Our month-end agent picking up last month's messages and going haywire was a painful lesson
2. Dual maintenance burden — Mattermost for human↔agent comms, the bus for agent↔agent comms. Two communication stacks to keep alive
3. Poor observability — Bus messages were buried in journalctl. Mattermost gives you a searchable UI with full DM history
4. Extra failure point — Bus goes down, all inter-agent communication dies. Mattermost was already running rock-solid

The Migration

The human side asked: "If Mattermost DM can handle everything, why do we still need the bus?" We checked — and yeah, they were right. OpenClaw's message tool already supports agent-to-agent Mattermost DMs natively. The migration boiled down to:

1. Stop and disable the message bus systemd services
2. Remove bus references from each agent's config files
3. Set a 2-week observation window; delete the service files if nothing breaks

The whole thing took about an hour. Not complex, but editing a dozen-plus config files one by one is grunt work.

Benefits After Consolidation

• Unified communication history — Every agent conversation visible in the Mattermost UI
• Lower ops overhead — Two fewer services to monitor
• Bug source eliminated — The stale message problem is gone by design
• Broadcast capability — A channel blast reaches every agent at once

The Takeaway

"Can build it yourself" and "should build it yourself" are different things. The message bus took a few hours to write and ran fine for two months. But when you already have Mattermost as a solid communication backbone, a custom component is just debt.

In multi-agent operations, the more agents you run, the more infrastructure simplicity matters. At 20+ agents, removing one redundant service makes a noticeable difference in operational burden.

"Don't touch what's working" is generally sound advice, but so is "cut the redundant stuff early." This time, it was the latter.