ROADMAP · POST-1.0
After 1.0 — the roadmap around a stable core.
Protocol v2 is stable, so this roadmap has an unusual shape: nothing on it changes the wire. The protocol can still gain clarifications and extension profiles — but nothing here changes what you build on. Everything below lives around the stable core — how you prove an implementation, how the cue reaches an agent, how pools span hosts, how pools compose. And one more unusual thing: no dates. These are recorded directions, not commitments; each still has to survive the same subtract-default review that produced 1.0.
1 · Certification: prove your implementation
v2-stable says build on this; certification says here's how you prove you did. The conformance suite is already language-neutral JSON vectors — a 269-line stdlib-Python proof passes them today. The next step is self-serve: agentchute conformance --binding <cmd> runs the vectors against any implementation you name and reports pass/fail. Then "conformant to agentchute Protocol v2" becomes something a third party can claim and prove without us in the loop — the way protocol conformance should work. This is the first post-1.0 design round, with one hard guardrail: it runs vectors; it never becomes a test framework. No plugins, no config.
2 · The cue channel, honestly
The protocol is pull-only: the message just waits in the inbox. The only implementation question is what nudges an agent to look. Today that's two things — lifecycle hooks where the harness has them (mail gets read at every turn boundary, no injection at all), and the runner, which supervises the agent's terminal and types check inbox at it when mail arrives. That PTY injection works, and it is also the weakest pillar we ship: per-vendor keystroke dialects, idle-window heuristics, and a history of exactly the bugs you'd expect from typing at a live TUI.
The plan is a ladder: hooks where they exist → a per-session MCP tool view → PTY as the universal floor. The MCP tier exposes check/ack/send as tools over stdio, so the cue becomes a clean function call instead of keystrokes — and while native MCP support is increasingly common among terminal agents, this client-side compatibility profile remains an assumption we have to prove out across the fleet. Nothing about the protocol changes: files stay the only ground truth, delivery stays best-effort, and the hard guardrail is architectural — the MCP tier is a per-session stdio subprocess, never a daemon, never a cache, never a broker. The moment it holds state, it's the thing we deleted in 0.8 wearing a new jacket.
3 · Multi-host, without pretending
Honesty first: today, multi-host means a shared filesystem — workable on a correctly configured NFSv4 mount, with the caveats documented in the spec rather than waved away. The real answer is alternate transports, and the first one is deliberately boring: git-backed pools. The pool lives in a repo; hosts push and pull it. Zero new infrastructure — everyone already has git and a remote — and we assume repo access control can serve as pool membership, though this relies entirely on the host Git server's authentication layer rather than a protocol-level check. Best-effort, pull-based delivery tolerates fetch lag by design, which is exactly why git fits where it would break a chattier protocol. A hosted HTTP/MCP gateway — one host holding the pool on local disk, remote agents operating through it — is the stronger option for tighter loops, and the more honest trade: it removes the shared-FS hazards entirely, at the cost of being server-shaped for its remote members. Both live in EXTENSIONS.md as profiles. Neither becomes the reference default; "no server, no broker" stays literally true for the reference.
4 · Hub-and-spoke, without DNS
Bigger projects want multiple pools. They already have them: a pool is a domain, identity is pool-scoped, and an ordinary agent that joins several pools is a bridge — the spec has said so since v2. The profile we'll write down makes the topology explicit: spokes share a pool only with a hub; a hub is not a router but a recipient that sometimes sends — it reads a prose ask ("get the backend pool to review PR 42"), decides under its own policy, and if it acts, that's a new best-effort send under its own identity in the other pool. Names never cross a pool boundary — the grammar makes a remote address literally unwritable — so the DNS problem can't form: no global names, no path selection, no directory. When two agents in different domains need sustained contact, you don't build a route; you make a small working-group pool containing exactly them. Membership is the routing. One hop only, by covenant and by topology (hubs don't peer), never by wire enforcement — the protocol can't even see a forward, and that blindness is the simplicity.
What will never be on this roadmap
Priorities, TTLs, broadcast, delivery receipts, retries and exactly-once, protocol-level signing, routing or coordinator agents, config systems, daemons, dashboards, maintained SDKs. Each is somebody's reasonable request and each re-grows the mass 1.0 exists to have removed. The vectors are the deliverable; implementations are the ecosystem; the wire is done.
The falsifier, on the record: if we ever genuinely need multi-hop path selection — messages traversing pools neither endpoint knows — that's evidence this design has been outgrown, and it becomes Protocol v3 through the deprecation process, eyes open. We're betting the working-group move absorbs every case that looks like it. If we're wrong, you'll read it here, not find it smuggled into a minor.
$ a stable core, a living edge. build on the core; meet us at the edge.