TLDR; I got tired of babysitting N terminal tabs of five different coding-agent CLIs. So I built agentproto — one daemon that drives Claude Code, Codex, Hermes, opencode, and Mastra through the same lifecycle, and actually supervises them.
I have a confession: at any given moment I have Claude Code, Codex, and
Hermes running in parallel terminal tabs, and I cannot remember which flag
spawns which, which one eats --prompt
, which one needs --cwd
vs cd
,
and which one will hang forever if I close the laptop lid. simonw described
the feeling on Hacker News recently — "Today I have Claude Code and Codex CLI and Codex Web running, often in parallel" — and called it a real jump in
I didn't have a good answer. So I built one.
It's called agentproto. It is one daemon and one CLI that drives any
coding-agent CLI — Claude Code, Codex, Hermes, opencode, Mastra, and a few
more — through the same start / prompt / monitor / kill lifecycle, so you
stop memorizing five different CLIs. On top of that lifecycle it adds the
supervision layer people keep hand-rolling by hand: durable policy gates,
nested orchestration, and multiplexed fan-in monitoring. MIT, no paid tier,
the daemon itself is an MCP server.
This is the story of why it exists.
The sharpest signal while I was building this came from other people
independently re-inventing the same primitives in tmux scripts.
On r/ClaudeAI, Confident_Chest5567 posted a writeup of orchestrating
agents via tmux panes with a watchdog that resets dead sessions — "a swarm of agents that can keep themselves alive indefinitely." In the same thread,
That last sentence is the thesis. The orchestration and the supervision
should live outside the agent — in a daemon, not in a tmux script you babysit
by hand, and not baked into one vendor's CLI. When I read it, I realized
agentproto was just the canonical implementation of what people were already
gluing together with tmux + Redis + sleep loops that die when the terminal
dies.
And then there was grim_io on HN, in a thread about parallel agent workflows:
"I'm not convinced there is any hope for a productive, long-term, burnout-free parallel agent workflow. Not while they need even the slightest amount of supervision/review." That is the single sharpest statement of the
el_duderino_50 on r/ClaudeCode tried to build a supervisor agent that
"reliably blocks Claude if it detects red flags" and reported back: "can't really get it to work reliably. It seems like communication and coordination between agents is pretty poorly supported." That is the exact gap a durable
[DIAGRAM: one daemon, N adapters, policy gates]
The shape is simple:
agentproto daemon
. It owns sessions, the event bus, the
policy registry, the orchestration gateway. It survives your terminal
closing.policy:passed
/ policy:failed
fires on the event bus — no polling. Gate
a commit on human approval: commit-ready
→ human ack
→ daemon stages and commits. This is the primitive IssueConnect7471 built a Redis watchdog to approximate, except it does not die when your terminal dies.The daemon is itself an MCP server — roughly 90 tools covering agent
lifecycle, session introspection, orchestration, MCP composition, tunnels,
cron, eval reporters, filesystem, terminal/PTY, browser-as-target, and
scheduling. You script it from code, from another agent, or from cron. No
terminal needs to be attached.
npm i -g @agentproto/cli
agentproto serve
agentproto sessions start claude-code --cwd . --prompt "refactor the payments module"
If you've used any coding-agent CLI, that's the whole learning curve.
agentproto run <adapter>
is the same call regardless of which CLI is
underneath. agentproto sessions
lists every live session across every
adapter with the same status columns.
I want to say this up front, because someone will clone the repo and check.
The orchestration layer is live and verified hands-on. The daemon, the CLI,
every adapter listed above, the policy gates, nested orchestration,
multiplexed fan-in monitoring, MCP composition, sessions, workflows, tunnels,
cron, eval reporters, per-session usage/cost observability — all real,
working today. You can install it cold and drive three different CLIs through
one lifecycle.
The repo also ships the AIP spec family — roughly 52 numbered specs covering
the full surface of an AI company / agent: COMPANY.md
, OPERATOR.md
,
PERSONA.md
, ROLE.md
, ASSEMBLY.md
, PLAYBOOK.md
, and so on. Most of
those specs are 0.1.0-alpha
scaffolded stubs. Real schemas, real intent,
not yet operational software. If you git clone
and grep for TODO
in
their build()
/ validate()
bodies, you will find it. That is not a
problem I'm hiding — it's the contract. The features page separates Tier 1
(live, verified hands-on) from Tier 2 (roadmap) explicitly, and if you find a
Tier 2 claim that reads as shipped, please file it. That honesty split is the
trust asset, not the vulnerability.
This is why you won't see me make any "agents that author their own tools
mid-session" claim in launch copy. I audited that against the source: the
manifest writers exist, but the runtime hot-load path that would let an agent
author and use a new tool mid-session does not. Claiming it would take one HN
reader one session to disprove. It's on the roadmap, explicitly labeled
"not yet."
I want to be careful about the word here. agentproto is not an SDK you import
into your process and build your agent inside of. It is a daemon — a binary
you start, that drives existing coding-agent CLIs as subprocesses over ACP /
JSON-RPC, and that exposes its supervision layer as something you call from
code, from another agent, or from cron. It does not replace whatever you build
agents with. You can run a LangGraph agent, or a Mastra agent, inside an
agentproto session if you want. They compose, they don't compete.
The honest comparison: tools like Claude Squad, Conductor, and Agent Farm
already exist for the single-adapter case — running several Claude Code
instances in parallel with git worktrees and tmux. They're great if that's
your workflow. agentproto is a different shape. It is a daemon with a
programmatic lifecycle (HTTP / MCP / CLI), it works across adapters (not
just Claude Code), it adds supervision primitives none of them have (durable
policy gates that survive a client disconnect, multiplexed fan-in monitoring,
session export, usage/cost introspection), and it could sit under tools like
them.
gck1, independently on HN, restated the pitch almost verbatim: "treat all tooling that wraps the models as dumb gateways to inference. Then provider switch is basically a one line config change." That is the lock-in answer.
The immediate roadmap is adapter breadth and contributor onboarding. The
adapters shipping today cover Claude Code, Codex, Hermes, opencode, Mastra,
claude-sdk, openclaw, and a browser target. The obvious gaps are gemini-cli,
aider, goose, cline, and Continue. The adapter contract is small — declare
models[]
and modes[]
via an AIP-45 manifest, implement the lifecycle
verbs. If you maintain one of those CLIs, or just like one, a one-adapter PR
is the highest-leverage way to grow the moat. The adapter-authoring guide is
at cli.agentproto.sh/docs/concepts/adapters, and there are good first issue: adapter
labels in the tracker.
The longer roadmap is the AIP spec family — turning those alpha stubs into
operational software, one spec at a time, in public. The spec-as-invitation
framing is intentional: an open standard being implemented in public, with a
tracker, turns the honesty liability into a participation surface.
If you're juggling Claude Code + Codex + Hermes + opencode in parallel tabs,
or you've built a tmux + Redis watchdog to keep agents alive, agentproto is
the daemon with those primitives built in. MIT, no paid tier, no vendor
lock-in. I'll be in the comments.
If you've built a crude version of any of this — a watchdog, a custom MCP
spawner, a supervisor agent that never quite worked — I'd genuinely like to
hear what you ran into. You built exactly what this ships. Your teardown is
more useful to me than a star.