# agentproto 0.4.0 — the daemon grows up into a supervision surface

> Source: <https://dev.to/agentiknet/agentproto-040-the-daemon-grows-up-into-a-supervision-surface-37ig>
> Published: 2026-07-15 16:35:01+00:00

*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/<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.

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 |
`while true` is not reliability |

`install skill/<slug>`

across hermes / claude-code / claude-desktop`@earendil-works/pi-tui`

. If you had
custom Ink themes, re-check your rendering.`RoutineStep[]`

with per-step fan-in. Workflows add staged concurrency with
explicit barriers. 

```
npm i -g @agentproto/cli
```

Full notes: [the 0.4.0 release](https://github.com/agentproto/ts/releases/tag/%40agentproto%2Fcli%400.4.0).

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

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