agentproto 0.4.0 — the daemon grows up into a supervision surface

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.

Durable cron, on the daemon

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:

• run an allowlisted command,
• spawn a fresh agent session,
• re-prompt a session that's already alive (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.

Scriptable wait — delete your polling loop

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

The WorkflowRunner primitive

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.

Structured transcripts

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.

Tool verbs, renamed to a family-first taxonomy

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.

The first in-process adapter (AIP-45)

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.

Reliability fixes worth naming

• The hermes hang. A per-turn silence watchdog on the ACP client fixes sessions that stalled without ever emitting turn-end. If you've had an agent sit there looking alive and doing nothing, this was often why.
• agent_output during tool-busy turns stays visible instead of going dark.
• Tool calls render informatively instead of the generic [tool] view line.
• Session liveness on the descriptor — pid, lastActivityAt, processAlive. The dashboard now distinguishes busy, idle, and stale-running (a session whose pid is dead but whose record says otherwise).
• Silent prompt-delivery failures to dead and busy sessions: fixed. They now tell you.
• Transcript writer no longer strips newlines from text-delta events.

Onboarding

agentproto onboard registers the MCP server and installs the skill pack in one
run. install skill/<slug> targets hermes, claude-code, and claude-desktop;
install-mcp does a surgical config.yaml upsert for hermes and a manifest
upsert for claude-desktop — it edits what it must and leaves the rest alone.

Go deeper

Most of what's in this release is an argument made in code. If you want the
argument in prose — including why the design went this way and not the obvious
way — these go with it:

What shipped in 0.4	The thinking behind it
Scriptable wait, durable cron	Kill the loop: why while true is not reliability
Structured transcripts	Your agent says the tests passed. It didn't run them.
install skill/<slug> across hermes / claude-code / claude-desktop	Your Claude skill is invisible to Codex — here's how to fix it (hands-on)
Tool-verb taxonomy, WorkflowRunner	You're optimizing the part of your agent you don't own
Why any of this matters at 5 agents	You can parallelize the typing. You can't parallelize the trust.

Notes before you upgrade

• chat-tui migrated off Ink/React onto @earendil-works/pi-tui. If you had custom Ink themes, re-check your rendering.
• Routines and workflows are different primitives. Routines are a flat RoutineStep[] with per-step fan-in. Workflows add staged concurrency with explicit barriers. Use workflows for new orchestration code.

npm i -g @agentproto/cli

Full notes: the 0.4.0 release.

---

agentproto is an open-source (Apache-2.0) orchestration layer that runs on top
of your existing stack — it doesn't replace your coding agent, it supervises it.
File an issue.

Building agentproto in the open — follow @theagentproto and @agentik_ai on X.