RELEASE · CLI v1.0 · PROTOCOL v2
1.0 — done, not big.
Most 1.0 announcements promise that things are about to get bigger. Ours promises the opposite: the wire will not break under you. agentchute 1.0 is out — the protocol reaches v2, stable, and the reference CLI that carries it is 1.0.
The problem, in one sentence
If you run several AI agents on one project — Claude Code writing, Codex reviewing, Gemini researching — you are the message bus: copy from one terminal, paste into another, relay the review back, all day. Frameworks solve this with brokers, task graphs, and SDKs. We solved it with a directory and a file.
Every agent gets an inbox — a directory. A message is a Markdown file dropped in it. The recipient reads its own inbox, on its own schedule. Pull, not push; best-effort; no server, no broker, no SDK. It works with any terminal-based agent, because none of it depends on vendor behavior. That's the whole protocol, and it's been the whole protocol since we deleted our way back to it.
How we got here
agentchute reached 1.0 the unusual way. The 0.8 redesign removed the sender-poke mistake and everything built to prop it up: the watchdog, cooperative wake, reachability caches, per-vendor wake adapters. The 0.9 line was the subtraction release — 8,262 lines removed in one tag — and made it policy: every release must remove something. 0.10 declared the protocol stable. 0.11 made the conformance suite language-neutral: seven invariants as JSON vectors, and a 269-line stdlib-Python script that passes them, proving the protocol lives outside any one implementation. What's left fits in your head: five primitives, seven invariants, two bindings, zero servers.
What "stable" means, precisely
Stable is SemVer-serious, not rhetorical. The covenants — the primitives, the envelope, the identity grammar, the lifecycle guarantees — change only through the written deprecation process. The protocol can still be improved and extended — clarifications, new extension profiles — but a breaking change means Protocol v3, entered through that same process. And the version now self-evidences: every registration carries v: 2 on the wire, so the claim lives in the pool, not in prose.
The reference CLI is 1.0.0, and the entire compatibility contract is one line: CLI 1.x implements Protocol v2. The tag itself changes nothing — v1.0.0 is byte-honest over the release we dogfooded on our own live pool, installed through the real installer, run by the same five-agent team that builds agentchute with agentchute.
The honesty clause. The protocol has been stable since v0.10.0, so 1.0 adds almost nothing technically new — on purpose. It adds exactly three small things: wire self-evidence (v: 2), a written two-line versioning contract, and a stated boundary: agentchute is a protocol and a faithful reference implementation — not a product. No support tier, no SLA, no roadmap-by-request. If a 1.0 that adds nothing sounds strange, that's the point: this is a protocol's 1.0, not a product's.
What we said no to
Rejecting these is the announcement: no priorities, no delivery receipts, no broadcast, no routing or coordinator agents, no signing machinery, no retries or exactly-once, no config system, no daemons, no maintained SDKs. Each one would re-grow the mass we spent four releases removing. In a category racing to add orchestration surface, agentchute's 1.0 statement is a protocol that stays small on purpose.
Build on it
Install the reference CLI and your agents are coordinating in minutes — or skip our binary entirely: the protocol is just files, and the vectors tell you whether your own implementation, in any language, got it right. Either way, the promise is the same and it's the only one we make: build on this — it won't break under you.
$ an inbox per agent. a Markdown message. that's the protocol — now at v2, stable.