Running multiple AI agents on a shared project is easy.
Coordinating them isn't.

agentchute is a small Markdown protocol that gives AI agents shared inboxes, so they can message each other, request review, and hand off work without a human acting as the relay. Humans stay in the loop for decisions and steering — not for ferrying messages between terminals.

No central server or broker required. No SDK. No compiled code required. Just AGENTCHUTE.md plus a short enrollment block your agents read and follow. 

curl -fsSL https://raw.githubusercontent.com/agentchute/agentchute/main/install.sh | sh

Or skip the binary — just drop AGENTCHUTE.md into your project and follow the enrollment block. The whole protocol fits in one file.

Three agents coordinating in tmux — thumbnail for the launch video
Three agents coordinating in tmux during the final pre-release cleanup pass. 24x speedup of a real working session. No staged prompts, no human ferrying messages. Watch on YouTube (62 seconds).
A developer surrounded by four AI agent terminals, ferrying messages by hand.

Latest from the blog

You are the message bus

How we stopped copy-pasting between four AI agent terminals — and accidentally shipped a coordination protocol along the way.

What's actually in the protocol

The protocol is a small set of implementation-agnostic primitives. Conforming implementations are free to choose any inbox medium, any transport between sender and inbox, and any wake mechanism — those are outside the protocol.

  • Per-recipient inbox. Each agent owns an ordered message stream. Senders deliver into the recipient's inbox; the recipient owns consumption. The inbox medium is implementation-specific.
  • Ordered, identified messages. Each carries a unique (timestamp, sender, nonce) identity tuple; receivers process oldest-first by timestamp with deterministic tie-breaking. The reference CLI realizes this as lexicographic-sorted filenames.
  • No-overwrite delivery. Delivery never silently clobbers an existing entry. Same-identity collisions retry with a fresh nonce. Sender-to-inbox transport is implementation-specific.
  • Recipient-owned consumption. Only the recipient reads its own message bodies. Liveness checks use inbox metadata only.
  • Optional wake. Senders MAY signal a recipient via a pluggable wake adapter. The recipient's own self-poll loop is an equally valid fallback. The wake mechanism is implementation-specific.
  • Self-registration. Each agent publishes a small record naming itself, its wake method/target (if any), and operational metadata.

The v0.1 reference implementation

The CLI in this repo picks one concrete answer for each implementation-specific axis. It's not the protocol — it's the implementation we used while building the protocol, and it worked well enough to be the exclusive coordination layer for the team that shipped it. We chose tmux because it is terminal-native, widely packaged, and gives each agent a stable addressable pane; with one install and a few panes, senders can wake recipients immediately without adding a daemon, broker, or wrapper-specific integration.

  • Inbox medium: plain .md files on a shared filesystem, organized under .<vendor>/loop/inbox/<agent>/.
  • Transport: atomic create-temp + rename (the local-filesystem realization of no-overwrite delivery).
  • Multiplexer: tmux. See the tmux starter kit for a 5-minute setup if you're new to it.
  • Peer-to-peer wake: tmux send-keys injecting the literal string check into the recipient's pane.
  • Recipient self-poll: Claude Code's /loop feature is the in-wrapper path; codex CLI and Gemini CLI have no built-in self-loop, so they use an operator-owned scheduler that invokes the wrapper. Used as the fallback when no peer wake adapter is reachable.

Local is not baked into the protocol, and neither is speed. The reference CLI uses a shared filesystem; another implementation can swap in a queue, HTTP endpoint, object store, git transport, or any other inbox medium that preserves the same semantics. Agents can run in one tmux session or on different machines, networks, or regions — same primitives either way.

Alternate inbox media (Redis/NATS queues, S3-prefixed inboxes, HTTP endpoints, git-backed) are protocol-compatible and discussed in EXTENSIONS.md#alternate-transports with a worked git-as-transport sketch. Alternate wake adapters (wezterm, kitty, OS notifications, SSH-based pokes) and alternate self-poll mechanisms are covered in the surrounding sections. None of these ship in v0.1; they ship the day someone writes them.

The Handoff: simple two-agent message flow

The simplest case: alice sends; bob's wake adapter pokes; bob's check runs; bob replies.

step 1 / 4

The Review: multi-agent coordination with liveness sidecar

Three peers plus a watchdog. claude-code requests review, codex and gemini-cli send findings back, claude-code consolidates and asks for sign-off. The watchdog runs as a metadata-only liveness sidecar — it only wakes a peer with a stale unread inbox. Same protocol; same shared inbox; no central broker.

step 1 / 5

What it isn't

agentchute is not a multi-agent framework. No task graphs, no retries, no role election, no central broker, no SDK, no SaaS pricing tier.

  • Not a message broker with delivery guarantees. No retries, no acknowledgments, no exactly-once. If you need queues, use a queue.
  • Not an identity/auth system. Messages are unsigned plain-text. If you don't trust your peers, don't run them on your machine.
  • Not a router or task-assignment engine. Agents are peers; senders pick recipients explicitly. No wildcard, no broadcast, no role election.
  • Not an audit log. Archives are local and gitignored by default. Loop messages are a transient operational trace.
  • Not a distributed transport with cryptographic guarantees. The v0.1 reference CLI runs over a shared filesystem and provides no signing, no acks, no exactly-once. The protocol itself is medium-agnostic — alternate inbox transports are compatible — but v0.1 ships only the local, unsigned, cooperative-trust implementation. For cryptographic audit, use a signed-envelope coordination protocol.

If you wanted any of those, this is the wrong tool, and that's fine.

Quickstart — no binary

The protocol-only path: a short shell snippet scaffolds the loop, plus one manual step per agent file. No agentchute binary required. 

# 1. Fetch the spec.
curl -fsSL https://raw.githubusercontent.com/agentchute/agentchute/main/AGENTCHUTE.md -O

# 2. Scaffold the loop directories at owner-only perms.
mkdir -p .agentchute/loop/{agents,inbox,archive,malformed}
chmod 700 .agentchute/loop/{agents,inbox,archive,malformed}

# 3. Ignore live state in git.
cat >> .gitignore <<'EOF'
# agentchute-gitignore v1 begin
.agentchute/loop/agents/*.md
!.agentchute/loop/agents/*.example.md
!.agentchute/loop/agents/README.md
.agentchute/loop/inbox/
.agentchute/loop/archive/
.agentchute/loop/malformed/
.agentchute/loop/watchdog.log
# agentchute-gitignore v1 end
EOF

# 4. Drop the ENROLLMENT block at the top of each agent's
#    discovered file (CLAUDE.md, CODEX.md, GEMINI.md, AGENTS.md).
#    Templates: templates/enrollment/wrapper.md and agents.md.

Each agent reads its file, registers itself by writing .agentchute/loop/agents/<its-id>.md, and starts checking its inbox. Sending and checking are just mv plus an optional wake poke.

Or, install the reference CLI

~4000 lines of stdlib Go, no third-party dependencies.

curl -fsSL https://raw.githubusercontent.com/agentchute/agentchute/main/install.sh | sh
# or
go install github.com/agentchute/agentchute@latest

What the CLI buys you:

  • agentchute init — scaffold loop directories + drop ENROLLMENT blocks into discovered wrapper files.
  • agentchute register --as <id> --vendor <vendor> — write your registration.
  • agentchute check --as <id> — pull your inbox, archive consumed messages, enforce §11 (quarantine + notify), and run §10.5 cooperative waking.
  • agentchute send --from <id> --to <peer> --task "..." — write the message file and poke the recipient.
  • agentchute prepare-pool --target <folder> — scaffold cross-folder enrollment in sibling folders.
  • agentchute status --as <id> — registry overview, inbox depths, freshness.
  • agentchute watchdog --as <id> — optional liveness daemon (most pools don't need one; cooperative waking covers it).

Both paths produce the same on-disk state. You can mix: hand-protocol on one shell, CLI on another, in the same pool.

One prerequisite: tmux (or a workaround)

The v0.1 reference CLI ships one peer-wake adapter: tmux send-keys. Install tmux and run agents in addressable tmux panes if you want senders to wake recipients immediately after delivery. Without tmux, delivery still works — messages land in the recipient's inbox — but recipients must poll manually, use a wrapper-provided self-loop, or run an operator-owned scheduler that invokes the agent.

Per-wrapper self-poll patterns we've verified:

  • Claude Code: /loop check — Claude's built-in recurring task. The agent itself sees each tick and processes inbox arrivals.
  • codex CLI (no built-in self-loop in 0.130.0): operator-owned while-loop invoking codex exec with an inbox-processing prompt.
  • Gemini CLI (no built-in self-loop): same shape — operator-owned scheduler invoking gemini with an inbox-processing prompt.

Important: a bare agentchute check shell loop without a wrapper is not a valid workaround. It consumes and archives messages without any model actually acting on them. Always schedule the wrapper, not the CLI alone.

Why this exists

In early 2026 it became normal to run two or three AI agents at once for the same project (Claude Code, codex CLI, Gemini CLI, whatever). Coordinating them by typing in the chat ate hours per week. Existing solutions either didn't exist or shipped a server, a database, and a Helm chart for what is structurally a 200-line problem.

agentchute is what's left when you remove every layer that didn't have to be there. The spec is short. The reference CLI is small. The only moving parts are shared inboxes and, when available, a wake poke for direct wake-ups. The simplicity is the point.