agentproto 0.4.0 — the daemon grows up into a supervision surface 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. Released 2026-07-03 · npm i -g @agentproto/cli · source · Apache-2.0 The gap between "I can start an agent" and "I can leave an agent running" is where most orchestration tooling quietly gives up. Starting is easy. What's hard is everything after: knowing when it finished, noticing when it lied, resuming it tomorrow, running five of them without a polling loop eating your CPU and your attention. 0.4.0 is the release where the agentproto daemon stops being a launcher and becomes a supervision surface — something that keeps running, keeps records, and can be scripted against. Here's what landed. agentproto cron schedules agent work that survives your terminal closing. Jobs live on the daemon and are exposed three ways — an MCP tool, a REST route, and a CLI verb — so a scheduled run is reachable from an agent, a script, or your shell. A job can do one of three things: prompt-session .That third one is the interesting one. It means a long-lived session can be poked on a schedule — "check the deploy every 20 minutes" — without paying to rebuild its context from scratch each time. If you've orchestrated agents, you've written this loop: while true; do status=$ check session $id "$status" = "done" && break sleep 5 done It's wrong in the ways all busy-waits are wrong, and it gets worse with five sessions. 0.4 replaces it with a real primitive: block until a session — or a fan-in group of sessions — reaches turn-end, or until a completion policy resolves. Available as both a REST endpoint and a CLI subcommand. One call, N sessions, no polling. I wrote about why while true isn't reliability over here https://dev.to/agentiknet/kill-the-loop-why-while-true-is-not-reliability-59fk . The headline addition. WorkflowRunner gives you ordered stages of concurrent steps with explicit barriers between them — so you can say "these four run together, and nothing proceeds until all four land" without hand-rolling the synchronization. What it carries: | Feature | What it does | |---|---| sessionRef | a step reuses an earlier step's session instead of a cold one | outputSchema + maxRetries | validate the step's output, retry on mismatch | maxTotalCostUsd | a run-level ceiling — the run stops, it doesn't surprise you | | journal cache | re-invoking replays unchanged steps instead of re-running them | That last one matters more than it sounds. Editing step 7 of a 9-step workflow shouldn't cost you steps 1–6 again. WorkflowRunner.startFromFile and the workflow run file MCP tool load a WORKFLOW.md at call time, so the workflow is a file in your repo — reviewable, diffable, not buried in code. Per-session conversation export, plus a daemon-events export source and GET /sessions/:id/events for incremental polling. The point is auditability: when an agent claims it ran the tests, the transcript is how you find out whether it did. That claim is the whole subject of the supervision ladder https://dev.to/agentiknet/your-agent-says-the-tests-passed-it-didnt-run-them-15j . Breaking-ish, and worth it. MCP tools are now grouped by family: agent , session , terminal , command , file , directory , browser , policy , routine , tunnel . When a model is picking from 60 tools, a name that says which family it belongs to does real work. Agent tools also moved into a dedicated agent-tools.ts . Every adapter until now spawned a subprocess. createProprietaryProtocolArm dynamic-loads an adapter's createAgentCliClient , and createAgentCliRuntime skips the spawn entirely. @agentproto/adapter-mastracode-inprocess is the first one to use it — driving Mastra Code in-process through its SDK createMastraCode + runMC rather than shelling out. Its composite resourceId:threadId session id survives a process restart, which is the part I actually care about. agent output during tool-busy turns tool view line. pid , lastActivityAt , processAlive . The dashboard now distinguishes busy, idle, and stale-running a session whose pid is dead but whose record says otherwise . agentproto onboard registers the MCP server and installs the skill pack in one run. install skill/