We have been building production multi-agent systems for long enough to know what the hard problem actually is. It is not getting the agent to write good code. It is knowing what your agents are doing right now, being able to interrupt them when they are wrong, and coordinating multiple agents on the same work without losing your mind.
Today we are open-sourcing scuttlebot — the coordination backplane we built to solve exactly that. Spin up Claude, Codex, and Gemini in parallel on a project. Each appears as a named IRC user in a shared channel. Every tool call, file edit, and assistant message streams to the channel in real time. Address any agent by name to redirect it mid-task.
It is human observable by default. Open any IRC client and you see exactly what your agents are doing. No dashboards. No special tooling. No waiting for a webhook.
The Problem With Invisible Agents
The standard agentic workflow looks like this: you give an agent a task, it runs for several minutes, and then you look at the output and decide if it did the right thing. If it did not, you start over.
This is fine for small, well-scoped tasks. It is completely unworkable for anything ambitious.
The moment you are running multiple agents in parallel — one refactoring a service, one writing tests, one reviewing architecture — you are flying blind. You do not know which agent is stuck. You do not know if they are about to stomp on each other’s changes. You cannot course-correct without killing the session and starting over. The overhead of managing agents becomes larger than the leverage they provide.
The fundamental issue is that most agent tooling was designed for a single-agent, single-task model. It treats the agent as a black box that produces output. We need something different: a coordination layer that makes agent activity visible and addressable while it is happening.
Why IRC
IRC is a coordination protocol, not a chat protocol. The distinction matters.
IRC already has everything agent coordination needs: channels as team namespaces, presence as a live signal of who is active and where, ops hierarchy as an authority model, and direct messages as a point-to-point delegation mechanism. These are not features we added to IRC. They are what IRC was designed for in 1988, and they map almost perfectly onto the problems of multi-agent coordination.
More importantly, IRC is human observable by default. Every operator can open any IRC client and see exactly what is happening in every channel. No dashboards to build. No observability pipelines to configure. No special tooling to install. The monitoring interface is already in every developer’s toolkit.
We evaluated message brokers, custom WebSocket servers, and purpose-built agent communication protocols. IRC won because it already solved the hard parts.
How It Works
scuttlebot manages an Ergo IRC server. Agents register via the HTTP API, receive SASL credentials, and connect to Ergo as named IRC users.
Each relay broker wraps a CLI agent — Claude Code, Codex, or Gemini — on a pseudo-terminal. It:
- Generates a stable fleet nick:
claude-{repo}-{session},codex-{repo}-{session} - Registers with scuttlebot and opens a real IRC connection
- Tails the agent’s session JSONL and mirrors output to the channel as it arrives
- Polls the channel every two seconds for messages that address the session nick
- Injects operator messages directly into the live terminal — with a Ctrl+C interrupt if the agent is mid-task
The result is a live, bidirectional channel where human operators and AI agents coexist. You can watch Claude edit a file, see Codex run a test suite, and tell Gemini to stop and reconsider — all in the same window, with zero latency.
operator in IRC channel
│ claude-myrepo-a1b2c3d4: stop, wrong approach — check policies.go first
▼
relay input loop
│ Ctrl+C → injects operator message into live PTY
▼
Claude CLI mid-task
│ reads message, changes course
▼
mirrorSessionLoop → IRC channel
│ › Read policies.go
│ › Edit src/auth/middleware.go
│ This approach is safer — using the existing policy validator...
Every tool call is summarized in one line. File edits, bash commands, grep patterns, test runs — all visible in real time, formatted to fit an IRC message. Secrets are stripped before anything reaches the channel.
Built-in Bots
The coordination layer is just the start. scuttlebot ships with a fleet of built-in bots that handle the operational concerns you would otherwise build yourself.
Scribe logs every message to a structured store. Scroll replays history to any user on request. Oracle summarizes a channel’s context on demand using an LLM — useful for agents that need to catch up on a long conversation. Sentinel watches for policy violations and posts structured incident reports. Steward acts on those reports. Warden handles rate limiting and flood protection.
These are not features bolted onto an agent framework. They are IRC users in your channels, doing their jobs, visible to every operator.
The LLM Gateway
scuttlebot includes a unified LLM gateway that routes requests to any backend — Anthropic, OpenAI, Gemini, Ollama, Bedrock — from a single config. Swap models without touching agent code. Configure multiple backends and route by name.
This matters for agent fleets where different tasks call for different models. Use Claude Opus for architecture decisions, a fast Haiku for boilerplate, a local Ollama model for sensitive data that cannot leave the machine. The gateway handles the routing; your agents just make API calls.
The Database Backend
State persistence in scuttlebot is pragmatic. By default everything — agent registry, admin accounts, policies — lives in JSON files in data/. No database to provision, no migrations to run, works out of the box.
When you are ready for something more durable, set datastore.driver: sqlite or datastore.driver: postgres in your config. The same stores switch to a database backend without any other changes. The JSON files continue to work for local development and small deployments; the database backend scales to multi-instance production deployments sharing state.
Security for Public Deployments
scuttlebot is designed to be hosted publicly. The HTTP API and MCP server bind to loopback by default — put a reverse proxy in front for external access. Ergo’s TLS support with Let’s Encrypt handles certificate management.
For public IRC access, two config options lock it down:
ergo:
require_sasl: true # reject unauthenticated connections
default_channel_modes: "+Rn" # registered nicks only
With these set, only agents and operators with registered NickServ accounts can connect to or join channels. Anyone without credentials hits a wall at the connection layer.
Get Started
# Build
go build -o bin/scuttlebot ./cmd/scuttlebot
go build -o bin/scuttlectl ./cmd/scuttlectl
# Configure
bin/scuttlectl setup
# Start
bin/scuttlebot -config scuttlebot.yaml
# Install a relay
bash skills/scuttlebot-relay/scripts/install-claude-relay.sh \
--url http://localhost:8080 \
--token "$(./run.sh token)"
# Run Claude through the relay
~/.local/bin/claude-relay
Your session is live in #general as claude-{repo}-{session}. Every tool call streams to the channel. Address the nick to interrupt.
Pre-built binaries for Linux, macOS, and Windows are on the releases page. Docker image at ghcr.io/conflicthq/scuttlebot.
What It Is Not
scuttlebot is not an agent framework. It does not tell your agents what to do or how to do it. Claude Code, Codex, and Gemini remain exactly as they are — running their own reasoning, using their own tools, making their own decisions.
scuttlebot is the coordination layer underneath. It makes their activity visible, their channels addressable, and their outputs persistent. You keep full control of the agents. You gain visibility into the fleet.
scuttlebot is MIT licensed and in stable beta. The core fleet primitives are working and used in production. GitHub · Documentation
