I built a CLI to drive every AI coding agent from one interface

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.

Why I built a daemon to drive every AI coding agent from one interface

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
cognitive load compared to a year ago. aantix asked, also on HN: "how does
everyone visually organize the multiple terminal tabs open for these numerous
agents in various states?"

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 hand-rolled watchdog

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,
IssueConnect7471 (18 upvotes) described wiring a Redis pub/sub heartbeat
plus dead-letter respawn between tmux panes, and arrived at this conclusion:
"Keep agents simple, push orchestration to the outside."

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
problem I have found in the wild. If your only answer to "how do I supervise
N agents" is a tmux script, burnout is the correct prediction.

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
policy gate closes — except the gate is a daemon primitive, not a same-model
agent trying (and failing) to watch itself.

The architecture, in one picture

[DIAGRAM: one daemon, N adapters, policy gates]

The shape is simple:

• One daemon. agentproto daemon. It owns sessions, the event bus, the policy registry, the orchestration gateway. It survives your terminal closing.
• N adapters. Each adapter is a thin bridge to one coding-agent CLI — claude-code, codex, hermes, opencode, mastracode, mastra-agent, openclaw, claude-sdk (which is itself a gateway to Anthropic / Moonshot / OpenRouter), and a browser-as-agent target. Each adapter self-declares the models and modes it supports via an AIP-45 manifest, so you never guess what a given CLI can do — you read the manifest.
• Policy gates. Attach a completion gate to any session's turn-end: a shell command that must exit 0, or an LLM-judge on a different adapter. 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.

Three-line quickstart

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.

What's actually shipping today (honest split)

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."

The wedge: supervision, not another SDK

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.
ggaowp on r/LocalLLaMA said it even more directly: "I'm looking for
something I can build on top of... and not worry about vendor lock-in.
Ideally: multi-provider LLM support, or at least swappable." One daemon, any
adapter, models and providers declared per-adapter — that's the plumbing for
people who already believe models are fungible in 2026 and just want the
switch to be one line.

What's next

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.

Try it

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.

• Repo: github.com/agentproto/agentproto
• Site: agentproto.sh
• Features (Tier 1 / Tier 2 split): agentproto.sh/features
• Adapter-authoring guide: cli.agentproto.sh/docs/concepts/adapters

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.