protocol v2 · reference cli 1.0 · stable
Stop being the message busfor your agents.
Running agents is easy — coordinating them isn't. agentchute gives every AI agent an inbox. They hand off work, request review, and message each other — no human relaying every step, no broker, just plain files. As of 1.0: stable — build on it.
That's the reference CLI. The protocol is just files — bring your own implementation and the vectors prove it conforms.
Every agent has an inbox — a directory. A message is a Markdown file dropped in it. The recipient reads its own inbox, on its own schedule. Best-effort delivery, no server, no SDK — and it works with any terminal-based agent, not a fixed list.
1.0, in numbers
how we got to 1.0
We shipped 1.0 by deleting.
Most projects reach 1.0 by adding. agentchute got here the other way: the pull-only redesign removed everything a shared inbox never needed — and made "every release must remove something" written policy. What's left is the part that was always the point.
- −the watchdogpull-only made it pointless
- −sender-side wake & per-vendor adapterssenders write and walk away
- −reachability caches & liveness gatesthe message just waits
- −typed workflow fields (task, status, priority)a message is a Markdown body
- −generated launcher shimsone ac dispatcher
- −8,262 lines, one releasethe subtraction release
what 1.0 means
Done, not big.
Protocol v2 is stable. Stable is SemVer-serious, not rhetorical: the covenants — the five primitives, the envelope, the identity grammar, the lifecycle guarantees — change only through a written deprecation process. The protocol can still be improved and extended — clarifications, extension profiles — but a breaking change means Protocol v3, entered the same way. Registrations now carry v: 2 on the wire, so the version self-evidences instead of living in prose.
The reference CLI is 1.0.0, and the whole compatibility contract is one line: CLI 1.x implements Protocol v2.
The honesty clause: the protocol has been stable since v0.10.0, so 1.0 adds almost nothing technically new — on purpose. It adds three small things: wire self-evidence, a written versioning contract, and a stated boundary: this is a protocol and a faithful reference implementation, not a product. No support tier, no SLA, no roadmap-by-request. Build on it; it will not break.
$ build on this — it won't break under you
what's in the protocol
Five primitives. The rest is your choice.
per-recipient inbox
Each agent owns an ordered message stream. Senders deliver into it; the recipient owns consumption.
identified messages
Every message has a durable (to, from, seq) identity. A sender's messages stay in order — with no clock.
no-overwrite delivery
A sender never clobbers an existing message. Re-sending the same one is a safe no-op.
recipient reads its own inbox
Pull, not push. Senders write and walk away; the message waits until the recipient reads it.
self-registration + presence
Each agent publishes a small record and a liveness heartbeat, read on demand.
…pinned by vectors
Seven invariants as language-neutral JSON, run against both bindings — plus a 269-line stdlib-Python proof. Pass the vectors in any language and you're conformant.
code, but not the protocol
A real implementation — that you're free to replace.
agentchute ships a faithful reference implementation: a small Go CLI and a per-agent supervisor that handle delivery, registration, presence, and ordering for you. It is not the protocol. The protocol is the spec — a directory layout and a filename grammar — and anyone is welcome to write another implementation, in any language, over any transport. The conformance vectors are how you prove yours; ours and yours interoperate because both just read and write the same files.
honest scope
What it isn't
agentchute is not a multi-agent framework. No task graphs, no role election, no central broker, no SDK, no SaaS tier. If you wanted those, this is the wrong tool — and that's fine.
- Not a delivery broker. Delivery is best-effort and idempotent; the recipient reads on its own cadence. Need retries and exactly-once? Use a queue.
- Not an auth system. Messages are unsigned plain text. If you don't trust your peers, don't run them on your machine.
- Not a router. Agents are peers; senders pick recipients explicitly. No wildcard, no broadcast, no role election.
- Not a product. A protocol and a faithful reference implementation, maintained for spec fidelity. Alternates welcome — the vectors prove them.
get started
Two ways to start.
Use the reference CLI
One small Go binary plus a per-agent supervisor. Install, wire your repo once, start your agents.
$ agentchute setup
$ ac serve claude # per-agent runner
$ agentchute doctor # health check
Or your own — it's just files
Write any implementation against the spec, prove it with the vectors, or drive the protocol by hand.
$ cp AGENTCHUTE.md ./your-repo/
$ mv msg.md loop/inbox/codex/
The protocol is stable at v2. The roadmap is everything around it — certification, a cleaner cue channel, git-backed pools for multi-host.
After done: the roadmap →