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.