{"slug": "agentproto-0-4-0-the-daemon-grows-up-into-a-supervision-surface", "title": "agentproto 0.4.0 — the daemon grows up into a supervision surface", "summary": "Agentproto 0.4.0 transforms its daemon from a launcher into a supervision surface, adding cron scheduling, a blocking wait primitive, and a WorkflowRunner with explicit barriers. The release introduces session export for auditability, MCP tool namespace grouping, and an in-process adapter for Mastra Code that eliminates subprocess spawning.", "body_md": "*Released 2026-07-03 · npm i -g @agentproto/cli · source · Apache-2.0*\n\nThe gap between \"I can start an agent\" and \"I can leave an agent running\" is\n\nwhere most orchestration tooling quietly gives up. Starting is easy. What's hard\n\nis everything after: knowing when it finished, noticing when it lied, resuming it\n\ntomorrow, running five of them without a polling loop eating your CPU and your\n\nattention.\n\n0.4.0 is the release where the agentproto daemon stops being a launcher and\n\nbecomes a **supervision surface** — something that keeps running, keeps records,\n\nand can be scripted against.\n\nHere's what landed.\n\n`agentproto cron`\n\nschedules agent work that survives your terminal closing. Jobs\n\nlive on the daemon and are exposed three ways — an MCP tool, a REST route, and a\n\nCLI verb — so a scheduled run is reachable from an agent, a script, or your\n\nshell.\n\nA job can do one of three things:\n\n`prompt-session`\n\n).That third one is the interesting one. It means a long-lived session can be\n\npoked on a schedule — \"check the deploy every 20 minutes\" — without paying to\n\nrebuild its context from scratch each time.\n\nIf you've orchestrated agents, you've written this loop:\n\n```\nwhile true; do\n  status=$(check_session $id)\n  [ \"$status\" = \"done\" ] && break\n  sleep 5\ndone\n```\n\nIt's wrong in the ways all busy-waits are wrong, and it gets worse with five\n\nsessions. 0.4 replaces it with a real primitive: block until a session — or a\n\n**fan-in group** of sessions — reaches turn-end, or until a completion policy\n\nresolves. Available as both a REST endpoint and a CLI subcommand.\n\nOne call, N sessions, no polling. (I wrote about why `while true`\n\nisn't\n\nreliability [over here](https://dev.to/agentiknet/kill-the-loop-why-while-true-is-not-reliability-59fk).)\n\nThe headline addition. `WorkflowRunner`\n\ngives you ordered stages of concurrent\n\nsteps with **explicit barriers** between them — so you can say \"these four run\n\ntogether, and nothing proceeds until all four land\" without hand-rolling the\n\nsynchronization.\n\nWhat it carries:\n\n| Feature | What it does |\n|---|---|\n`sessionRef` |\na step reuses an earlier step's session instead of a cold one |\n`outputSchema` + `maxRetries`\n|\nvalidate the step's output, retry on mismatch |\n`maxTotalCostUsd` |\na run-level ceiling — the run stops, it doesn't surprise you |\n| journal cache | re-invoking replays unchanged steps instead of re-running them |\n\nThat last one matters more than it sounds. Editing step 7 of a 9-step workflow\n\nshouldn't cost you steps 1–6 again.\n\n`WorkflowRunner.startFromFile`\n\nand the `workflow_run_file`\n\nMCP tool load a\n\n`WORKFLOW.md`\n\nat call time, so the workflow is a file in your repo — reviewable,\n\ndiffable, not buried in code.\n\nPer-session conversation export, plus a daemon-events export source and\n\n`GET /sessions/:id/events`\n\nfor incremental polling. The point is auditability:\n\nwhen an agent claims it ran the tests, the transcript is how you find out\n\nwhether it did. That claim is the whole subject of\n\n[the supervision ladder](https://dev.to/agentiknet/your-agent-says-the-tests-passed-it-didnt-run-them-15j).\n\nBreaking-ish, and worth it. MCP tools are now grouped by family: `agent_*`\n\n,\n\n`session_*`\n\n, `terminal_*`\n\n, `command_*`\n\n, `file_*`\n\n, `directory_*`\n\n, `browser_*`\n\n,\n\n`policy_*`\n\n, `routine_*`\n\n, `tunnel_*`\n\n.\n\nWhen a model is picking from 60 tools, a name that says which family it belongs\n\nto does real work. Agent tools also moved into a dedicated `agent-tools.ts`\n\n.\n\nEvery adapter until now spawned a subprocess. `createProprietaryProtocolArm`\n\ndynamic-loads an adapter's `createAgentCliClient`\n\n, and `createAgentCliRuntime`\n\nskips the spawn entirely.\n\n`@agentproto/adapter-mastracode-inprocess`\n\nis the first one to use it — driving\n\nMastra Code in-process through its SDK (`createMastraCode`\n\n+ `runMC`\n\n) rather than\n\nshelling out. Its composite `resourceId:threadId`\n\nsession id survives a process\n\nrestart, which is the part I actually care about.\n\n`agent_output`\n\nduring tool-busy turns`[tool] view`\n\nline.`pid`\n\n, `lastActivityAt`\n\n,\n`processAlive`\n\n. The dashboard now distinguishes busy, idle, and\nstale-running (a session whose pid is dead but whose record says otherwise).`agentproto onboard`\n\nregisters the MCP server and installs the skill pack in one\n\nrun. `install skill/<slug>`\n\ntargets hermes, claude-code, and claude-desktop;\n\n`install-mcp`\n\ndoes a surgical `config.yaml`\n\nupsert for hermes and a manifest\n\nupsert for claude-desktop — it edits what it must and leaves the rest alone.\n\nMost of what's in this release is an argument made in code. If you want the\n\nargument in prose — including why the design went this way and not the obvious\n\nway — these go with it:\n\n| What shipped in 0.4 | The thinking behind it |\n|---|---|\n| Scriptable wait, durable cron |\n`while true` is not reliability |\n\n`install skill/<slug>`\n\nacross hermes / claude-code / claude-desktop`@earendil-works/pi-tui`\n\n. If you had\ncustom Ink themes, re-check your rendering.`RoutineStep[]`\n\nwith per-step fan-in. Workflows add staged concurrency with\nexplicit barriers. \n\n```\nnpm i -g @agentproto/cli\n```\n\nFull notes: [the 0.4.0 release](https://github.com/agentproto/ts/releases/tag/%40agentproto%2Fcli%400.4.0).\n\n*agentproto is an open-source (Apache-2.0) orchestration layer that runs on top\nof your existing stack — it doesn't replace your coding agent, it supervises it.\n*\n\n*Building agentproto in the open — follow @theagentproto and @agentik_ai on X.*", "url": "https://wpnews.pro/news/agentproto-0-4-0-the-daemon-grows-up-into-a-supervision-surface", "canonical_source": "https://dev.to/agentiknet/agentproto-040-the-daemon-grows-up-into-a-supervision-surface-37ig", "published_at": "2026-07-15 16:35:01+00:00", "updated_at": "2026-07-15 16:40:08.647541+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "ai-infrastructure", "mlops"], "entities": ["agentproto", "Mastra Code", "MCP"], "alternates": {"html": "https://wpnews.pro/news/agentproto-0-4-0-the-daemon-grows-up-into-a-supervision-surface", "markdown": "https://wpnews.pro/news/agentproto-0-4-0-the-daemon-grows-up-into-a-supervision-surface.md", "text": "https://wpnews.pro/news/agentproto-0-4-0-the-daemon-grows-up-into-a-supervision-surface.txt", "jsonld": "https://wpnews.pro/news/agentproto-0-4-0-the-daemon-grows-up-into-a-supervision-surface.jsonld"}}