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