{"slug": "i-built-a-cli-to-drive-every-ai-coding-agent-from-one-interface", "title": "I built a CLI to drive every AI coding agent from one interface", "summary": "A developer built agentproto, a daemon and CLI that unifies the lifecycle of multiple AI coding agents—Claude Code, Codex, Hermes, opencode, and Mastra—under a single interface with durable supervision, policy gates, and orchestration. The tool addresses the fragmentation of managing multiple agent CLIs by providing a common start/prompt/monitor/kill lifecycle and a supervision layer that persists beyond terminal sessions. The daemon itself is an MCP server with approximately 90 tools for agent lifecycle, orchestration, and monitoring.", "body_md": "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.\n\nI have a confession: at any given moment I have Claude Code, Codex, and\n\nHermes running in parallel terminal tabs, and I cannot remember which flag\n\nspawns which, which one eats `--prompt`\n\n, which one needs `--cwd`\n\nvs `cd`\n\n,\n\nand which one will hang forever if I close the laptop lid. simonw described\n\nthe feeling on Hacker News recently — *\"Today I have Claude Code and Codex\nCLI and Codex Web running, often in parallel\"* — and called it a real jump in\n\nI didn't have a good answer. So I built one.\n\nIt's called **agentproto**. It is one daemon and one CLI that drives any\n\ncoding-agent CLI — Claude Code, Codex, Hermes, opencode, Mastra, and a few\n\nmore — through the same start / prompt / monitor / kill lifecycle, so you\n\nstop memorizing five different CLIs. On top of that lifecycle it adds the\n\nsupervision layer people keep hand-rolling by hand: durable policy gates,\n\nnested orchestration, and multiplexed fan-in monitoring. MIT, no paid tier,\n\nthe daemon itself is an MCP server.\n\nThis is the story of why it exists.\n\nThe sharpest signal while I was building this came from other people\n\nindependently re-inventing the same primitives in tmux scripts.\n\nOn r/ClaudeAI, **Confident_Chest5567** posted a writeup of orchestrating\n\nagents via tmux panes with a watchdog that resets dead sessions — *\"a swarm\nof agents that can keep themselves alive indefinitely.\"* In the same thread,\n\nThat last sentence is the thesis. The orchestration and the supervision\n\nshould live outside the agent — in a daemon, not in a tmux script you babysit\n\nby hand, and not baked into one vendor's CLI. When I read it, I realized\n\nagentproto was just the canonical implementation of what people were already\n\ngluing together with tmux + Redis + sleep loops that die when the terminal\n\ndies.\n\nAnd then there was grim_io on HN, in a thread about parallel agent workflows:\n\n*\"I'm not convinced there is any hope for a productive, long-term,\nburnout-free parallel agent workflow. Not while they need even the slightest\namount of supervision/review.\"* That is the single sharpest statement of the\n\nel_duderino_50 on r/ClaudeCode tried to build a supervisor agent that\n\n*\"reliably blocks Claude if it detects red flags\"* and reported back: *\"can't\nreally get it to work reliably. It seems like communication and coordination\nbetween agents is pretty poorly supported.\"* That is the exact gap a durable\n\n[DIAGRAM: one daemon, N adapters, policy gates]\n\nThe shape is simple:\n\n`agentproto daemon`\n\n. It owns sessions, the event bus, the\npolicy registry, the orchestration gateway. It survives your terminal\nclosing.`policy:passed`\n\n/ `policy:failed`\n\nfires on the event bus — no polling. Gate\na commit on human approval: `commit-ready`\n\n→ human `ack`\n\n→ daemon stages\nand commits. This is the primitive IssueConnect7471 built a Redis watchdog\nto approximate, except it does not die when your terminal dies.The daemon is itself an MCP server — roughly 90 tools covering agent\n\nlifecycle, session introspection, orchestration, MCP composition, tunnels,\n\ncron, eval reporters, filesystem, terminal/PTY, browser-as-target, and\n\nscheduling. You script it from code, from another agent, or from cron. No\n\nterminal needs to be attached.\n\n```\nnpm i -g @agentproto/cli\nagentproto serve\nagentproto sessions start claude-code --cwd . --prompt \"refactor the payments module\"\n```\n\nIf you've used any coding-agent CLI, that's the whole learning curve.\n\n`agentproto run <adapter>`\n\nis the same call regardless of which CLI is\n\nunderneath. `agentproto sessions`\n\nlists every live session across every\n\nadapter with the same status columns.\n\nI want to say this up front, because someone will clone the repo and check.\n\nThe orchestration layer is live and verified hands-on. The daemon, the CLI,\n\nevery adapter listed above, the policy gates, nested orchestration,\n\nmultiplexed fan-in monitoring, MCP composition, sessions, workflows, tunnels,\n\ncron, eval reporters, per-session usage/cost observability — all real,\n\nworking today. You can install it cold and drive three different CLIs through\n\none lifecycle.\n\nThe repo also ships the AIP spec family — roughly 52 numbered specs covering\n\nthe full surface of an AI company / agent: `COMPANY.md`\n\n, `OPERATOR.md`\n\n,\n\n`PERSONA.md`\n\n, `ROLE.md`\n\n, `ASSEMBLY.md`\n\n, `PLAYBOOK.md`\n\n, and so on. Most of\n\nthose specs are `0.1.0-alpha`\n\nscaffolded stubs. Real schemas, real intent,\n\n**not yet operational software**. If you `git clone`\n\nand grep for `TODO`\n\nin\n\ntheir `build()`\n\n/ `validate()`\n\nbodies, you will find it. That is not a\n\nproblem I'm hiding — it's the contract. The features page separates Tier 1\n\n(live, verified hands-on) from Tier 2 (roadmap) explicitly, and if you find a\n\nTier 2 claim that reads as shipped, please file it. That honesty split is the\n\ntrust asset, not the vulnerability.\n\nThis is why you won't see me make any \"agents that author their own tools\n\nmid-session\" claim in launch copy. I audited that against the source: the\n\nmanifest writers exist, but the runtime hot-load path that would let an agent\n\nauthor and use a new tool mid-session does not. Claiming it would take one HN\n\nreader one session to disprove. It's on the roadmap, explicitly labeled\n\n\"not yet.\"\n\nI want to be careful about the word here. agentproto is not an SDK you import\n\ninto your process and build your agent inside of. It is a daemon — a binary\n\nyou start, that drives existing coding-agent CLIs as subprocesses over ACP /\n\nJSON-RPC, and that exposes its supervision layer as something you call from\n\ncode, from another agent, or from cron. It does not replace whatever you build\n\nagents with. You can run a LangGraph agent, or a Mastra agent, inside an\n\nagentproto session if you want. They compose, they don't compete.\n\nThe honest comparison: tools like Claude Squad, Conductor, and Agent Farm\n\nalready exist for the single-adapter case — running several Claude Code\n\ninstances in parallel with git worktrees and tmux. They're great if that's\n\nyour workflow. agentproto is a different shape. It is a daemon with a\n\nprogrammatic lifecycle (HTTP / MCP / CLI), it works across adapters (not\n\njust Claude Code), it adds supervision primitives none of them have (durable\n\npolicy gates that survive a client disconnect, multiplexed fan-in monitoring,\n\nsession export, usage/cost introspection), and it could sit *under* tools like\n\nthem.\n\ngck1, independently on HN, restated the pitch almost verbatim: *\"treat all\ntooling that wraps the models as dumb gateways to inference. Then provider\nswitch is basically a one line config change.\"* That is the lock-in answer.\n\nThe immediate roadmap is adapter breadth and contributor onboarding. The\n\nadapters shipping today cover Claude Code, Codex, Hermes, opencode, Mastra,\n\nclaude-sdk, openclaw, and a browser target. The obvious gaps are gemini-cli,\n\naider, goose, cline, and Continue. The adapter contract is small — declare\n\n`models[]`\n\nand `modes[]`\n\nvia an AIP-45 manifest, implement the lifecycle\n\nverbs. If you maintain one of those CLIs, or just like one, a one-adapter PR\n\nis the highest-leverage way to grow the moat. The adapter-authoring guide is\n\nat cli.agentproto.sh/docs/concepts/adapters, and there are `good first issue: adapter`\n\nlabels in the tracker.\n\nThe longer roadmap is the AIP spec family — turning those alpha stubs into\n\noperational software, one spec at a time, in public. The spec-as-invitation\n\nframing is intentional: an open standard being implemented in public, with a\n\ntracker, turns the honesty liability into a participation surface.\n\nIf you're juggling Claude Code + Codex + Hermes + opencode in parallel tabs,\n\nor you've built a tmux + Redis watchdog to keep agents alive, agentproto is\n\nthe daemon with those primitives built in. MIT, no paid tier, no vendor\n\nlock-in. I'll be in the comments.\n\nIf you've built a crude version of any of this — a watchdog, a custom MCP\n\nspawner, a supervisor agent that never quite worked — I'd genuinely like to\n\nhear what you ran into. You built exactly what this ships. Your teardown is\n\nmore useful to me than a star.", "url": "https://wpnews.pro/news/i-built-a-cli-to-drive-every-ai-coding-agent-from-one-interface", "canonical_source": "https://dev.to/agentiknet/i-built-a-cli-to-drive-every-ai-coding-agent-from-one-interface-ai", "published_at": "2026-07-09 15:53:27+00:00", "updated_at": "2026-07-09 16:05:45.979754+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "ai-tools", "ai-infrastructure", "large-language-models"], "entities": ["agentproto", "Claude Code", "Codex", "Hermes", "opencode", "Mastra", "Simon Willison", "MCP"], "alternates": {"html": "https://wpnews.pro/news/i-built-a-cli-to-drive-every-ai-coding-agent-from-one-interface", "markdown": "https://wpnews.pro/news/i-built-a-cli-to-drive-every-ai-coding-agent-from-one-interface.md", "text": "https://wpnews.pro/news/i-built-a-cli-to-drive-every-ai-coding-agent-from-one-interface.txt", "jsonld": "https://wpnews.pro/news/i-built-a-cli-to-drive-every-ai-coding-agent-from-one-interface.jsonld"}}