Agent-to-agent messaging with delivery confirmation.
Multi-agent systems break down silently. Agent A sends a task to Agent B. Did Agent B get it? Did it process it? Did it reply? You end up asking, copy-pasting, manually relaying status. Disco-Bus closes that loop.
An agent calls ping() with a recipient, subject, and payload. The bus stores it, assigns a tracking ID, and flips the state from SENT to DELIVERED. The receiving agent reads it with ping_read() when they spin up. Replies thread back with reply_to.
No more copy-pasting between agent windows. No more lost context. Every message is stored, tracked, and threaded — a running record you can search, replay, and audit. And it all flows through Discord, so you can manage your agents from your phone if you want.
#alerts.delivery_failed_at and excludes it from retries until the operator clears it.In #dispatch: 📬 [Bus] agent-a → agent-b Subject: research-art-styles-2026 Tracking: bus-42-20260422T070000 Status: DELIVERED — awaiting pickup ✅ [Bus] agent-b picked up message from agent-a Tracking: bus-42-20260422T070000 Status: PICKED UP 🔄 [Bus] agent-b replied to agent-a Tracking: bus-reply-43-20260422T071500 Original: bus-42-20260422T070000 Status: LOOP CLOSED ✅
Local SQLite for state, HTTP for delivery, optional Discord mirroring for human visibility. Memory is its own concern — if you want semantic recall over message payloads, that's Mnemo Cortex's job. The bus doesn't route through it.
$ git clone https://github.com/GuyMannDude/disco-bus.git $ cd disco-bus $ pip install -r requirements.txt $ echo "$DISCORD_BOT_TOKEN" > ~/.sparks/discord-token $ cp config.example.json config.json # edit agents/channels $ python3 disco-bus-watcher.py Mode: STANDALONE (Discord only — payload in notifications) Polling every 30s
./install.sh or a JSON-manifest-driven ./robot-install.sh for LLM agents). Different shape, same family.Every agent in a Disco-Bus deployment has an A2A Agent Card in agent-cards/ describing identity, capabilities, and delivery method. Each bus message maps cleanly to an A2A Task:
Disco-Bus → A2A Task ───────────────────────────────────────── tracking_id → task.id subject → task.name body → task.input lifecycle → task.state (CREATED/DELIVERED→submitted, PICKED UP→working, REPLIED→completed, DELIVERY FAILED→failed) reply_to → task.metadata.reply_to
HTTPS / JSON-RPC transport is the v2 roadmap. Data shape compatibility is in now — when transport ships, external A2A clients can submit tasks to your Sparks agents without any data-model changes.
The repo includes SETUP-PROMPT.md — a self-contained prompt any AI agent can read to build the entire bus on a fresh machine. Architecture, schema, lifecycle, A2A mapping, and step-by-step build instructions, all in one paste.
Karpathy's "idea file as publishing format" pattern. Don't ship a tool — ship a description an AI can build from.
Built by Guy Hutchins + his Sparks AI team. Half Moon Bay, California.
SETUP-PROMPT.md is our take on it.