DEV Community: Agentik

Your coding agent runs a shell on your machine. I audited mine.

Agentik — Tue, 21 Jul 2026 23:40:08 +0000

A coding agent that can run bash on your laptop is a remote shell on localhost. It has that threat model whether or not anyone designed for it — browser drive-bys, DNS rebinding, curl | bash, the twenty years of localhost-daemon mistakes the web already made and wrote down.

Last week wren.wtf published a teardown of opencode: Stop using opencode. Read it in full. The headline was a real CVE — a default HTTP server with permissive CORS and an endpoint that ran arbitrary shell commands, so any website you visited could take the machine.

I maintain agentproto, an open runtime that does the same dangerous thing on purpose: a local daemon that lets agents run commands, read files, and open tunnels on the user's machine. So I read the teardown as a checklist and pointed it at my own code. Below is what I found, what I changed, and — the part that transfers — the methodology, so you can run it on whatever agent tool you use.

The one idea

"Textual command filtering is thoughts and prayers." — the teardown

That line is the whole game. Most agent tools try to make bash safe by parsing the command string and blocking the bad ones. It doesn't work, and the article lists why: pipe to bash, base64-decode, env git, a heredoc, python3 -c, an absolute path. Every one walks past a string filter.

The fix is not a better regex. It's two boundaries a string never touches:

What the process is allowed to do — OS-level rights.
Who is allowed to ask — the network posture.

Everything that follows is one of those two.

Run these four questions on your own tool first

You can answer them in five minutes:

Does it bind a TCP port — to 127.0.0.1, or 0.0.0.0?
Can a random website fetch() that port and read the response? Open devtools on any page and try.
When it says "allow bash", what does the allow check — the command string, or the binary?
Does it reach a remote model before you chose one?

If you don't like your answers, you're where I was.

What I found, by threat class

Threat	The mistake	The fix
Browser drive-by RCE	loopback-bypassed auth + reflected CORS on a command endpoint	`Origin` gate, no bypass
Cross-origin read exfil	transcripts + a live event stream readable by any page	same gate on read routes
DNS rebinding	`Host` header never checked	reject non-loopback `Host` on the loopback path
Supply chain	`curl \	bash` with no checksum
Interpreter escape	allowlisting `bash`/`node` = arbitrary read	opt-in OS sandbox
Phoning home	remote model by default	loopback bind, user-chosen model, gated tunnel

The browser drive-by was the sharpest. The endpoint that runs commands was gated by an auth check with a loopback bypass — there to let local clients through without a token. But a browser's fetch() to 127.0.0.1 is loopback. With reflected-origin CORS, any page could drive it.

The signal that separates a real local client from a drive-by is one header the page cannot forge:

// A browser always sends Origin on a cross-origin request.
// Native clients (the CLI, curl, an editor) send none.
if (origin && !allowlisted(origin)) return reject(403)

A page at evil.com sends Origin: https://evil.com, which isn't allowlisted, and gets a 403 — from loopback, in the default config. Native clients send no Origin and keep working untouched. One header closed the class.

Reading is exfiltration too. The same daemon served conversation transcripts and a live event stream over GET — readable cross-origin, no shell required. The Origin gate went on the read routes as well. If a route leaks state, gate it like it writes state.

DNS rebinding is the follow-up: a page rebinds evil.com to 127.0.0.1, and now Origin is only half the story. So the loopback path also validates the Host header — a rebinding request still carries its own hostname, and anything that isn't a loopback Host is refused.

The command-filter myth, and what replaces it

agentproto never parsed command strings. It spawns with shell: false and a verbatim argv, against a default-deny allowlist of binaries, not strings. That structurally kills every bypass in the teardown — there is no shell to inject into.

The residual is honest: if you allowlist an interpreter — bash, node, python3 — you have allowlisted arbitrary code, and a working-directory anchor won't stop it reading ~/.ssh/id_rsa. The article's own recommendation is the right one: confine at the OS, not the string. So command execution gained an opt-in sandbox — macOS Seatbelt, Linux bubblewrap — that bounds what the process can read and write, and in strict mode whether it has a network at all.

Prove the boundary; don't ship a guessed profile

This is the part I hold hardest. A sandbox you haven't watched deny something is a comment, not a control.

So before writing a line of the sandbox, I made it deny something in a real process:

macOS Seatbelt — a workspace read succeeds; cat ~/.ssh/id_rsa returns Operation not permitted.
Linux bubblewrap, in a container — the workspace is bound and visible; ~/.ssh is never mounted, so the read is ENOENT; with --unshare-net, a socket connect returns ENETUNREACH.

Only then did the code get written — with the flags I had watched work — and a test that runs the real sandbox where it exists. The confinement ships with evidence, not a hope.

Not calling home

The teardown's other thread: opencode connects to a remote model by default, pulls the default model's URL from a third party, and starts reading your files with a shell already open.

The posture I hold agentproto to is the opposite, and it's boring on purpose:

The daemon binds 127.0.0.1, not 0.0.0.0.
It contacts no remote model on its own. The model is whatever adapter you point it at — local or hosted, your key, your call.
Going public is one explicit verb, it mints a bearer token, and the tunnel is gated. A passthrough tunnel the daemon can't gate now says so, in its own result, out loud.

Local-first is not a feature you add later. It's a default you refuse to trade away.

The methodology, in five lines

Treat an agent runtime as a remote shell on localhost. It is one.
Deny by default. The allowlist gates which binary; the OS gates what it can touch.
Split "who can ask" from "what runs" — a page can't forge Origin, and can't forge a loopback Host. Use that.
Reading is exfiltration. Gate reads like you gate writes.
Prove the boundary in a real process before you trust it.

Where it landed

Eight pull requests, all public. Every finding from the teardown is closed, and both sandbox backends were validated in real processes before they shipped:

#570 — gate /mcp against the browser drive-by
#571 — block cross-origin reads, tighten CORS, redact tokens from logs
#572 — refuse unverified curl | bash installers in non-interactive contexts
#573 — harden the loopback signal, flag unauthenticated tunnels
#578 + #581 + #585 — the interpreter footgun: warn, then confine (macOS Seatbelt, Linux bubblewrap)
#582 — the DNS-rebinding Host guard

The one thing the runtime already did right — argv and a binary allowlist instead of string filtering — is the reason the worst class never applied.

Read the original teardown. Then run the four questions against whatever agent runs commands on your machine. You'll find something.

agentproto 0.8.0 — the daemon makes decisions so you don't have to

Agentik — Sun, 19 Jul 2026 14:14:50 +0000

0.8.0 released 2026-07-17 · npm i -g @agentproto/cli · source · Apache-2.0

If you've been running an agent daemon you've hit the wall. The agent finishes
its work, runs the tests, everything passes — and then it stops. Not because it's
done. Because it's waiting for you to click "Approve."

0.8 is about tearing that wall down.

No breaking changes in this one. Upgrade and the daemon gets smarter; your
existing config stays intact.

`permissions watch`: your agent stopped asking permission

When an agent pauses mid-turn to ask "should I run this command?", the daemon
parks it in a durable inbox. Until 0.8, someone — you, or a supervising agent —
had to answer explicitly. That's the right default. But after the hundredth
npm install you've approved in a row, it stops being safety and starts being
noise.

agentproto permissions watch --rule 'command:npm:*:allow' \
                             --rule 'command:git:status,diff,log:allow'

A watch is a persistent rule that auto-resolves matching permission requests
before they ever surface in the inbox. The agent pauses for exactly as long as it
takes the daemon to check the rule — sub-millisecond. You never see the prompt.

The rule grammar is kind:adapter:action:decision:

# Allow all git reads, deny force-pushes
command:git:status,diff,log,show,branch:allow
command:git:push.*force:deny

# Allow file writes in the project tree (but nowhere else)
write:**/src/**:allow
write:/etc/**:deny

A watch is a live daemon session you start once and forget. It survives agent
restarts, adapter swaps, model changes — it lives at the daemon layer, not the
agent layer. agentproto permissions watch --list shows what's active;
--remove <id> kills one.

This is the feature that makes the permission-hold inbox from 0.6 actually
usable at scale. Before, answering every prompt yourself was exhausting.
Auto-approving everything was reckless. permissions watch gives you the middle
ground: you decide the policy once, the daemon enforces it forever.

Worktree isolation as policy, not convention

agent_start has accepted worktree: true since 0.6. It was opt-in — if you
remembered to set it, your parallel agents couldn't collide on the working tree.
If you forgot, they could.

0.8 makes it a daemon-level policy:

{
  "defaults": {
    "worktrees": { "isolation": "always" }
  }
}

always means every root spawn gets its own worktree, no matter what the caller
passes. A spawn that would have landed directly in your main working tree now
lands in a fresh worktree instead. The caller can't opt out — that's the point of
a policy.

never means the opposite: worktree isolation is disabled daemon-wide, and a
spawn that requests it is rejected rather than silently ignored. (A CI box with
ephemeral runners has no worktree to isolate.)

The default is permissive — today's behaviour — so nobody's setup changes
unless they choose to tighten it.

This is the pattern: take a thing that required discipline and turn it into a
thing that's enforced. The daemon's job isn't to suggest best practices. It's to
make the unsafe path harder than the safe one.

Your CI can speak agentproto now

- uses: agentproto/agentproto-run@v0
  with:
    prompt: "run pnpm test, fix every failure, commit, open a PR"
    adapter: claude-code
    model: claude-sonnet-5
    worktree: true
    gate: "pnpm test"

agentproto/agentproto-run is a composite GitHub Action that boots the daemon,
spawns the agent session, waits for it to finish, runs the gate, and reports the
result. It's the same path agentproto run takes locally, wrapped in a CI step.

Underneath it's the generic agentproto-run lane — the same one the review-fix
loop uses. Any adapter, any model, any gate, in CI or on your machine. The
composite action is just the GitHub-shaped packaging of it.

Why this matters: until now, putting an agent in CI meant wiring up your own
Dockerfile with the daemon, the adapter, the credentials, the gate script, and
the exit-code plumbing. agentproto-run collapses that into one step. It's what
lets the review-fix-demo from 0.7 reuse a session across turns on the same CI
lane — the session stays alive, the lane re-prompts it.

The LLM endpoint learned to say "try again"

A stripped model — one whose safety layer removes the entire response — returns
an empty completion. To the caller it looks exactly like a network timeout:
nothing came back, retry.

0.8's LLM endpoint now replays the turn once when a provider returns zero
content. If the second attempt also comes back empty, it surfaces the emptiness
explicitly rather than silently dropping it. The caller gets a real error instead
of a mystifying hang.

Also in this release: the Requesty gateway is a first-class preset. Route your
calls through it the same way you route through OpenRouter or Moonshot —
agentproto providers set requesty $REQUESTY_API_KEY and it's live. The
transparent pack is committed in the repo, so the route is auditable.

Skills are now built, not hand-copied

The skill directory in ~/.agentproto/skills/ used to be a hand-maintained copy
of what lived in the monorepo's packages/. That meant the two drifted. 0.8
adds a build step — pnpm build in the skill-pack packages — that produces the
directory from source. Hand-copied .skills/ is retired.

This is infrastructure, not a feature you'll notice directly. But it's the
reason the permissions watch skill ships on day one instead of waiting for
someone to remember to copy it over. Every package under packages/ that
declares a skill manifest is now part of the build graph.

The getting-started path works end to end

0.8 rewrites the quickstart as one verified path: install, serve, spawn, prompt,
read output. Every step was walked by a fresh machine with no prior agentproto
state. If friction was found, it was removed or documented.

The old quickstart assumed you already knew what an MCP server was and why you'd
want one. The new one starts from "you have a coding agent, here's what happens
when you give it a supervisor." That's the right frame for someone who hasn't
been living in this repo.

Also in the box

Codex model selection fixed. Codex spawns now receive the model as a CLI argument instead of ACP session config — the old path was silently ignored, and every Codex session ran on the default model regardless of what you asked for.
Zero-credential users get a helpful message. If you don't have credentials configured for an adapter, the daemon tells you how to configure them instead of telling you to go buy a subscription. Two very different things.
Provider-key env aliases. GOOGLE_API_KEY is now injected alongside GEMINI_API_KEY, so providers that expect one but not the other don't fail silently. The mapping lives in the catalog, not in every adapter.
Worktree NUL-byte bug fixed. A literal NUL in a worktree status file made grep, git, and file all treat it as binary. The fix isn't glamorous, but a worktree that can't be ls-ed is worse than no worktree.
Release notes don't overwrite themselves. A same-day second batch of releases no longer wipes the first one's notes. Small thing. Cost me a changelog entry once.

The arc from 0.5 to 0.8

Four releases in two weeks. Look at the shape:

Release	Theme
0.5	Credentials, sandboxes, cost accounting
0.6	Pairing, E2E encryption, permission inbox
0.7	Extension polish, session story, the things 0.6 got slightly wrong
0.8	Autonomy — the daemon resolves permission, isolates worktrees, and runs in CI without a human in the loop

0.5 was "the daemon knows who you are." 0.6 was "the daemon reaches other
machines securely." 0.8 is "the daemon makes decisions so you don't have to."

The direction is intentional. A supervisor that needs supervision isn't one.
Every release moves one more decision from the human to the daemon — not by
guessing, but by enforcing a policy you declared once.

Upgrading

npm i -g @agentproto/cli

No breaking changes from 0.7. permissions watch and worktree isolation policies
are additive — they don't touch existing behaviour unless you activate them.

Previously: 0.6 + 0.7 — pair two machines through a broker that can't read your traffic · 0.5.0 — credentials, sandboxes, and cost accounting that refuses to lie · 0.4.0 — the daemon grows up into a supervision surface

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.

agentproto 0.6 + 0.7 — pair two machines through a broker that can't read your traffic

Agentik — Fri, 17 Jul 2026 03:07:03 +0000

0.6.0 released 2026-07-16, 0.7.0 on 2026-07-17 · npm i -g @agentproto/cli · source · Apache-2.0

Your agent daemon runs on the machine with your credentials, your repo, and your
shell. Sooner or later you want to reach it from somewhere else — a laptop, a
phone, a CI box. That means a relay in the middle. And a relay in the middle is
a thing you have to trust.

0.6 is mostly about not having to.

Two breaking changes in here, so read the migration note at the bottom before
you upgrade.

Pairing: the broker is deliberately stupid

agentproto pair offer mints a one-time token and prints an agentproto://pair?…
URL. On the other machine:

# On the daemon machine
agentproto pair offer
# → agentproto://pair?t=<token>&rv=<url>&fp=<fingerprint>

# On the client machine
agentproto pair accept "agentproto://pair?..."

That triggers a pair/v1 ECDH handshake over the rendezvous broker, after which
every byte is wrapped in an AEAD channel. The interesting part is what the broker
is allowed to be:

The rendezvous is a dumb WebSocket splicer. It matches two sockets on the same
one-time token, pipes bytes verbatim both ways, and parses nothing.

It learns the token, the IPs, message sizes, and timing. It cannot read content
and it cannot forge it. That's not a promise about our operational discipline —
it's a property of the protocol. The distinction matters, because "trust us with
your plaintext, we're careful" is exactly the claim nobody should accept, ours
included.

After first pairing, the daemon auto-reconnects using day-scoped epoch routing
tokens derived from a shared pairRoot secret — HKDF(pairRoot, "rv-route"‖epoch).
It parks on both the current and previous epoch, so a client whose clock straddles
midnight still finds it. (A small thing that would otherwise be a mystifying
once-a-day bug.)

Revoke with agentproto pair rm <fingerprint> — the daemon stops parking on
those tokens immediately.

Don't want our broker? Self-host it. A Dockerfile ships with the release —
non-root, RENDEZVOUS_* env config, /healthz probe. Offers default to the
hosted rendezvous when nothing else is configured, and pair offer says so
explicitly rather than defaulting silently.

The same treatment for `serve --connect`

Pairing isn't the only place you hand bytes to a middleman. agentproto serve --connect pushes your daemon out through a tunnel, and that tunnel host has
historically seen plaintext. 0.6 adds an opt-in E2E handshake — tunnel-e2e/v1 —
so it doesn't have to:

{ "tunnel": { "e2e": true } }

It's token-authenticated rather than PKI-based: the same shared secret that
authenticates the tunnel also keys the channel, which is why there's no
certificate story to manage. It's opt-in on purpose, and the daemon refuses to
silently fall back to plaintext against a host that doesn't advertise e2e — if you
asked for encryption and can't have it, you get an error, not a quiet downgrade.
That's the whole reason to have the flag: a security property you can't verify
isn't one.

Breaking: Claude Code spawns now demand explicit credentials

@agentproto/adapter-claude-code@1.0.0 and @agentproto/driver-agent-cli@1.0.0
are major bumps, and this is why.

Spawning a Claude Code session used to inherit whatever the daemon's launching
shell happened to export. Which means a stray ANTHROPIC_API_KEY in your
environment could silently bill your org's API credits when you thought you were
on your Max plan — and you'd find out on the invoice.

Now the runtime resolves one of two modes at spawn time and applies it
mechanically:

mode	sets	scrubs
`subscription`	`CLAUDE_CODE_OAUTH_TOKEN` (via `claude setup-token`) — bills your Max/Pro plan	`ANTHROPIC_AUTH_TOKEN`, and the Bedrock/Vertex redirect toggles
`api-key`	`ANTHROPIC_API_KEY` from the provider store	the subscription credential

Scrubbing CLAUDE_CODE_USE_BEDROCK / CLAUDE_CODE_USE_VERTEX in subscription
mode is the quiet hero: an ambient env var could otherwise reroute a native spawn
to Bedrock without a word.

Configure once:

{
  "defaults": {
    "adapters": {
      "claude-code": {
        "auth": { "mode": "subscription", "token": "<bearer-token>" }
      }
    }
  }
}

Or override per-spawn via agent_start.auth. The same resolver now backs
adapter-codex, adapter-claude-sdk, and adapter-hermes — every adapter
uses catalog-sourced billing credentials instead of ambient env inference.

Keys you set with agentproto providers set <slug> <key> get injected into the
child process at spawn time, never into your shell. The resolver looks up the
adapter's declared provider in the catalog, maps it to an env var name
(providerEnvVar("anthropic") → ANTHROPIC_API_KEY), and sets it there and only
there.

Worktrees grew a lifecycle — and a gc that learned restraint the hard way

If you run agents in parallel you have too many worktrees. I certainly do.

agentproto worktree new              # provisions under worktrees.root + a provenance marker
agentproto worktree ls --status      # classify everything
agentproto worktree gc               # dry-run plan
agentproto worktree gc --apply       # execute it

ls --status classifies each worktree on three independent axes: tree
(clean/dirty), integration (eleven states — fresh, merged, open,
partial, pushed-no-pr, unpushed, local-only, gone-unexplained,
diverged, detached, unknown), and liveness (idle, sessions,
daemon-unreachable). The integration axis is squash-merge-proof — it checks SHA
containment against origin/main and caches immutable forge verdicts (a merged PR
stays merged), so it stays honest offline without needing a registry. It never
guesses: a cache miss while offline is unknown, full stop.

The gc ate a live worktree on July 15th

I'd rather tell you this than have you find it.

The first cut of gc had a rule that sounded safe: dirty worktrees get
salvaged (snapshotted to ~/.agentproto/worktree-salvage/) rather than
reclaimed, so nothing uncommitted is ever simply deleted. On 2026-07-15 that rule
destroyed a live worktree out from under a running agent. The mechanism: a branch
with zero commits of its own classified as fresh, fresh was treated as
license to salvage-then-remove, and the agent's uncommitted work went with it.
The snapshot existed — but the worktree the agent was actively writing to did not.

The bug wasn't the salvage step. It was letting an axis prove less than the code
assumed it proved. fresh cannot distinguish "never had commits" from "real
commits, fast-forwarded into main." Both are consistent with fresh, and only one
of them is safe to destroy.

The rule in 0.6 is narrower, and the narrowness is the point:

Only merged — always forge-confirmed — ever licenses destroying dirty, uncommitted work. fresh never does, clean or not.
A merged ∧ dirty worktree written to recently holds anyway, inside a recent-write window. Someone is probably still in there.
Reclaim (clean trees only) needs tree=clean ∧ integration ∈ {merged, fresh} ∧ liveness ∈ {idle, daemon-unreachable}. fresh is fine here precisely because a clean tree has nothing to lose.
gc re-classifies every worktree from scratch immediately before touching it. A plan you printed ten minutes ago cannot cause a deletion now.

The hard guarantee against losing work was never the liveness probe — it's git's
own refusal to remove a dirty worktree without --force. The probe is an
optimization on top. We'd inverted that, and it cost a worktree.

worktree rm / archive replace the old blanket --force with explicit
--discard-untracked / --discard-modified. "Force" was one flag meaning two
very different kinds of destruction; now you have to name which one you meant.

Your agent stopped guessing about permission

When an agent pauses mid-turn to ask permission — Claude Code's
requestPermission before a shell command — the daemon now parks it in a durable
inbox instead of timing out or auto-approving.

agentproto permissions ls              # pending holds across all sessions
agentproto permissions approve <id>
agentproto permissions deny <id>

Same three operations exist as MCP tools, so a supervising agent can answer
programmatically. SessionDescriptor gains blockedOn: "subagent" | "command" | null,
so a UI can finally say why a session looks stuck instead of showing a spinner.
(The case for gating writes rather than blanket-approving: --approve-all is how your agent ships the dangerous one.)

Also in the box

xAI / Grok is a first-class preset — grok-4.5, grok-4.3, grok-4.20, grok-build-0.1 registered in the catalog:

  agentproto providers set xai $XAI_API_KEY
  agentproto run --adapter claude-sdk --mode xai --model grok-4.5 "explain this codebase"

Route-aware model identity — the catalog now separates a model's product identity from its serving route: openai/gpt-4o vs openai/gpt-4o@openrouter. Bare legacy ids still work. Custom routes register via registerCustomRoute — and only the env var name lives in config, never the value.
Fault-tolerant fan-out — MapStep/PipelineStep take onError: "collect", so every item completes and you get a Promise.allSettled-shaped result instead of losing the batch to the first throw.
agentproto policy — completion policies are finally a CLI verb: attach / status / wait / ls / cancel. The engine existed for a while; it had no command, which meant in practice nobody attached one.
agentproto acp — any ACP-speaking agent, not just our adapter family, can be registered in config.json and driven directly.
SSE with replay — GET /sessions/:id/events/stream replays stored events then hands off to live delivery. Reconnect mid-session and you miss nothing.
agentproto.json — declare setup/teardown hooks, supervised services, and a localhost reverse proxy per worktree.
agentproto run --output-schema — validate a run's output against a JSON Schema and fail the command if it doesn't conform. For CI that eats agent output.
agentproto sessions story <id> — a readable narrative of what a session actually did, collapsing noisy low-level events into steps.
agentproto run --model / --effort — pick the model and reasoning effort per run, with a friendly error on unknown flags instead of a stack trace.
daemon.authToken + --auth-token — a persistent gateway bearer token, so the daemon isn't re-authenticating from scratch every restart.
terminalPresets in config.json — name a terminal setup once, reuse it.
@agentproto/adapter-pi — an AIP-45 proprietary-arm adapter for earendil-works/pi. The adapter family keeps growing without the core knowing.
claude-opus-4-8, claude-sonnet-5, claude-fable-5 registered in the pricing catalog — and runnable is now decoupled from priced, so a model missing pricing data still runs (it reports no-pricing, it doesn't guess).
Apache-2.0. Every package relicensed from MIT — 92 packages, zero MIT left. No API changes.

The VS Code extension stopped lying to you

The bigger story across these two releases isn't in the CLI at all. The
VS Code extension
went 0.0.1 → 0.1.0 (in 0.6) → 0.1.1 (in 0.7), which is the arc from
"technically exists" to "the thing I actually watch my agents in."

0.1.0 gave it a spine: structured conversation rendering instead of a wall of
raw events, a sessions tree with filters/search/grouping, workspace autodetect on
spawn, session restart over MCP, and agentproto.openTerminal — a real
Pseudoterminal mirror for PTY and agent-cli sessions, so you can watch a session
in an actual terminal rather than a simulation of one.

0.1.1 is where it stopped misrepresenting state, which is the part I care
about:

Stop was painted as a crash. You'd stop a session deliberately and the UI would show you the same thing it shows when an agent dies. Tree icons and the status bar now run on an activity axis rather than a lifecycle one — a stopped session reads as stopped.
A sub-agent reaped after finishing read as "stopped" instead of "complete." It had done its job. The UI said otherwise.
The sidebar auto-refreshes on a clock, unread sessions carry a read-receipt dot, and a spawn shows up as an optimistic row instead of appearing several seconds late.

Both of those first two are the same bug in different clothes, and it's the bug
this whole project exists to fight: the interface asserting something about your
agents that isn't true. A panel that calls a clean stop a crash trains you to
ignore it, and an ignored panel is worse than no panel — you've paid for the pixels
and gained nothing.

The composer also grew up in this window: a stop button, prompt history on ↑/↓,
drag-and-drop, @file mentions, attachment chips, and paste-an-image-into-the-
transcript. (Fair warning, since I'd rather you hear it here: several of those
landed without changesets, so they're in the shipped extension but missing from its
changelog. The tooling that's supposed to catch that didn't.)

0.7.0, a day later: the polish pass

Beyond the extension, 0.7 is exactly what a release should look like when the
previous one was big: fixes to the things 0.6 got slightly wrong.

Adapters no longer report themselves uninstalled while rebuilding. A last-known-good fallback covers the window where a package is mid-build — the old behaviour made a perfectly healthy adapter vanish from the catalog for a few seconds, which is a wonderful way to lose an afternoon.
models.allowed takes structured entries, fixing gateway model-mode binding in the VS Code picker.
Sessions record worktreePath / worktreeId at spawn time — so the session and the worktree it lives in are joinable without inference.
policy ls --session <id> (and the matching policy_list / GET /policies filter) — the policy list stops being unreadable once you have more than a handful.
--prompt strings get wrapped into a ContentBlock before session.send().
All CLI timeout/interval flags validate and echo their resolved duration, so --until 15m tells you what it parsed rather than silently meaning something else.
node-pty's spawn-helper exec bit is fixed, with PTY spawn errors that actually say what failed.
Test gateways stopped writing fake session rows into the real ~/.agentproto/. Our own test suite was polluting real user state. Worth naming, because it's the same class of bug as the gc one: something that only looks isolated.

Plus docs backfill for 0.6's policy / worktree verbs, config keys, and
sessions story — which had shipped without their pages.

Migrating from 0.5 to 0.7

adapter-claude-code and driver-agent-cli went to 1.0.0. If you relied on
Claude Code spawns inheriting credentials from the daemon's shell, they no longer
do. Declare the mode:

{
  "defaults": {
    "adapters": {
      "claude-code": { "auth": { "mode": "subscription", "token": "<bearer-token>" } }
    }
  }
}

Use mode: "api-key" to bill an API key from the provider store instead. This is
a change you want: the old behaviour is how you accidentally bill org credits
for a session you thought was on your subscription.

npm i -g @agentproto/cli

Full notes: the July 2026 release.

Go deeper

What shipped in 0.6 / 0.7	The thinking behind it
Permission inbox, explicit credential modes	`--approve-all` is how your agent ships the dangerous one (hands-on)
`agentproto policy`, completion policies	Kill the loop: why `while true` is not reliability
Route-aware model identity, xAI preset	Cheaper per token is not cheaper per outcome
`agentproto.json`, lifecycle hooks	Your Claude skill is invisible to Codex (hands-on)
Session story, SSE replay, the VS Code extension	Your agent says the tests passed. It didn't run them.
Why any of this matters at 5 agents	You can parallelize the typing. You can't parallelize the trust.

Previously: 0.5.0 — credentials, sandboxes, and cost accounting that refuses to lie · 0.4.0 — the daemon grows up into a supervision surface

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.

agentproto 0.5.0 — credentials, sandboxes, and cost accounting that refuses to lie

Agentik — Wed, 15 Jul 2026 19:16:51 +0000

Released 2026-07-08 · npm i -g @agentproto/cli · source · Apache-2.0

0.4
turned the daemon into a supervision surface. 0.5 makes it one you can hand a
credential to, run somewhere other than your laptop, and actually measure.

37 packages went out, six of them new. Three arcs are worth your time.

Arc 1 — Auth: the secret never touches your env

@agentproto/auth@0.1.0 implements AIP-50 end to end. Three CredentialStore
backends (Keychain, Memory, File), a full RFC 8628 device-code flow engine, and
a CredentialBroker that hands you ready-to-use headers by provider path:

import { CredentialBroker, KeychainStore, getAuthProvider } from "@agentproto/auth"

const broker = new CredentialBroker({
  store: new KeychainStore(),
  getProvider: getAuthProvider,
})
// → { Authorization: "Bearer <token>" }, refreshed silently when stale.
const headers = await broker.resolveHeaders({ path: "guilde" })

The broker refreshes 60s before expiry, scopes by audience, and knows the
difference between tokens it can serve directly (PAT / OAT / daemon) and
assertion-style tokens that need a flow engine first.

The part I like most is the companion: @agentproto/secrets@0.1.0 adds an
mcp-header SecretExposure variant. Brokered headers get forwarded to child
MCP servers at spawn time — the secret never appears in env, never appears in
config, never sits in a file the agent can read. If you've ever handed an agent
a .env and felt something die inside, this is the fix.

agentproto auth login is rewritten onto this engine, and
agentproto auth cred set|list|rm seeds credentials for brokered child-MCP auth.

Arc 2 — Sandboxes: stop running agents against your filesystem

@agentproto/sandbox@0.1.0 defines the AIP-36 SandboxProvider interface — a
backend-agnostic boot/connect/pause/stop lifecycle.
@agentproto/sandbox-e2b@0.1.0 is the first concrete implementation.

import { createSandboxAgentSessionHost } from "@agentproto/sandbox"
import { e2bSandboxProvider } from "@agentproto/sandbox-e2b"

const host = await createSandboxAgentSessionHost({
  provider: e2bSandboxProvider,
  spec: sandboxHandle,
  secrets: { slugs: ["ANTHROPIC_API_KEY"] },
})
// a full DaemonAgentSessionHost — prompt, export, stop, pause all work
await host.stop()  // closes the daemon connection, then tears down the box

The runtime wires it through agent_start.sandbox, so any AgentStep in a
workflow can declare a sandbox with no bespoke plumbing. Paused boxes reconnect
later via provider.connect(sandboxId, …).

Pair it with @agentproto/storage-github@0.1.0 — an AIP-35 WorkspaceSync over
git, with configurable branching (main / per-conversation / per-turn) and
opt-in PR creation. The token goes through GIT_HTTP_EXTRAHEADER, never the
command line, never the repo URL. Its pairsWith: "sandbox" metadata is not
decoration: sandbox + GitHub storage is the combination that lets an agent work
on a real repo without touching your disk.

Arc 3 — Observability, including the honest kind

Eval. runEval runs typed cases through a target, scores with bound scorers,
aggregates a report. Four deterministic scorers ship (exact-match,
regex-match, json-schema-valid, latency-budget). The LLM judge is
vendor-neutral by construction — the package carries no LLM SDK. You inject a
JudgeFn:

import { runEval, llmJudge, bindScorer } from "@agentproto/eval"

const report = await runEval({
  id: "summarise-suite",
  cases: [{ id: "c1", input: longDoc, expected: "concise summary" }],
  scorers: [bindScorer(llmJudge({
    id: "quality",
    judge: myAgentJudge,        // any async fn satisfying JudgeFn
    criteria: "Accurate, concise, no hallucinations?",
    mapOutput: ({ output }) => output,
  }))],
}, { target: async (doc) => summarise(doc) })

Telemetry. @agentproto/telemetry@0.2.0 ships an OTel adapter alongside the
existing sinks. @agentproto/telemetry-langfuse@0.2.0 ingests session turns into
Langfuse as traces, with atomic-drain flush on shutdown and per-case span trees.

Redaction. @agentproto/redaction@0.2.0, zero dependencies, four composable
redactors:

const redact = chainRedactors([denyListRedactor(), valueScanRedactor()])
redact.redact({ Authorization: "Bearer sk-ant-abc…", note: "use sk-live-xyz" })
// → { Authorization: "[redacted]", note: "use [redacted]" }

valueScanRedactor is the useful one — it catches secret shapes regardless of
the key name: PEM blocks, JWTs, sk- keys, AWS access key ids, GitHub and Slack
tokens. The runtime now defaults its telemetry tracer to the secrets redactor,
so turn events are scrubbed before they leave the process.

Cost, honestly. usage_update events now carry tokensIn, tokensOut, and
cost. deriveSessionUsage resolves them into a snapshot with a four-way
source tag:

`source`	meaning
`adapter`	the agent reported a real cost
`computed`	tokens priced against the in-repo LLM catalog
`no-pricing`	tokens exist, model isn't in the catalog — no price invented
`none`	nothing measured

That no-pricing state is deliberate. A dashboard that shows a confident wrong
number is worse than one that admits it doesn't know. (More on why per-token
pricing misleads you: cheaper per token is not cheaper per outcome.)

Also in the box

Gateway presets — moonshot (Kimi), openrouter, deepseek, usable from both claude-code and claude-sdk adapters. The ambient ANTHROPIC_API_KEY is scrubbed from env when a gateway base_url is set, so it can't leak to a third-party host.
Role registry + spawn-time privilege gate. Agents spawn as executor or supervisor, or a custom role from ROLE.md. A maxGrantableDelegation cap stops a role pack from self-granting delegation above your ceiling — a pack asking for more than the cap gets forced to deny. Why that gate exists: an agent that can spawn agents is a fork bomb with good intentions.
Worktree linkPaths — symlink gitignored dirs (read: node_modules) from the host repo into a fresh worktree, so pnpm install --prefer-offline resolves without a full reinstall. AgentStep.cwd binds to the provisioned path: provision → agent → gate → approval → cleanup.
agentproto_terminal — a live PTY panel over WebSocket in the MCP UI bridge.
Global defaults config — per-adapter skills/options auto-applied to every spawn, folded into each adapter's native option shape.
adapter-kit → provider-kit rename. @agentproto/adapter-kit@0.3.0 is a compat shim that re-exports everything. Old imports keep working.
Caption-first video ingestion in corpus import-web — subtitles first (fast, free), transcription only when captions are absent.

Go deeper

Each arc in this release is an argument made in code. Here's the argument in
prose — why the design went this way, and what it's defending against:

What shipped in 0.5	The thinking behind it
Credential broker, `mcp-header` exposure	`--approve-all` is how your agent ships the dangerous one (hands-on)
Role registry, `maxGrantableDelegation` cap, sandboxes	An agent that can spawn agents is a fork bomb with good intentions
Cost `source` tags, gateway presets	Cheaper per token is not cheaper per outcome
Eval harness, LLM-judge scoring	Your agent says the tests passed. It didn't run them.
Telemetry, redaction, the whole observability arc	You're optimizing the part of your agent you don't own
Caption-first `corpus import-web`	A folder of docs is not a knowledge base (hands-on) · Your coding agent knows the internet's average (hands-on)

npm i -g @agentproto/cli

Full notes: the 0.5.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.

agentproto 0.4.0 — the daemon grows up into a supervision surface

Agentik — Wed, 15 Jul 2026 16:35:01 +0000

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.

A Folder of Docs Is Not a Knowledge Base

Agentik — Tue, 14 Jul 2026 01:36:49 +0000

Disclosure up front: I build agentproto and its corpus
tooling, which is what the walkthrough uses. The commands are real and
checkable; the problem in the first half is one every RAG setup hits.
Corrections welcome — file an issue.

The advice is everywhere and it sounds complete: give your agent your knowledge —
just do RAG over your docs folder. So you point a retriever at docs/, embed the
chunks, and wire it up. The agent starts answering questions about your systems.

Then you ask it something that matters, and it gives you a fluent, confident
paragraph — and you have no idea whether it's true, because you have no idea where
it came from. Was that from the current runbook or a design doc you abandoned in
2024? Is that retry number the real one, or a chunk from a stale README that
happened to score well on cosine similarity? You can't tell. Neither can the
agent.

That's the tell that you don't have a knowledge base. You have a search index over
a pile of documents, which is a different and much weaker thing.

The one idea, if you remember nothing else:
A folder of docs is not a knowledge base. What makes it one is provenance —
every fact knowing which source it came from, so the agent can cite it and you
can check it.

The two things a doc dump can't do

A folder of markdown fails as a knowledge base for two structural reasons, and no
amount of better embeddings fixes either.

It retrieves prose, not facts. A document is a wall of sentences about many
things at once. Chunk it and you get arbitrary slices — half a paragraph about
retries glued to the start of a paragraph about logging. The agent gets near the
answer and reconstructs the rest, which is exactly where confident-but-wrong comes
from. The unit of knowledge should be a claim, not a 512-token window.

It forgets where everything came from. Once a chunk is embedded, it's just a
floating string. There's no thread back to "this is from runbooks/payments.md,
last touched in the April incident." So the agent can't cite, and — worse — you
can't audit. A knowledge base you can't audit is a knowledge base you can't trust,
which means it's a liability the first time it's confidently wrong.

Both problems have the same fix, and it's not a fancier retriever. It's a
pipeline: turn sources into atomic, sourced claims before anything queries
them. That pipeline is what separates a corpus from a folder.

What's your "knowledge base" actually made of?

Place yourself before you build. Four honest answers.

Nothing. The agent runs on pre-training and whatever you paste. Generic by
default. Ceiling: it never knows one thing that isn't already public.

A docs folder + RAG. You retrieve chunks by similarity. Better than nothing,
and it's the trap this piece is about: no provenance, no dedup, no notion of a
claim — it answers from sources it can't name. Ceiling: confident, unverifiable,
and stale the day a doc rots.

A hand-curated wiki. Real, human-maintained, often good — but it's written for
people to read, not for an agent to query claim-by-claim, and it goes stale
between the edits nobody makes. Ceiling: high quality, low queryability, manual
upkeep.

A distilled, sourced corpus. Sources imported with their origin attached,
distilled to claim-level entries, each carrying its provenance, queryable by topic.
This is the one an agent can cite and you can audit — and it's four commands.

Where are you? If your honest answer is "RAG over a docs folder," you have
the confident-but-unverifiable setup — the most dangerous kind, because it feels
like it works right up until it states a stale fact with a straight face. The
rest of this turns the pile into a corpus.

Step 1: import, and keep the receipt

Start by pulling your sources into a corpus workspace — and the non-negotiable is
that each source keeps a thread back to where it came from.

npm i -g @agentproto/corpus-cli

# scaffold an AIP-10 workspace (generic research preset, no seed noise)
corpus init house-knowledge knowledge/house --preset research

# import your sources; --tags is what makes the corpus queryable by topic later
corpus import-web knowledge/house --urls-file runbooks.txt --tags runbooks
corpus import-web knowledge/house --urls-file incidents.txt --tags incidents

Every imported source lands as an AIP-10 record carrying its originalUrl — the
provenance thread. An article comes in via readability; a walled page routes
through a browser; a recorded incident review or an architecture talk on video
comes in via transcription — same workspace, same provenance, so a decision your
team only ever said out loud becomes a citable source. Import is resumable: re-run
it and it skips what's already in, so you grow the corpus instead of rebuilding it.

Step 2: distill — turn documents into claims

This is the step a folder-and-RAG setup skips entirely, and it's the one that
matters. Distillation reads each source and emits atomic, claim-level entries,
roughly seven per source, each one carrying the source it came from.

# cheap + strong: distill on an open model via OpenRouter (saves frontier credits)
corpus distill knowledge/house --engine opencode -m openrouter/deepseek/deepseek-v4-pro

Now the unit of knowledge is a claim, not a chunk — "payment retries are capped at
3 with an idempotency key, per incident 2026-04" is one entry with one source, not
a slice of a paragraph that happened to embed nearby. When an agent retrieves this,
it retrieves the fact and its origin, which is what lets it answer "per
incident 2026-04…" instead of "a common approach is…". Provenance stops being
metadata and becomes the answer.

Why claims beat chunks, grounded. Anthropic's context-engineering guidance is
to keep the working context small and retrieve high-signal facts just in time
rather than pre-loading walls of text. You can't do just-in-time retrieval on a
document — it's too big and says too much. You can do it on a claim. Distillation
is what makes your knowledge retrievable at the right grain.

Step 3: gate the corpus — a knowledge base is maintained, not filled

A pile of docs is fill-once-and-forget. A corpus is an artifact you keep, so it
gets a quality gate before anything trusts it.

corpus validate knowledge/house    # schema-valid sources, 0 errors
corpus lint knowledge/house        # structural checks
corpus knowledge knowledge/house --tags incidents --max 20   # preview what an agent would pull

Two failure modes to catch here, because they're the ones that poison a corpus
quietly. A bad scrape — a retriever grabbing a cookie-wall or a nav menu
instead of the article — still gets distilled into confident-sounding entries;
grep for self-flags ("content does not match", off-topic nouns) and quarantine
them into a demoted/ folder so they never reach an agent. And coverage: for
each topic you care about, does the corpus actually have sourced claims, or is that
tag empty? A gap you find now is a gap the agent won't paper over with a guess
later.

This is the discipline the doc-dump never had: your knowledge base is only as
good as its worst source, so you check the sources.

Step 4: serve it — every agent, claim-level, sourced

Now the corpus becomes a tool. Back it with a knowledge.search driver pointed at
the workspace you just built, and serve it over MCP — the full contract-and-driver
pattern is its own walkthrough, but the payoff is one
environment variable and one command:

CORPUS_WS=knowledge/house agentproto serve   # serves knowledge.search to every agent

Every agent that mounts the daemon — Claude Code, Codex, a cheap local model — now
queries the same distilled, sourced corpus, and because the driver reads local
files, your knowledge never leaves the machine. Ask any of them your retry
policy and the answer comes back with incident 2026-04 attached. That citation
isn't decoration — it's the thing that lets a skeptical reviewer (human or agent)
check the answer against the source instead of trusting it.

The honest edges

A corpus is a real artifact, so it has real upkeep and real failure modes.

A wrong corpus is worse than no corpus. A stale claim gets retrieved with the
same confidence as a fresh one — now with a source attached, which makes it more
persuasive and more dangerous. Provenance is what saves you: because every claim
names its origin, a wrong answer is traceable to the stale source and fixable,
instead of an anonymous hallucination you can't hunt down. You maintain a corpus
like you maintain docs, because that's what it is.

Don't let the agent write your knowledge base. A corpus distilled from real
runbooks, incidents, and decisions is yours; one an agent generates about itself is
the internet's average with your repo's name on it. Distill from sources you'd
stand behind — the whole point is that the knowledge is earned, not synthesized.

And the fair comparison. Managed RAG products and vendor retrieval are less
setup — if you want "upload your docs, get a chatbot," they'll get you there faster,
and for some teams that's the right trade. What you give up is the two things this
whole piece is about: claim-level provenance you can audit, and a knowledge base
that lives in your repo, on your machine, not in someone's index. If your knowledge
is your edge, those aren't details.

Build the corpus, not the pile

Everyone rents the same models now, so the one part of the stack that's genuinely
yours is what your agent knows — and that's only true if what it knows is real.
A folder of docs behind a retriever gives you fluent answers from sources you can't
name and can't check, which is the exact opposite of what a knowledge base is for.

The fix isn't a better embedding model. It's a pipeline: import your sources with
their provenance intact, distill them into claims small enough to retrieve and
honest enough to cite, gate the result like the artifact it is, and serve it to
every agent you run. Four commands, and your agent stops guessing from a pile and
starts answering from a corpus — one where every fact can tell you exactly where it
came from.

Give your agent knowledge. Just make sure it's the kind that can show its work.

If you build your knowledge base a way that keeps provenance without the distill
step — or you've made folder-RAG genuinely auditable — tell me where. I'll fix the
piece.

Written by the maintainer of agentproto (Apache-2.0,
source) — a local, cross-vendor daemon for
running and governing coding agents. Same contract as our
/compare page: dated facts, named strengths,
corrections by issue. Got something wrong?
File an issue.

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

An Agent That Can Spawn Agents Is a Fork Bomb With Good Intentions

Agentik — Tue, 14 Jul 2026 01:36:46 +0000

Disclosure up front: I build agentproto, one of the
tools in this market. The primitives in the back half are real and the fields
are checkable; the problem in the front half is everyone's. Corrections
welcome — file an issue.

Here's the multi-agent dream, and it's a good one: you hand one capable agent a
big task, and instead of grinding through it alone, it spins up a little team —
one sub-agent to research, two to implement in parallel, one to review — waits for
them all, and hands you the merged result. An orchestrator that manages
orchestrators. It works, and it's genuinely powerful.

Now read that sentence again with an engineer's paranoia. An orchestrator that
manages orchestrators. If an agent can spawn agents, then the agents it spawns
can spawn agents. And nothing in "you can spawn a sub-agent" says where that
stops.

You already know this shape. It's the oldest prank in the Unix book:

:(){ :|:& };:   # a function that calls two copies of itself, forever

That's a fork bomb. It does nothing malicious — each copy just politely starts
two more, until the process table is full and the machine is on its knees. A
coding agent with an unbounded spawn tool is the same structure with a language
model in the middle and your API bill underneath.

The one idea, if you remember nothing else:
Spawning isn't a feature you turn on. It's a privilege you grant — and a
privilege with no depth, no breadth, and no ceiling is a fork bomb with good
intentions.

The privilege you're granting without noticing

When you give an agent a spawn_sub_agent tool, you're not just adding a
capability. You're granting it the right to grant itself the same capability,
recursively, as many times as its reasoning talks it into. Most setups make that
grant implicitly and totally: if the tool is in the toolset, spawning is
unlimited — any depth, any number of children, and each child just as privileged
as the parent.

Two things make that expensive fast, and neither is hypothetical. First, cost.
Anthropic's own guidance on sub-agents is that you isolate exploration in them
precisely because each one can burn ten thousand tokens to hand back a
five-line summary — cheap when it's one, a bonfire when a confused parent
spawns twelve and each of those spawns twelve. Second, the multi-agent reflex
itself is usually wrong:

The receipt that should slow you down. The sharpest orchestration writers
converge on one rule: the number of agents a job spawns is the **output* of
the orchestration decision, not the input.* You don't pick a multi-agent
workflow because you can — you pick it because the work's shape demands it. An
agent that spawns because spawning is available has skipped the only decision
that mattered.

So the problem isn't multi-agent orchestration. It's ungoverned spawning —
handing an LLM a recursive, self-replicating capability and trusting its judgment
to not run it off a cliff. The fix isn't "don't spawn." It's "make spawning a
metered privilege."

How does your setup bound spawning today?

Place yourself honestly before you build. Four postures, each with a ceiling.

Unbounded. Any agent holding the spawn tool spawns freely — any depth, any
count. Powerful, and one confused reasoning loop from a runaway tree and a bill
with a comma you didn't expect. Ceiling: the first agent that decides the answer
to "this is hard" is "spawn more agents."

Concurrency-capped by hand. You cap how many agents run at once, in your own
harness code, watching a dashboard. Better — but it's your attention doing the
capping, and it doesn't stop depth, just width at one instant. Ceiling: you,
watching.

Worktree-isolated only. You give each parallel agent its own git worktree so
they don't stomp each other's files — the near-universal isolation trick, and a
good one. But a worktree isolates the filesystem, not the right to spawn. A
tidily-isolated agent can still fork-bomb. Ceiling: clean files, unbounded tree.

Privilege-gated. Spawning is a role, capped by depth and breadth, and a child
can never grant itself more than the parent had. This is the one that can't run
away, and it's the one you can declare instead of police.

Where are you? If your honest answer is "any agent with the tool can spawn
as much as it wants," you don't have orchestration — you have a fork bomb that
hasn't gone off yet. The rest of this is four bounds that make sure it never
does.

Bound 1: spawning is a role, and most agents shouldn't have it

The first bound is the bluntest: most agents in a tree should be leaves that
physically cannot delegate. In agentproto that's a spawn-time role.

// this child does the work and CANNOT spawn — the spawn tools are removed
agent_start({
  adapter: "claude-code",
  role: "executor",        // leaf: agent_start / agent_prompt are stripped
  cwd: "/abs/host/path",
  prompt: "Implement the retry cap in src/payments/retry.ts. Do not delegate."
})

An executor is a leaf by construction: the agent_start and agent_prompt
tools are stripped from its toolset, and asking it to become an orchestrator
is simply ignored — no amount of clever prompting gives it back the ability to
spawn, because the capability isn't in the room. A supervisor may delegate.
That single distinction turns "every agent is a potential parent" into "spawning
is a named privilege that most of the tree doesn't hold."

This is the same lesson the OWASP Agentic Top 10 files under least agency:
give an agent only the autonomy its task needs. A worker implementing a function
doesn't need the right to raise an army. Take it away, and a whole class of
runaway trees becomes unrepresentable.

Bound 2: depth — the recursion has a floor it can't dig past

Leaves can't spawn, but supervisors can, and a chain of supervisors is still a
recursion. So the second bound caps how deep the tree can go, and makes the cap
one-directional.

agent_start({
  role: "supervisor",
  orchestrator: { maxDepth: 3, maxChildren: 8 },   // this subtree, bounded
  // …
})

maxDepth defaults to 3 and has a hard ceiling of 8 — a spawn that would
exceed it is rejected outright, not queued. The load-bearing detail is the
direction: a recursive spawn can only lower the inherited cap, never raise
it. A parent at depth 3 can hand a child a budget of 2; that child cannot hand
its child a budget of 5. The fork bomb's whole trick is unbounded recursion;
capping depth with a monotonically-shrinking budget removes the trick. The tree
has a floor, and nothing inside the tree can dig past it.

Bound 3: breadth — no single agent fans out into a swarm

Depth stops the tree going infinitely down; breadth stops any one node
exploding sideways. maxChildren defaults to 8 concurrently-alive
sub-agents per parent and, like depth, a recursive spawn can only lower the
inherited quota — never raise it.

That's the direct antidote to the :|: in the fork bomb — the part where one
process becomes two becomes four. Cap the branching factor and the geometric
explosion can't start. Combined with depth, your worst case is now a known
number of agents (maxChildren ^ maxDepth, and shrinking as it descends), not an
open-ended one. You can look at a spawn config and say exactly how bad a confused
run gets. That sentence is impossible in the unbounded world.

Cost gets its own hard stop. Independently of the tree shape, each session
takes maxCostUsd — a cumulative dollar ceiling; the session is stopped at the
next turn-end once it's exceeded. Depth and breadth bound the count; this
bounds the spend directly, so even a legal-sized tree of expensive turns has a
number it can't cross.

Bound 4: a child can't out-privilege its parent

The last bound is the subtle one, and it's what makes the other three trustworthy:
a child can never end up more powerful than the parent that made it. The daemon
enforces a privilege lattice — a spawn made through an orchestrator may only
create a role at or below the caller's own level, never something more privileged,
and an explicit tools allowlist can only ever narrow the toolset, never widen
it. A child can never grant itself scope its parent didn't have.

And the parent's view is boxed, too. The daemon mints a per-child scope-token,
injects a scoped sub-gateway into that child's session, and revokes the token
when the session exits. A parent's session_tree shows only its own subtree;
it can't see, prompt, or kill sessions outside its branch. Shell, filesystem,
remote, and import tools are never handed to an orchestrator child at all. So
the tree isn't just size-bounded — every node is capability-bounded to a shrinking
box, and the boxes evaporate when the work is done.

Four bounds, one property: you can hand an agent the genuinely powerful ability to
build and run a team, and still be able to state — before it runs — the maximum
depth, the maximum breadth, the maximum spend, and the ceiling on privilege. The
capability stays; the fork bomb becomes unrepresentable.

The honest edges (what bit me building this)

Real infrastructure, real sharp corners. Four I hit live:

The parent has to be Claude Code. A hermes parent silently ignores the injected orchestration gateway — it never mounts the spawn tools, so nothing happens. Children can be any adapter (cheap Haiku for trivial work); the parent that does the orchestrating must be Claude Code. If a parent reports "the orchestration tools aren't mounted," that's the tell.
Fan-in races fast children. A trivial child can finish its turn before the parent has wired up its wait — and turn-end is a transient event, so the wait times out on a child that already succeeded. Teach the parent the fallback: if the wait times out, read the child's output to confirm, or take an event cursor before spawning.
Killing the parent doesn't kill the children. The scope-token is revoked on parent exit, but the child processes are full sessions of their own. Kill the parent and each child (their ids are in session_tree), or you'll leak running agents.
cwd must be a real host path for every child — the daemon runs on your machine, and a child with no resolvable working directory just errors out.

And the fair comparison. Vendors do ship sub-agents — Claude Code's Agent Teams
will run a team for you, and inside one vendor's stack it's smooth and needs none
of this wiring. Two things a built-in team doesn't give you: the spawn tree stays
inside that vendor (your cheap open-model executors aren't invited), and the
governance is theirs, not a set of depth/breadth/role/cost bounds you declare and
own. If you live entirely in one vendor and never want a mixed fleet, take the
built-in — it's less work. If you want to spawn across vendors and sleep at
night, the bounds have to be yours.

Give it a team. Keep the blast radius finite.

The instinct to stop agents from spawning is the wrong lesson — spawning a team
is exactly the leverage that makes agents worth orchestrating. The right lesson is
that a self-replicating capability handed to a probabilistic reasoner needs the
same thing every other powerful capability needs: limits it can't rewrite.

So grant the privilege deliberately. Make most agents leaves that can't delegate.
Cap the depth so the recursion has a floor. Cap the breadth so no node fans into a
swarm. Cap the spend and the privilege so a child is always smaller than its
parent. Do that and "an agent that spawns agents" stops being a fork bomb and
starts being what you actually wanted: a team with a foreman, and a foreman who
can't accidentally hire the whole city.

Let the agent build its team. Just make sure the tree has a floor, the branches
have a limit, and the whole thing dies when the job's done.

If your orchestrator bounds spawning a cleaner way — or you've found a runaway
tree these four bounds wouldn't have caught — tell me where. I'll fix the piece.

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

'Approve All' Is How Your Agent Ships the Dangerous One

Agentik — Tue, 14 Jul 2026 01:36:42 +0000

Disclosure up front: I build agentproto, one of the
tools in this market. The primitives in the second half are real and the
commands are checkable; the problem in the first half stands on its own.
Corrections welcome — file an issue.

You gave your coding agent a shell. Now you live in one of two bad houses.

In the first house, every risky command stops and asks you. Can I run
git push? Can I delete this file? Can I curl this? You approve, approve,
approve — and somewhere around the two-hundredth reflexive yes, the one request
that actually mattered slides through on muscle memory.

In the second house, you got tired of that and ran the agent with
--dangerously-skip-permissions. Now it never asks. It also never asks before
the rm -rf in the wrong directory, or the DROP TABLE against the wrong
DATABASE_URL, while you're at lunch.

The one idea, if you remember nothing else:
Auto-approve reads. Gate writes. The line isn't risky vs. safe — it's
does this change state.

Both houses share one bug: they treat "should the agent need approval?" as a
property of your attention — how much you're willing to click — instead of a
property of the action. Fix that, and the whole problem changes shape.

The line everyone draws in the wrong place

Ask ten teams where the approval boundary goes and you'll get three wrong
answers. By tool category: "shell is dangerous, file-read is fine" — except
cat ~/.aws/credentials is a read that exfiltrates and echo can clobber a
file. By reversibility: "block the irreversible stuff" — except you can't
reliably tell at call time what's reversible. By vibes: skip-all until
something breaks.

The boundary that actually holds is simpler and it's not about the tool at all:

Draw it at state mutation. One widely-cited write-up on human-oversight for
code agents (Niklas Heidloff) lands on the exact rule: auto-approve only the
commands that don't change state; gate the ones that do. Not by tool, not by
reversibility — by whether the world is different afterward. A pure read can run
free. A write waits.

And here's why "just approve each one" was never going to save you, stated by the
people who studied it: manual-approve, skip-all, and static allowlists all fail
the same way. Review every action and you hit approval fatigue — after hundreds
of reflexive yeses the dangerous request gets one too. Skip everything and you've
armed the agent. A static allowlist rots the moment the agent needs something
new. The failure isn't your discipline; it's asking a human to be the runtime
permission check.

That's the same wall from the trust piece,
wearing a different hat: you are the serial bottleneck, and "approve each action"
just moves the bottleneck to your clicking finger.

How do you gate a risky call today?

Place yourself before you build. Four honest answers, each with its ceiling.

You approve each one. Every gated call pings you; you click yes. Safe-ish,
and completely unscalable — this is the approval-fatigue trap, and it caps at one
agent you babysit full-time. Ceiling: you, again.

You skip all of it. --dangerously-skip-permissions, YOLO mode. Fast, fully
unattended, and one hallucinated path from a very bad afternoon. Ceiling: the
first destructive command nobody caught.

You keep a static allowlist. A file of pre-blessed commands. Better — but it's
frozen; the agent hits something new and either stalls or you widen the list until
it's *. Ceiling: it can't tell a read from a write, so it over- or
under-blocks.

You classify by risk and relay only the writes. Read-only calls auto-approve;
state-changing calls pause and route to a decision — a human or a policy — and
the important ones surface instead of drowning. This is the only one that scales,
and it's the one you can build. The rest of this piece wires it.

Where are you? If your honest answer is "skip-all, and I hope," you don't
have an autonomy setup — you have an unexploded one. Everything below moves the
yes/no off your attention and into the architecture.

Rung 1: make the tool declare its own risk

The relay only works if a call knows whether it mutates before it runs. So put
the risk class on the tool contract, not in a human's head. In agentproto a tool
declares what it changes; a read-only tool mutates nothing and approves itself:

// a read-only tool — nothing changes, so it runs free
export const knowledgeSearch = defineTool({
  id: "knowledge.search",
  // …schema…
  mutates: [],              // touches no state
  approval: "auto",         // ⇒ auto-approved, never interrupts you
})

// a write tool — declares the mutation, so it must be cleared
export const applyPatch = defineTool({
  id: "fs.apply_patch",
  // …schema…
  mutates: ["fs"],          // changes files on disk
  approval: "gated",        // ⇒ pauses for a decision before it runs
})

That's "auto-approve reads, gate writes" as two lines of contract instead of a
policy you enforce by clicking. knowledge.search from
the knowledge piece is literally mutates: [] for
exactly this reason. The boundary is now data, so a machine can enforce it — which
is the whole point of making approval, in the words of one human-in-the-loop
build (Nylas), a first-class architectural feature, not an afterthought you
bolt on per tool.

Rung 2: the permission relay — a pause, not a wall

Now the gated calls need somewhere to go that isn't a modal blocking your
terminal. agentproto turns a pending write into an item in a cross-session inbox:
the agent pauses, the decision waits, and anyone — or anything — can answer it.

# what's waiting on a decision right now?
permissions_list
# → [{ id: "perm_9f", sessionId: "sess_42",
#      tool: "fs.apply_patch", summary: "write migrations/003_add_index.sql" }]

# answer it — approve once, approve-always, or deny
permissions_respond { id: "perm_9f", decision: "approve" }

Two things this buys that a terminal prompt doesn't. First, it's out of band:
the approval isn't trapped in one attached session, so a supervisor (or you, from
your phone) can clear it without sitting in front of the agent. Second, it's
programmable: decision is just approve / deny, so the responder can be a
human for the calls that need judgment and a policy for the calls that don't.

The relay is the L2 rung, built. The supervision ladder
maps the whole climb from you watch to a gate decides; this is the L2
"permission relay" rung as actual wiring. Read-only auto-approves (Rung 1),
risky writes land here, and only the genuinely judgment-worthy ones ever reach a
person. Approval fatigue dies because the reads never showed up in the first
place.

Relaying the write to a human is fine for a DROP TABLE. But for "did this diff
actually fix the bug," a human clicking approve is just a slower version of the
agent grading itself. Some writes need a check, not a click.

Rung 3: put an external check on the write — and stage the commit behind it

The top rung replaces the human judgment call with something that scales: a gate
that runs outside the working agent and has to say yes before the write lands.
You attach it to the session, it fires at the end of the agent's turn, and its
verdict — not the agent's self-report — decides what happens next.

// attach a gate to the session; a green result stages a commit behind YOUR ack
attach_policy({
  sessionId: "sess_42",
  then: "commit",
  gate: {                              // a shell gate: exit 0 = pass
    command: "pnpm",
    args: ["test", "--run", "payments"]
  },
  commit: {
    paths: ["src/payments/retry.ts"],  // stages EXACTLY these — never `git add -A`
    message: "fix: cap payment retries at 3 (incident #2026-04)",
    requireHumanAck: true              // green gate ⇒ waits for your yes
  }
})

The lifecycle is the part that matters: the gate runs, and on green the policy
doesn't commit — it moves to awaiting-ack and emits policy:commit-ready. The
commit does not happen until you call ack_policy({ policyId, approve: true }),
which stages only the listed paths (git add -- <paths>, never -A, never a
glob), commits, and emits policy:committed. It never pushes. The agent cannot
reach past the gate to the commit; the gate cannot reach past your ack to the
push.

When exit codes can't judge, spawn a skeptic. Swap the shell gate for
gate: { judge: { adapter, prompt } } and agentproto runs a short-lived LLM
reviewer that ends in VERDICT: PASS|FAIL — fail-safe, so a timeout or an
unparsable answer counts as FAIL. Prompt it to refute, not admire ("try to
prove this diff did NOT fix the bug"). That's the kill-the-loop
lesson in one primitive: the check has to sit outside the loop it's checking, or
it rubber-stamps.

You now have the full plane: reads run free, writes relay, load-bearing writes
wait on an external verdict, and the irreversible act — the commit — is staged
behind one human yes.

The honest edges (the gotchas that bit me)

This is real infrastructure, which means it has sharp corners. Four I hit live,
so you don't:

The gate runs against an allowlist, and test isn't on it. Shell gates go through the same default-deny allowlist as any command (.agentproto/allowed-commands.json). test -f x fails with not in allowlist → the policy goes blocked. Use an allowlisted binary — ls x, not test -f x; pnpm/node for tests.
The gate's working directory is anchored to the workspace. A session whose cwd is outside the workspace fails the gate with cwd escapes the workspace. If you run agents in per-feature worktrees outside the repo root, shell gates are effectively unusable — fall back to then: "emit" (milestone only) and verify the result yourself with git/gh.
Attach before the turn ends. The gate fires on turn-end; attach the policy before the session finishes its turn (spawn idle → attach → prompt), or you race the event and miss it.
The durable auto-supervisor is still volatile. The RoutineRunner that would babysit this across many steps is an in-memory MVP today — a daemon restart drops in-flight runs. The pieces that survive are the ones above: attach_policy, the event bus, the ack. Don't build a control tower on the part that isn't load-bearing yet.

And the fair comparison, because credibility depends on it. Claude Code already
ships a good version of Rung 1–2 — per-command permission prompts and an
allowlist, built in, zero setup. If you live entirely in one vendor's agent,
you may not need to wire any of this. Two things you're trading for that
convenience: the approval dies with the session (close the terminal, lose the
relay), and it's single-vendor — it won't clear a pending write from your Codex
agent or a cheap local model. An approval plane that spans every agent you run,
and survives your laptop sleeping, is the part a per-tool prompt can't give you.
The broader principle underneath all of it is OWASP's least agency: grant the
minimum autonomy, tools, and credential scope the task needs — and make the
grant a decision the architecture enforces, not one you re-make by clicking.

Give it the keys, keep the ignition

Autonomy was never the scary part. An agent that can read your whole codebase,
run your tests, and draft the fix is exactly what you want. The scary part is the
write — the one command that changes something you can't un-change — landing
because you were too tired to catch it or too far away to be asked.

So stop deciding approval with your attention and start deciding it with the
action. Auto-approve the reads; they can't hurt you. Relay the writes; a human or
a policy clears them. Put an external check on the writes that matter, and stage
the one irreversible act — the commit — behind a single deliberate yes. The agent
proposes. Something outside the agent disposes. That's the whole plane.

Give your agent the keys. Just keep the ignition where it can't reach it.

If your setup draws the approval line somewhere smarter than state mutation, or
you've made approve-each actually scale, tell me where — I'll fix the piece.

The series — Orchestration, Honestly

Ten pieces, one argument. Start anywhere; each one cross-links the rest.

	Piece	The one idea
1	You can't parallelize the trust	Amdahl's Law: why your fifth agent slows you down
2	Harness engineering	you rent the model; the harness is the part you own
3	The supervision ladder	five rungs of trusting an agent you don't watch
4	The approval plane (you're here)	auto-approve reads, gate writes — wire the line between
5	Kill the loop	why "keep going until done" compounds a wrong turn
6	Route by cost	plan expensive, execute cheap, verify independently
7	Files with contracts	the interop layer every agent system reinvents
8	Knowledge is power	give your agent your knowledge, not the internet's average
9	Paseo, hands-on	a full real-session review of the daemon
10	9 orchestrators, compared	the tool-by-tool teardown + a decision table

Written by the maintainer of agentproto (Apache-2.0, source). Same contract as our /compare page — dated facts, named strengths, corrections by issue. Got something wrong? File an issue.

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

You're Optimizing the Part of Your Agent You Don't Own

Agentik — Tue, 14 Jul 2026 01:36:40 +0000

Disclosure up front: I build agentproto, one of the
tools in this market. Every fact below is dated and sourced; the tool-by-tool
review lives in
9 coding-agent orchestrators, compared where
competitors' strengths are named. Corrections welcome — file an issue.

Open any dev feed this week and count how many arguments are about the model.
Which one codes best. Which one dropped. Which benchmark moved two points.

It's the wrong fight. Here's the receipt that should end it:

The receipt. LangChain took a coding agent from rank 30 to the top 5 on
Terminal-Bench without changing the model — the wins came from the scaffolding
around it, not a better brain. Same weights, thirty places, harness only.

Sit with that. The single biggest jump they got came from the part you can
actually edit — and most people spend their attention on the part they can't.

You rent the model. You own the harness.

You did not train the model. You can't change its weights, you can't see its
training data, and next quarter the vendor swaps it for a new one and your
carefully-tuned prompts quietly stop meaning what they meant. The model is a
rental. It's a good rental — but it's not yours, and it moves under you.

The harness is everything you wrap around that rental to turn a raw
token-predictor into something that ships work: the system prompt, the tools, the
memory, the loop, the checks, the sandbox it runs in. Anthropic's own harness
team defines it exactly this way — the harness is "everything wrapped around a
model that turns raw capability into completed work."

The one idea, if you remember nothing else:
You rent the model. You own the harness. Stop optimizing the rental.

And it turns out the harness is the bigger lever anyway. LangChain's own writeup
is one data point; the broader pattern is that harness-only changes repeatedly
beat model swaps. The field even has a name for the discipline now —
"harness engineering" — with a whole awesome-list of tools for it. The model got
commoditized while you weren't looking. The scaffolding is where the craft moved.

Which era are you working in?

There's a clean way to place yourself, and it's basically the history of this job
in three steps. Anthropic's context-engineering post lays out the first two; the
long-running-agent writeups add the third. Find the one that sounds like your
week.

Era 1 — prompt engineering. You get better results by wording the ask
better. Few-shot examples, "think step by step," role-play framing. This still
matters, but it's table stakes now, and it's the most fragile layer — a model
upgrade can silently rewrite what your clever phrasing does.

Era 2 — context engineering. You realized the bottleneck isn't the wording,
it's what's in the window. Anthropic's framing: treat context as a finite
attention budget, because recall degrades as the window fills — "context rot,"
where attention spreads thinner across every added token. You curate what the
model sees, load facts just-in-time, and keep state on disk instead of in the
transcript.

Era 3 — harness engineering. You stopped tuning any single call and started
designing the system the model runs inside: the loop, the tools, the roles, the
gates, the sandbox. The model became one swappable component in a machine you
built.

Where are you? If your honest answer is "I write really good prompts,"
you're in Era 1 — doing real work on the most rented, most fragile layer. Every
rung past here is about moving leverage into the part you keep.

Most teams are stuck somewhere in Era 1, blaming the model for failures the
harness was supposed to catch. So let's climb.

Rung 1: a loop grounded in truth, and nothing more

The minimal harness is almost embarrassingly small. Anthropic's "Building
effective agents" reduces it to one line: an agent is a tool-using model in a
loop, grounded in feedback from the real environment. Not a framework. A loop
that checks reality.

Start there and resist the urge to add. The same post is blunt about it: begin
with the simplest thing and add complexity only when it measurably helps,
because frameworks bury the actual prompts and responses under abstraction and
make failures harder to debug. Most "my agent is dumb" bugs are a harness that
grew faster than it earned.

The tell. If you can't name what each piece of your scaffolding is for —
which specific model weakness it patches — that piece is probably cargo. The
loop grounded in ground truth is the only part you always need.

Rung 2: get the right things into the window, keep the rest out

Once the loop works, the next failure is the model drowning in its own history.
This is the Era-2 move made structural. The long-running-agent playbooks compress
it to three verbs — Reduce, Offload, Isolate:

Reduce — compact old tool calls into summaries once history crosses a threshold, so the window stays high-signal.
Offload — write the plan, the progress, and the rules to a file on disk (a NOTES.md, a task list), not the transcript. State outside the context window survives a reset; state inside it evaporates.
Isolate — push exploration into sub-agents with clean windows that burn ten thousand tokens and hand back a five-line summary. The dirty context never touches the main thread.

The knowledge you feed it is part of this budget too — and whose knowledge
decides how much of the internet's average you're stuck with, which is
its own piece. The rule underneath all of it:
the best context is the smallest set of high-signal tokens that lets the model
take its next step — even when the window could hold a thousand times more.

Rung 3: stop letting the worker grade its own work

Here's the harness component people skip, and it's the one that fails silently.
An agent asked "are you done?" says yes too early — models grade their own
output too leniently, seeing a button render and calling the feature shipped.
Anthropic's harness team found the fix isn't a smarter prompt; it's a
structural split, a generator-and-evaluator loop where the two roles are
separate and the evaluator is tuned to be skeptical.

The mature version splits three ways — planner, generator, evaluator — because
each targets a different failure: the planner fixes under-scoping, the generator
does the work, the evaluator catches the lie. This is the whole spine of the
supervision ladder; the point here is narrower —
the evaluator is a harness component you install, not a mood the model gets
into. Bolt it outside the working agent's loop, or it grades itself and passes.

Receipt. This is also why "just loop until done" isn't reliability. A loop
gives the agent persistence, not correctness — the completion check has to live
outside the loop or it rubber-stamps a wrong turn fifty times. That argument
has its own piece.

Rung 4: make the parts swappable

The resilient harness treats the model as a component, not the center of gravity.
Addy Osmani's long-running-agent writeup names the split cleanly — decouple the
Brain, the Hands, and the Session:

Brain — the model plus its loop. Replaceable: swap Claude for a cheap open model on a task that doesn't need frontier reasoning.
Hands — the ephemeral sandbox where code runs and gets thrown away.
Session — the durable state and history, which outlives any single run.

Decoupled, each part upgrades on its own clock. Your rented Brain changes every
quarter; your Hands and Session don't have to. This is also what makes cost
routing possible at all — plan on an expensive Brain, execute on a cheap one, and
the routing math only works because the harness let you
swap the engine without rebuilding the car.

There's an interop tax hiding here, though: today every tool speaks its own
dialect of "agent behavior as files" — CLAUDE.md, AGENTS.md, SKILL.md, all
mutually invisible — so a capability you built for one Brain doesn't travel to the
next. Fixing that with contracts instead of yet another framework is
a companion piece.

Rung 5: the best harness engineers delete scaffolding

Now the counterintuitive top of the ladder, and the part almost nobody says out
loud. Every piece of your harness encodes an assumption that the model is bad at
something. When the model gets good at it, that piece becomes dead weight.

Multiple harness writers land on the same warning independently — it's the Bitter
Lesson arriving at the application layer. The context resets, the sprint
decomposition, the elaborate verification dance: each one exists to patch a
weakness in this model generation. LangChain's own history shows it — the same
scaffolding that lifted an agent to the top 5 becomes drag once a stronger model
ships and no longer needs it.

The move most teams miss. On every model upgrade, don't just enjoy the
bump — re-audit your harness and rip out the scaffolding the new model made
pointless. The harness that wins in 2026 is lighter than the one that won in

Growing your harness forever is how you end up slower than someone running a plain loop on a better model.

That's the discipline in one sentence: build the scaffolding the model needs
today, and be ruthless about deleting it the day it doesn't.

The vendors will sell you a harness. It just won't be yours.

Here's the fair part, because the whole argument depends on it. The model vendors
are shipping harnesses too, and they're good. Claude Code is a harness. Managed
Agents is Anthropic's hosted meta-harness — session, sandbox, and loop
virtualized behind a stable interface, April 2026. If you want the harness to be
someone else's problem, that is a genuine, less-work answer, and I won't pretend
otherwise.

Two things you're trading away, though, and they're exactly the two the whole
piece has been about. A hosted harness is their harness, wrapped around
their model, on their plan — so you can't prune it (Rung 5 isn't yours to
do), and you can't swap the Brain for a cheaper or open one (Rung 4 is off the
table). You've rented the model and the harness. The one part that was supposed
to be yours went back to being a rental.

The alternative is to own the harness as portable infrastructure — the checks,
the contracts, the roles living in your repo and running on your machine,
around any model. That's the whole design of what I build:
agentproto is a local daemon with adapters for Claude
Code, Codex, and open models via OpenRouter or Hermes, so the harness you tune
travels when you swap the engine, and no vendor holds the keys. Concede the
hosted route is less setup. Just know what you gave up to skip it.

Tune the car, not the rental

So the feed has it backwards. The model you're all arguing about is the one thing
in the whole system you can't change and won't keep. The harness — the loop, the
context budget, the evaluator, the swappable parts, the scaffolding you're brave
enough to delete — is the part that's yours, the part that moved a coding agent
thirty places without a new model, and the part your competitors are ignoring
while they refresh the benchmark leaderboard.

Two questions turn this into Monday's work. When your agent fails, do you reach
for a better prompt, or do you ask which harness component was supposed to catch
it? And when the next model drops, do you just feel faster — or do you open your
harness and delete what it made obsolete?

Rent the best engine you can. Then go build a car worth putting it in.

If your harness beats this framing — or you've found a scaffold worth keeping that
I'd have told you to cut — tell me where. I'll fix the piece.

The series — Orchestration, Honestly

Ten pieces, one argument. Start anywhere; each one cross-links the rest.

	Piece	The one idea
1	You can't parallelize the trust	Amdahl's Law: why your fifth agent slows you down
2	Harness engineering (you're here)	you rent the model; the harness is the part you own
3	The supervision ladder	five rungs of trusting an agent you don't watch
4	The approval plane	auto-approve reads, gate writes — wire the line between
5	Kill the loop	why "keep going until done" compounds a wrong turn
6	Route by cost	plan expensive, execute cheap, verify independently
7	Files with contracts	the interop layer every agent system reinvents
8	Knowledge is power	give your agent your knowledge, not the internet's average
9	Paseo, hands-on	a full real-session review of the daemon
10	9 orchestrators, compared	the tool-by-tool teardown + a decision table

Written by the maintainer of agentproto (Apache-2.0, source). Same contract as our /compare page — dated facts, named strengths, corrections by issue. Got something wrong? File an issue.

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

9 Coding-Agent Orchestrators, Honestly Compared (Dated, Sourced, and One of Them Is Mine)

Agentik — Tue, 14 Jul 2026 01:36:37 +0000

Disclosure up front: I build agentproto, one of the
nine tools below. Every fact is dated and pulled from each project's own docs
or repo; where a competitor beats me, it says so in plain text. Corrections
welcome — file an issue, I'll fix it.

Most "best orchestrator" roundups rank. They hand you a leaderboard, crown a
winner, and leave you to discover three weeks later that the winner solves a
problem you don't have.

This one doesn't rank. It places. Because the awesome list has grown past
fifty entries and
half of them changed shape in the last six months — so the useful question was
never "which is best," it's "which one fits the specific way my setup hurts."

The one idea, if you remember nothing else:
A ranking tells you who won. A map tells you where you are. Two questions
locate any orchestrator on it — who checks the work, and who equips the
agents — and almost every tool answers one while quietly dodging the other.

Those two questions are the ones the landscape
piece ends on, and they're not
arbitrary. They're the two halves of the bottleneck that caps every agent
fleet: the judgment that decides "done" is true, and the plumbing that gets a
new capability to every agent instead of one. Everything else a tool advertises
— panes, voice, kanban swimlanes — is UX on top of how it answers those two.

Method: each project's own docs and repo, checked 2026-07-07 → 2026-07-14, plus
hands-on sessions where noted. Supervision rungs refer to
the ladder: L0 you watch, L1 watchdogs, L2
permission relay, L3 verifier loops, L4 external policy gates.

The two questions, and why the map has two axes instead of ten

Strip a tool's branding and it answers two questions or dodges them.

Question one — who checks the work? When the agent says "done," what decides
whether that's true? This is the supervision ladder: at the bottom (L0) the
checker is you, reading a diff; at the top (L4) it's a process the agent can't
see or sweet-talk, holding the commit until a gate passes. The rung is the
answer.

Question two — who equips the agents? When you give one agent a new tool or
skill, how many of the others get it for free? For almost every tool the answer
is zero — you rewire each agent by hand, which is the quiet serial tax nobody
puts on the pricing page. The vendors equip agents, but only inside their own
walls. Exactly one tool on this list distributes your tools to every agent;
that's its own companion piece.

Plot both and the field sorts into a shape, not a ranking. Cockpits answer
question one with your eyeballs and dodge question two. Steering tools give the
human a nicer surface and dodge both. Only the daemon shape can even reach the
top-right corner — and only one is standing there. Let's walk the map.

The daemons: the only shape that can answer both

A daemon is a long-lived process that owns sessions behind an API. It's the only
shape that can run unattended — which is the only shape that can answer
question one above rung L2, and question two at all.

agentproto (disclosure: mine)

Local daemon + CLI, Apache-2.0, 0.5.0-alpha. Nine adapters under one manifest
contract (Claude Code, Claude SDK with Anthropic/Moonshot/OpenRouter gateways,
Codex, Hermes, opencode, Mastra Code + Agent, browser-as-agent). The three bets
are exactly the two questions plus the safety to delegate them:

Checks the work: L4. A completion policy attaches to a session; at turn-end a gate fires — a shell command (lint/tests/typecheck) or a skeptical judge model — and the commit is staged behind a human ack. It runs on the daemon, so it survives your laptop closing.
Equips the agents: yes — and this is the rare one. You author a tool once (a TOOL contract + a DRIVER implementation, plain files) and the daemon serves it over MCP to every agent; external MCP servers can be imported and handed to any agent at spawn. Write once, every agent gets it.
Role-gated nested orchestration: executors can't spawn, supervisors can (with depth and children caps), so an agent can safely manage a team without fork-bombing your machine.

Weaknesses, honestly: alpha APIs that will move under you, no mobile client, no
voice, terminal-native UX only. And of ~52 numbered AIP specs, the daemon plus
core adapters are operational — the rest is early scaffolding. If your
bottleneck is steering from a phone, this is the wrong tool; keep reading.

Paseo — the strongest steering tool on this list

The other real daemon, and — credit where it's due — the best tool here for
driving agents from anywhere. 10.3k★ (as of 2026-07-13), AGPL-3.0, a one-man
company. Daemon plus
desktop / iOS / Android / web / CLI clients, QR pairing, voice control (local or
OpenAI STT/TTS), an official Docker image, and a self-hostable web UI. Five
first-class providers (Claude Code, Codex, Copilot, OpenCode, Pi) plus custom
ones — custom binaries, ACP agents, Anthropic-compatible endpoints like Z.AI and
Qwen. Recurring schedules with run history. Its MCP server is opt-in
(daemon.mcp.enabled) so Claude Desktop or Code can drive it.

I didn't just read the docs — I installed it and ran the permission relay end to
end. Launch an agent in always-ask mode, watch it freeze on a Write, approve
from another terminal with paseo permit allow, task completes. It works
exactly as advertised.

Two gotchas from the actual session (2026-07-13). The default Claude model
is Opus, so our one-word "hi" cost $0.29 before we'd typed a real prompt.
And every run spins up a fresh workspace unless you pass --workspace. Full
log in the hands-on review.

Now place it on the map. Checks the work: L2/L3 — it relays the agent's own
permission prompts to a nicer surface, plus a Ralph-loop skill with an optional
verifier. There's no L4: no daemon-side turn-end gate, no commit staging.
Equips the agents: no — injectIntoAgents pushes Paseo's control tools
into agents, but there's no way to write your tool once and have every agent
get it. So: unbeatable at question one's ergonomics, silent on question two. If
your bottleneck is steering from the couch, stop here — it's excellent.

The cockpits: your eyeballs are the checker

A cockpit is an interface you sit inside and review from. Every one answers
question one with "you, watching" (rung L0) and question two with "you, rewiring
each agent by hand." That's not a knock — for exploratory work L0 is the right
rung. It's a ceiling, and the ceiling is your own attention.

The ceiling, measured. Tools whose supervision model is "a human watches
each pane" have no programmatic API, no per-turn gates, and state that
evaporates when the app closes — the ladder piece has the exact
wall. Teams then hand-roll tmux-plus-Redis
watchdogs to compensate — reinventing a daemon badly.

Claude Squad — the terminal-first classic.

AGPL-3.0 TUI over tmux + git worktrees, multi-agent (Claude Code, Codex, Gemini,
Aider), brew install claude-squad (needs tmux + gh). One isolated workspace per
task, review by hand. L0 by design — you are the loop. No API, so question two
never even comes up.

Conductor — the most polished L0 cockpit.

Closed-source Mac app: clones your repo, gives each agent (Claude Code, Codex,
Cursor) its own git-worktree workspace, with a genuinely strong diff viewer and
PR flow. A Conductor Cloud variant exists. macOS only, no programmatic surface —
review throughput is the whole product, and it's good at it.

Crystal → Nimbalyst — the shape outlives the app.

Crystal (Stravu's Electron app, the first GUI for parallel Claude Code/Codex
sessions in worktrees) was deprecated in February 2026; Nimbalyst is the
successor — same model plus a session kanban, a linked task board, one-click
worktree isolation, a per-session diff sidebar, and the only native iOS app in
the category with push-on-input. Still L0 at heart, but the mobile monitoring
nudges it toward "watch from anywhere." Open-source, Mac/Windows/Linux + iOS.

Vibe Kanban — the cautionary data point.

The agent kanban board — and the reason "who maintains this?" is a real column
in the table below.

The sustainability receipt, now dated. Bloop, the company behind Vibe
Kanban, shut down in April 2026; the project survives only as
community-maintained open source with its cloud services sunset. It's not
alone — Opcode (formerly Claudia) is no longer actively developed, and Crystal
became Nimbalyst. Evaluate open-source agent tools as local tools you own,
not as SaaS with a support guarantee. (Nimbalyst's own 2026 roundup of
agent-management tools makes the same point.)

The batch runner and the remote control

Two tools that look like supervision from a distance and turn out to answer
question one with an asterisk.

Claude Code Agent Farm — L1, and honest about it.

MIT Python batch runner: throw dozens of Claude Code instances at a lint/type-fix
queue (its repo demos 20+), coordinated by tmux + lock files, with an HTML
report and a workload watchdog that auto-restarts stalled agents. That watchdog
is its answer to question one — and a watchdog keeps the process alive, it
says nothing about whether the output is right. Restart twenty stalled agents
enough times overnight and by morning you don't have correct code — you have
twenty confident reports and one shared mistake, multiplied. Claude Code only,
by design. The right tool for exactly one job, and it doesn't pretend otherwise.

Omnara — L2, plus the sharpest architecture lesson on the list.

YC S25, Apache-2.0 apps. Syncs coding-agent sessions (Claude Code, Codex, n8n)
across terminal, web, and mobile, with notifications and human-in-the-loop
replies — so its answer to question one is "you, from your phone" (L2). In 2026
it pivoted to a hosted, voice-first managed-agents platform. The pivot carries a
lesson worth more than the feature list:

Don't build on a CLI you don't control. Omnara originally wrapped the
Claude Code CLI and had to abandon that architecture — constant upstream CLI
changes made the wrapper unmaintainable. It rebuilt on the stable Claude Agent
SDK. Intercepting a fast-moving interactive CLI is a losing architecture; build
on a programmatic layer. (Per Omnara's own GitHub README.)

The competitor that isn't on the awesome list

Here's the fair part, because credibility depends on it. The biggest competitor
to every tool above isn't a third-party tool — it's the model vendors absorbing
orchestration natively, and their integration reaches deeper than any outsider's
can.

What shipped, dated. Claude Code Agent Teams; Dynamic Workflows (Claude
writing its own orchestration script); Outcomes — a grader model that
scores work against your rubric and forces retries, a legitimate L3;
Advisor — a cheap executor consulting a stronger model mid-turn; and
Managed Agents, Anthropic's hosted meta-harness. If you're an all-Claude shop
on a Team plan, that's a real answer to question one, closer to the model than
I'll ever sit.

So why does third-party orchestration outlive it? Two structural limits, and
they're both about the two questions.

The catch that sends you cross-vendor. Every vendor stack is
single-vendor by construction — Advisor has the same single-vendor,
encrypted-advice catch as Agent Teams; see the landscape
piece for the compatibility-table
breakdown. That rules out the exact case where checking pays off most: a cheap
open executor judged by a stronger model. And it all lives on their plans and
their infrastructure.

That matters because open weights caught up. On SWE-bench Verified (July 2026)
the frontier is GPT-5.6 Sol at 96.2 and Claude Fable 5 at 95 — but the best
permissively-licensed models, GLM-5.2 (MIT, 82.8), Kimi K2.7 (78.2) and
DeepSeek-V4 (MIT, 76.2), now match proprietary frontier from a few months back
at a fraction of the price. The rational 2026 fleet is mixed — and a mixed fleet
only pays off if something external, cross-vendor, catches the $0.10 model's
mistakes before merge (the routing math is its own post).
The vendor stacks, by design, can't be that something.

The long tail (and what it's actually solving)

amux, cmux, dmux, mux (yes, all of them), clideck, thurbox, agentbox, AGX,
sortie, tutti… Most are cockpit or batch-runner variants — same two answers as
their bigger cousins. The interesting outliers aren't orchestrators at all:
coordination micro-protocols like gnap (git-as-task-board), swarm-protocol
(MCP work-claiming), and wit (AST-level function locks). They solve agent
collision — two agents clobbering the same file — not agent supervision.
Useful, but a different question than either of ours. Full zoo in the
awesome list.

The table (the receipt)

Read it as a coordinate grid: the two middle columns are the two questions.

Tool	Shape	Who checks the work	Who equips the agents	License / status	The honest catch
agentproto (mine)	daemon	L4 — turn-end gate, judge, commit behind ack, survives disconnect	your tools → every agent (TOOL/DRIVER + imported MCP)	Apache-2.0, 0.5.0-alpha	alpha APIs, no mobile/voice, terminal-only
Paseo	daemon	L2/L3 — permission relay, Ralph loop	injects its own control tools only	AGPL-3.0, 10.3k★	no L4 gates, no user tools; Opus default is pricey
Claude Squad	TUI cockpit	L0 — you, in a pane	you, by hand (no API)	AGPL-3.0, community	caps at 2–5 agents; dies at screen-lock
Conductor	Mac cockpit	L0 — you, great diff viewer	you, by hand (no API)	closed, free	macOS only, no programmatic surface
Nimbalyst (ex-Crystal)	cockpit + iOS	L0 + mobile push-on-input	you, by hand	open-source	Crystal deprecated Feb 2026; still eyeballs
Vibe Kanban	kanban board	L0 — you, on a board	you, by hand	community-maintained	Bloop shut down Apr 2026
Agent Farm	batch runner	L1 — a liveness watchdog	n/a (one vendor, one job)	MIT, community	keeps it alive, not correct; Claude Code only
Omnara	remote control	L2 — you, from your phone	n/a (hosted)	Apache-2.0, YC S25	pivoted to hosted; approval fatigue
Vendor-native (Claude)	in-product / hosted	L3 — Outcomes grader, inside the walls	vendor equips, per-product only	proprietary	single-vendor; Advisor advice encrypted

(Facts from each project's own docs/repos, 2026-07-07 → 2026-07-14. The
vendor-native row is unpacked in
the state-of piece.)

Pick by the shape of your pain, not by a ranking

There is no best tool, only best fits. Find your bottleneck; the map picks for
you.

Steering from the couch or phone, best-in-class UX → Paseo (or Omnara if you'd rather it be hosted).
Terminal cockpit, hands-on review, no lock-in → Claude Squad; Mac-native with a great diff viewer → Conductor; want a board + the only native iOS app → Nimbalyst.
Grinding a mechanical fix queue with one vendor → Agent Farm.
All-Claude shop on Team/Enterprise, happy inside one vendor → the native stack (Agent Teams / Dynamic Workflows / Outcomes).
Unattended runs, mixed-vendor fleets, a real check before merge, and your own tools distributed to every agent → agentproto.

The tie-breaker, if two rows look close. Ask the two questions out loud
against your actual week. If your pain is "I can't watch fast enough,"
question one sorts you — climb the supervision
ladder. If your pain is "I keep re-wiring the same
tool into every agent," question two sorts you, and today almost nothing
answers it. Steering tools answer neither; they add cockpits in front of the
same bottleneck.

That's the whole map. Nine tools, two questions, one honest table — and the one
row I built is disclosed as mine on every line. A ranking would've told you I
won. A map tells you something more useful: exactly which pain each of us was
built to kill, and which we quietly left on the table.

If I've mis-rated where your tool sits, or a dated fact has gone stale since I
checked, tell me where — I'll fix the piece.

The series — Orchestration, Honestly

Ten pieces, one argument. Start anywhere; each one cross-links the rest.

	Piece	The one idea
1	You can't parallelize the trust	Amdahl's Law: why your fifth agent slows you down
2	Harness engineering	you rent the model; the harness is the part you own
3	The supervision ladder	five rungs of trusting an agent you don't watch
4	The approval plane	auto-approve reads, gate writes — wire the line between
5	Kill the loop	why "keep going until done" compounds a wrong turn
6	Route by cost	plan expensive, execute cheap, verify independently
7	Files with contracts	the interop layer every agent system reinvents
8	Knowledge is power	give your agent your knowledge, not the internet's average
9	Paseo, hands-on	a full real-session review of the daemon
10	9 orchestrators, compared (you're here)	the tool-by-tool teardown + a decision table

Written by the maintainer of agentproto (Apache-2.0, source). Same contract as our /compare page — dated facts, named strengths, corrections by issue. Got something wrong? File an issue.

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

Your Coding Agent Knows the Internet's Average. Here's How to Make It Know Yours.

Agentik — Tue, 14 Jul 2026 01:36:33 +0000

Disclosure up front: I build agentproto, whose
knowledge and operator primitives are the back half of this piece. The problem
in the first half stands on its own, and the walkthrough uses real, checkable
commands. Corrections welcome — file an issue.

Open Claude Code. Open Codex. Open a cheap local model in the same repo. Ask all
three the same question about your codebase — your retry convention, your deploy
runbook, why that one service is the way it is.

You'll get three fluent, confident, near-identical answers. And all three will be
wrong in the same way: they'll describe how a reasonable team does it, not how
yours does. They're all running the same frontier weights, trained on the same
public internet, so out of the box they all know exactly the same thing.

The one idea, if you remember nothing else:
The weights are everyone's. Your knowledge base is the only part of the stack
that's yours — and the only thing that makes the agent yours instead of the
internet's average.

The model stopped being the differentiator

Here's the shift most people missed while arguing about benchmarks. The gap
between the best model and the tenth-best is collapsing — the hub piece
has the Stanford AI Index receipt (the #1-to-#10 spread fell from 11.9% to 5.4%
in a year). When the weights converge, the weights stop being your edge.

What replaces them is system design. One widely-cited 2026 essay on the evolution
of agents put it bluntly: agent capability has moved from model quality to
system design — from writing a clever prompt to engineering what the model can
see. The clever prompt is a commodity now. The context isn't.

The receipt that reframes the whole market. In a production-readiness
comparison of agent frameworks, one finding held across every orchestration
style tested: retrieval quality dominates knowledge-agent performance
regardless of orchestration. You can have the best planner-worker-judge
topology in the world; if the agent is retrieving from the internet's average
instead of your world, it answers like a stranger.

So the interesting question stopped being "which model?" and became "what does it
know that no one else's does?" JetBrains' framing is useful here: some agents are
action-first (their value is what they do) and some are data-first
(their value is what they can access). A coding agent for your team is
data-first whether you designed it that way or not.

The uncomfortable part: if you haven't attached your knowledge to your agent,
you're shipping the stranger.

Which tier is your agent on?

Run the self-diagnosis before you build anything. There are three tiers, and most
teams are stuck on the first two without noticing.

Tier 0 — no knowledge base. The agent knows what the pre-training run knew:
public GitHub, Stack Overflow, docs up to some cutoff. Ask it about your world and
it pattern-matches to the nearest public example. It's confident and it's generic.
Ceiling: it will never know a single thing that isn't already on the internet.

Tier 1 — pasted into context. You dump the runbook, the conventions doc, a few
past PRs into the prompt (or a CLAUDE.md) and hope. It works — until the context
fills up. Anthropic's context-engineering post is direct about why this caps out:
you have to treat context as a finite attention budget, because recall decays
as the window grows ("context rot").

Why Tier 1 has a hard ceiling. The same post prescribes the fix — keep
lightweight references and retrieve just-in-time, not pre-load everything.
Pasting your whole knowledge base into every prompt is the exact anti-pattern:
it's expensive, it rots, and it doesn't scale past a handful of documents. A
KB you paste is a KB you'll soon truncate.

Tier 2 — a served, queryable knowledge base. Your knowledge lives in one place,
gets indexed, and every agent queries it on demand — pulling only the three
relevant entries for the question at hand, with their sources attached. This is
just-in-time retrieval, done properly, shared across every agent you run.

The jump from Tier 1 to Tier 2 is the whole game — and it's the "who equips the
agents" question from the files-with-contracts piece,
pointed straight at knowledge. Let's build it.

Step 1 — an operator that already knows where to look

Start with the packaged shape, because it shows the target. In agentproto, an
operator (the AIP-9 OPERATOR.md) is a persona plus policies plus a set of
bound tools — and one of those tools is a knowledge binding.

# operators/house-engineer/OPERATOR.md — persona + policies + a KB binding
---
name: House Engineer
id: house-engineer
profile:
  role: Answer and act using OUR conventions and past incidents, never generic defaults.
  voice: Concrete, cites the runbook or incident it's drawing from.
tools:
  - knowledge-query          # ← the bound knowledge tool
  - shell
policies:
  - "policy:engineering/house-rules"
metadata:
  corpus:
    knowledgeViews:
      - corpus: engineering
        filter: { tags: [conventions, runbooks, incidents] }
---

Read what that knowledgeViews block does: it scopes the operator to your
engineering corpus, filtered to the tags that matter. The persona decides how it
answers; the policies decide what it's allowed to do; the knowledge view decides
what it knows. Three separate concerns, one file.

This is a real shape, not a mock. The research operators shipped in
agentproto's own corpus — source-scout, research-analyst — carry exactly
this: tools: [knowledge-query, ...] plus a metadata.corpus.knowledgeViews
binding scoped by domain and quality score. The operator is the packaging.
Underneath it is a tool, and the tool is the part that ports to any agent.

An operator is what "give the agent your knowledge" looks like when it's one
declared file. Now let's build the tool that backs it — the part that reaches
agents that never heard of your operator format.

Step 2 — the knowledge.search tool, authored once

This is the exact move from the files-with-contracts piece,
specialized to knowledge: split the contract (what the tool promises) from the
driver (the code that answers). Here's the contract — a pure defineTool,
no execute body.

// tools/knowledge-search/TOOL.ts — the contract, and nothing else
import { defineTool } from "@agentproto/tool"
import { z } from "zod"

export const knowledgeSearch = defineTool({
  id: "knowledge.search",
  description:
    "Answer from OUR knowledge base: conventions, runbooks, past incidents. " +
    "Returns refined entries, each with the source it came from.",
  inputSchema: z.object({
    query: z.string(),
    tags: z.array(z.string()).default([]),
    limit: z.number().default(5),
  }),
  outputSchema: z.object({
    entries: z.array(z.object({
      kind: z.string(),
      title: z.string(),
      body: z.string(),
      source: z.string(),      // provenance — where this knowledge came from
    })),
  }),
  mutates: [],                 // read-only → no approval gate
  approval: "auto",
})

Now the driver — the implementation, bound to the contract by implementTool. It
reads your corpus workspace off local disk and returns the matching entries.

// drivers/knowledge-corpus.ts — backed by your own corpus workspace
import { defineDriver, implementTool } from "@agentproto/driver"
import { knowledgeSearch } from "../tools/knowledge-search/TOOL.js"
import { resolveKnowledge } from "@agentproto/corpus"
import { NodeFsAdapter } from "@agentproto/corpus/fs"

export default defineDriver({
  id: "knowledge.search.corpus",
  name: "Knowledge search over your corpus workspace",
  kind: "in-process",
  implementations: [
    implementTool(knowledgeSearch, async ({ input }) => {
      // the same resolver behind `corpus knowledge <ws> --tags … --max …`
      const hits = await resolveKnowledge({
        fs: new NodeFsAdapter({ root: process.env.CORPUS_WS! }),
        query: { tags: input.tags, maxResults: input.limit },
      })
      return {
        entries: hits.map((h) => ({
          kind: h.kind,
          title: h.title,
          body: h.body,
          source: h.sources.join(", "),
        })),
      }
    }),
  ],
  network: { egress: [] },     // reads local files → your knowledge never leaves the box
})

That driver is the real corpus resolver — the same resolveKnowledge call that
sits behind corpus knowledge <ws> --tags conventions,incidents --max 5 on the
command line, now exposed as a tool. The network.egress: [] line is doing quiet
but load-bearing work: the knowledge is queried from local files, so it never
leaves your machine.

Provenance is a feature, not decoration. Every entry carries its source —
the runbook, the incident, the PR it was distilled from. That's what lets an
external check — the supervision ladder's whole
point — verify the answer later: the LLM-as-a-judge literature evaluates RAG on
two sides, context relevance going in and faithfulness coming out (did the
answer actually follow the retrieved source, or wander off it?). No provenance,
no faithfulness check.

One contract, one driver, and now every agent that mounts the daemon can answer
from your world. Serve it.

Step 3 — the same question, with and without your knowledge

Start the daemon. It reads your tools/ and drivers/ and serves them over MCP,
knowledge.search included.

npm i -g @agentproto/cli
agentproto serve                 # serves the /mcp gateway to every agent

Now spawn an agent with the tool, and ask it something it could only know from
your docs — a convention set by a past incident:

agentproto sessions start codex --cwd . \
  --prompt "What's our retry policy for the payments queue? Use knowledge.search."

→ Per incident #2026-04 (double-charge on gateway timeout), payment retries are
  capped at 3 with jittered backoff, and we NEVER retry a charge without an
  idempotency key. Source: runbooks/payments-queue.md, incidents/2026-04.md

Now the same agent, same question, without the tool:

agentproto sessions start codex --cwd . \
  --prompt "What's our retry policy for the payments queue?"

→ A common approach is exponential backoff with 3–5 retries and a dead-letter
  queue after the final attempt…

The second answer isn't wrong — it's the internet's average, and it's exactly
what you'd get from any agent, anywhere. The first answer knows about the
double-charge you shipped in April, because it read your incident file. That
delta — a real past incident it could only learn from your knowledge base — is
the entire difference between an agent and your agent.

Cross-vendor, by construction. That was Codex. Point Claude Code or a cheap
local model via Hermes at the same daemon and they call the identical
knowledge.search — because it's served over MCP, not baked into one vendor's
config. Author the KB tool once; every agent in your fleet inherits your world.

The Guilde parallel: the same primitive, packaged

Here's the honest framing, because overclaiming is how you lose a reader. In
Guilde — our AI-company product — attaching a knowledge
base to an agent is one packaged step: an operator ships with an attached
corpus, and you apply it to a scope in a single command. Persona, policies,
knowledge, done.

What you just built by hand in agentproto is that same primitive, one floor down:
an operator (Step 1) plus a served knowledge tool (Step 2). Guilde adds the
one-command packaging; agentproto is the from-primitives path you can run today,
in your own repo, on your own machine, with no platform to adopt.

What agentproto does not do yet, stated plainly. There's no single
apply-knowledge-pack verb in the open CLI — you wire the tool, the driver,
and the operator yourself, as three files. That's more assembly than the
packaged version. It's also fully inspectable and fully yours, which for a
knowledge base — the most sensitive thing you'll attach to an agent — is often
the trade you want.

The primitive is identical either way: an operator with a queryable knowledge
tool. One product packages it; the other hands you the parts.

The honest edges

A knowledge base is not magic, and three caveats keep it honest.

A wrong KB is worse than no KB. If your knowledge base contains a stale
convention, the agent will state it with the same confidence as a correct one —
now with a source attached, which makes it more persuasive and more dangerous.
This is why the faithfulness check above matters: retrieval quality is the whole
ballgame, and a KB is an artifact you maintain, not a bucket you fill once.

Don't let the agent write its own knowledge base. ETH Zurich research
(Gloaguen et al.) found that LLM-generated AGENTS.md files provided no
benefit and could reduce success rates. A knowledge base curated from real
incidents, runbooks, and decisions is yours; one the agent hallucinated about
itself is just the internet's average with your repo's name on it. Curate the
KB like you'd curate docs — because that's what it is.

And it's the most sensitive thing you'll attach. Your incidents, your
conventions, your internal decisions — that's exactly the data you don't want
leaving your network. The network.egress: [] driver above isn't a detail; it's
the reason this whole pattern runs locally. Your knowledge is your edge precisely
because it's private, so the tool that serves it should keep it that way.

Knowledge is the part you own

Every team in 2026 rents the same frontier weights. That was always going to
commoditize — the models converge, the benchmarks compress, and the clever prompt
becomes a thing anyone can copy. What doesn't commoditize is what your agent knows
that no one else's does: your codebase's conventions, your runbooks, the incident
that taught you never to retry a charge without an idempotency key.

That knowledge is the one layer of the stack you actually own. Attaching it isn't
a nice-to-have on top of a good model — after the models converged, it's the
only move left that makes your agent yours. An operator with a queryable
knowledge tool, served locally to every agent you run. Three files, and the
stranger becomes a colleague.

So run the diagnosis one more time, honestly: does your agent know your world, or
just the internet's average of it? If it's the average, you don't have an agent
problem. You have a knowledge problem — and it's the good kind, because the fix is
entirely in your hands.

If your setup already attaches knowledge a cleaner way, or I've mis-described how
your KB reaches your agents, tell me where — I'll fix the piece.

The series — Orchestration, Honestly

Ten pieces, one argument. Start anywhere; each one cross-links the rest.

	Piece	The one idea
1	You can't parallelize the trust	Amdahl's Law: why your fifth agent slows you down
2	Harness engineering	you rent the model; the harness is the part you own
3	The supervision ladder	five rungs of trusting an agent you don't watch
4	The approval plane	auto-approve reads, gate writes — wire the line between
5	Kill the loop	why "keep going until done" compounds a wrong turn
6	Route by cost	plan expensive, execute cheap, verify independently
7	Files with contracts	the interop layer every agent system reinvents
8	Knowledge is power (you're here)	give your agent your knowledge, not the internet's average
9	Paseo, hands-on	a full real-session review of the daemon
10	9 orchestrators, compared	the tool-by-tool teardown + a decision table

Written by the maintainer of agentproto (Apache-2.0, source). Same contract as our /compare page — dated facts, named strengths, corrections by issue. Got something wrong? File an issue.

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

Kill the Loop: Why `while true` Is Not Reliability

Agentik — Tue, 14 Jul 2026 01:36:30 +0000

Disclosure up front: I build agentproto, which runs
checks inside an agent's loop rather than only at the end. Everything about
why that matters you can verify without me — the sources are named and dated,
and I'll concede where the plain loop is exactly right. Corrections welcome,
file an issue.

You gave your agent a loop, closed the laptop, and went to bed.

The whole pitch of the overnight loop is that it keeps going. while true; do cat prompt.md | claude -p; done — it wakes back up every time it stalls,
re-reads the plan, and grinds on until a checklist is green. You come back to a
finished feature and a clean exit code. Sometimes that's a miracle. Sometimes
it's a very tidy way to have built the wrong thing four hundred times.

The one idea, if you remember nothing else:
A loop gives your agent persistence, not correctness. And a wrong turn, held
with conviction and looped, is just a faster way to be wrong.

Persistence is not correctness

A loop is a liveness guarantee. It promises the process will keep running; it
promises nothing about whether the process is pointed the right way. Those are
two different properties, and the whole overnight-autonomy genre quietly conflates
them. "It's still going" feels like "it's still on track" at 2am. It isn't.

Geoffrey Huntley named the mechanism precisely when he described the Ralph
technique as a deterministic loop wrapped around a non-deterministic model —
the bet being that repeated attempts converge on a working solution. That bet is
real, and often it pays. But convergence has a direction, and the loop doesn't
supply it. The loop supplies fuel.

Why the direction can be wrong. Each Ralph iteration starts with a fresh
context window but inherits all prior work from the filesystem — code, commits,
notes — which it treats as ground truth and builds on (Sid Bharath, "the
dumbest smart way to run coding agents," 2026). That's the strength on a good
run. On a bad one, iteration two builds on iteration one's mistake, iteration
three trusts both, and the error stops looking like a bug and starts looking
like the codebase.

So an unsupervised loop doesn't self-correct. It self-reinforces. It pays
compound interest on your first wrong turn — confidently, on a timer, with every
pass making the mistake more load-bearing and more expensive to unwind. The
scariest output of a runaway loop isn't a crash. It's a green checkmark on top of
a bad foundation.

The check at the finish line is the check that arrives too late

"Fine," you say, "I gated it — the loop only exits when the tests pass and it
prints COMPLETE." Good instinct, wrong position. A terminal gate fires after
the loop has already burned the budget and stacked the tower. By the time your
end-of-run check has an opinion, the wrong thing is built, tall, and load-bearing.

And the completion signal you're trusting is more fragile than it looks.

The exit condition is a suggestion, not a safety mechanism. A completion
promise is typically a static exact-match string with no OR conditions — so it
can silently never fire if the wording drifts. The thing that actually bounds a
runaway loop is the iteration cap; long loops can plausibly cost $30–150 in
API spend, so you never run one without one (The AI Agent Factory, 2026).
Read that again: the mechanism keeping your loop from running forever is a
counter, not a judgment. It stops the spend. It doesn't check the work.

The deeper problem is that the failures that matter most are invisible to any
single moment — including the last one. Apollo Research, whose Watcher tool
monitors coding agents, splits agent failures into two shapes, and the split is
the whole game.

Two failure shapes, two different checks. Some failures live in a single
action — deleting files, leaking a secret, a force-push — and must be blocked
synchronously, before execution. Others only emerge over many turns — scope
creep, a confidently wrong diagnosis, premature "done" claims — and no single
action reveals them; they have to be judged over the trajectory
(Apollo Research,
2026). A terminal gate sees exactly one moment. The drift that sinks you lives
in the shape it can't see.

Self-diagnosis: when does your loop check its work?

Here's the one question that sorts every autonomous setup. When does your loop
check its work — only at the very end, or partway through? If the only
checkpoint is the completion gate, you are blind to the exact class of failure
that compounds: the one that builds up quietly across turns and looks fine right
up until it's enormous.

Run the honest audit on your own harness. Between kickoff and the final green
check, how many times does something other than the agent look at where it's
going? For most overnight loops the answer is zero — the agent grades its own
progress every iteration, and a generator grading itself is the plateau the whole
supervision ladder is built to escape.

Receipt from the trajectory list. Apollo's rubric of multi-turn failure
modes reads like a confession of every bad overnight run: premature completion
claims without verification, ignoring user corrections, confidently wrong
diagnoses, scope overreach, fabricated APIs, and — my favorite — repeating a
failing command 3+ times without changing strategy. A loop is a machine for
doing that last one at scale.

If your check lives only at the finish line, the loop's superpower — never giving
up — becomes its failure mode. It will never give up on the wrong path, either.

The wrong fix: a watchdog that restarts you into the same groove

The reflex, when a loop misbehaves, is to make it more persistent: auto-restart
on stall, replay the last message in a fresh session, keep it alive through
context overflow and API errors. That's a watchdog, and it's genuinely necessary
plumbing for unattended runs — but it is the exact wrong tool for this problem.

A watchdog keeps the process breathing and says nothing about whether the process
is right. It will cheerfully restart a wrong loop into producing the same wrong
answer until sunrise — the supervision ladder
calls this L1, and the reason it's the lowest automated rung is that "alive" and
"correct" are different axes. Restarting a confidently-wrong agent doesn't
interrupt the self-reinforcement. It refuels it.

Alive ≠ on-track. Health-monitoring harnesses track context usage, idle
time, and error counts, then act: clear context below a threshold, restart
agents that stall, disable them after N consecutive errors (Claude Code Agent
Farm, 2026). Every one of those signals is about liveness. None of them asks
the only question that matters mid-flight: is this still the right thing to be
building?

So the fix can't be "keep it going better." It has to be something that can make
it stop going the wrong way — partway through, before the tower is tall.

The fix: an external skeptic that runs during the loop

The check has to move two places at once: outside the agent (a different
context, ideally a different model — a generator can't be its own skeptic) and
inside the timeline (running alongside the loop, not waiting at the exit).
That's the ladder's L3/L4 external-judge idea, but
applied continuously instead of only at turn-end.

This is precisely what a trailing monitor does, and Apollo measured the payoff
and its limit in the same breath.

Catch the drift early or don't bother. When a trailing monitor scores a
session over threshold on scope-overreach or premature-completion, injecting a
short system-reminder-style nudge — "you were asked to fix the login bug but
are now refactoring the session module" — generally steers the agent back.
But effectiveness drops the further the agent has already committed to the
wrong path, so the monitor must run frequently enough to catch drift early
(Apollo Research,
2026). That sentence is the entire argument for killing the terminal-only gate:
the redirect that works cheaply at turn three is nearly useless at turn thirty.

The redirect gets weaker exactly as fast as the loop's confidence gets stronger.
Compound interest, running the other way. A check that only fires at the end
isn't a safety net; it's an autopsy.

And because the monitor is a separate context, it can be a separate provider —
which is a feature, not an accident.

Don't let the agent pick its own referee. Models share blind spots with
themselves: a monitor from the same family tends to trust the agent's reasoning
patterns — Apollo observed Claude models being too trusting of their own
reasoning, GPT models over-suspicious as graders. Mixing providers across the
monitoring pipeline yields oversight that doesn't inherit the supervised
agent's biases. The skeptic works best when it isn't the defendant's cousin.

Building it: interrupt the loop, don't just watch it end

Concretely, the difference is one structural move. Here's the naive loop
everyone starts with — one check, at the very end:

# The terminal-gate loop: blind between iterations
while true; do
  cat prompt.md | claude -p --dangerously-skip-permissions
  grep -q "COMPLETE" progress.md && break   # the ONLY check, and it's last
  [ $((i++)) -ge 50 ] && break              # the counter, not a judgment
done

Everything between kickoff and COMPLETE is unsupervised. Now put a skeptic
inside the timeline — an external monitor that reads the trajectory at every
turn boundary and can halt-and-redirect partway through, even mid-way through a
sub-agent's run:

// A mid-flight monitor: runs alongside, can interrupt — not a watchdog
{
  "sessionId": "sess_…",
  "cadence": "every-turn",              // not "on-exit"
  "monitor": { "judge": {
    "adapter": "gemini",                // a DIFFERENT provider than the executor
    "prompt": "Score scope-overreach, wrong-diagnosis, premature-completion 0–1. Quote the turn."
  }},
  "onDrift": {                          // trajectory failure → steer, early
    "above": 0.6,
    "action": "nudge",
    "text": "You were asked to fix the retry test, not rewrite the queue. Return to the task."
  },
  "onIrreversible": { "action": "block" } // single dangerous action → stop, synchronously
}

That's the reversibility split in config: single dangerous actions get blocked
before they run; multi-turn drift gets caught early, while the redirect still
works. The monitor lives in a daemon, so it keeps checking after your screen
locks — and because it's an external adapter, it runs on any executor: Claude
Code, Codex, or a cheap GLM/DeepSeek model via Hermes. The loop keeps its
persistence; you just stop letting it persist unsupervised.

This matters most where the money is. A mixed fleet — frontier model plans, cheap
model executes in a loop, the routing math its own post —
is where self-reinforcement is cheapest to trigger and most expensive to catch
late. The $0.10 executor will loop confidently into a wall; something external has
to notice before iteration thirty.

Kill the loop, not the iteration

To be fair to the loop, because fairness is the point: for a low-stakes,
disposable, sandboxed project, the plain overnight loop is the right tool.
Someone shipped a full prompt-history feature to a React Native app from an
11-task list for about $1, exiting early at iteration 8 on the completion
sentinel — it compiled and worked (demo talk, 2026).
Well-scoped, throwaway, checked by real tests: loop away. The trouble starts the
moment it's code you're accountable for — "the loop wrote it" has never once
been a defense.

So "kill the loop" doesn't mean kill iteration — iteration is how these agents
converge at all. It means kill the unsupervised loop: the one whose only check
sits at the finish line, refueled by a watchdog, grading its own homework every
pass. Keep the while true. Just put a skeptic inside it, running alongside,
allowed to interrupt.

Because a loop, on its own, is confidence with an exit code. Persistence isn't the
same as being right, and this whole series turns on one question first asked in
the hub piece: when your agent says
"done," what — other than the agent — decided that was true? A loop answers
"nothing, but enthusiastically." The only real answer is to have something that
isn't the agent look at where it's going before it gets there.

If your loop already checks itself mid-flight, or I've mis-drawn where the
terminal gate fails you, tell me where — I'll fix the piece.

The series — Orchestration, Honestly

Ten pieces, one argument. Start anywhere; each one cross-links the rest.

	Piece	The one idea
1	You can't parallelize the trust	Amdahl's Law: why your fifth agent slows you down
2	Harness engineering	you rent the model; the harness is the part you own
3	The supervision ladder	five rungs of trusting an agent you don't watch
4	The approval plane	auto-approve reads, gate writes — wire the line between
5	Kill the loop (you're here)	why "keep going until done" compounds a wrong turn
6	Route by cost	plan expensive, execute cheap, verify independently
7	Files with contracts	the interop layer every agent system reinvents
8	Knowledge is power	give your agent your knowledge, not the internet's average
9	Paseo, hands-on	a full real-session review of the daemon
10	9 orchestrators, compared	the tool-by-tool teardown + a decision table

Written by the maintainer of agentproto (Apache-2.0, source). Same contract as our /compare page — dated facts, named strengths, corrections by issue. Got something wrong? File an issue.

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

DEV Community: Agentik

Your coding agent runs a shell on your machine. I audited mine.

The one idea

Run these four questions on your own tool first

What I found, by threat class

The command-filter myth, and what replaces it

Prove the boundary; don't ship a guessed profile

Not calling home

The methodology, in five lines

Where it landed

agentproto 0.8.0 — the daemon makes decisions so you don't have to

permissions watch: your agent stopped asking permission

Worktree isolation as policy, not convention

Your CI can speak agentproto now

The LLM endpoint learned to say "try again"

Skills are now built, not hand-copied

The getting-started path works end to end

Also in the box

The arc from 0.5 to 0.8

Upgrading

agentproto 0.6 + 0.7 — pair two machines through a broker that can't read your traffic

Pairing: the broker is deliberately stupid

The same treatment for serve --connect

Breaking: Claude Code spawns now demand explicit credentials

Worktrees grew a lifecycle — and a gc that learned restraint the hard way

The gc ate a live worktree on July 15th

Your agent stopped guessing about permission

Also in the box

The VS Code extension stopped lying to you

0.7.0, a day later: the polish pass

Migrating from 0.5 to 0.7

Go deeper

agentproto 0.5.0 — credentials, sandboxes, and cost accounting that refuses to lie

Arc 1 — Auth: the secret never touches your env

Arc 2 — Sandboxes: stop running agents against your filesystem

Arc 3 — Observability, including the honest kind

Also in the box

Go deeper

agentproto 0.4.0 — the daemon grows up into a supervision surface

Durable cron, on the daemon

Scriptable wait — delete your polling loop

The WorkflowRunner primitive

Structured transcripts

Tool verbs, renamed to a family-first taxonomy

The first in-process adapter (AIP-45)

Reliability fixes worth naming

Onboarding

Go deeper

Notes before you upgrade

A Folder of Docs Is Not a Knowledge Base

The two things a doc dump can't do

What's your "knowledge base" actually made of?

Step 1: import, and keep the receipt

Step 2: distill — turn documents into claims

Step 3: gate the corpus — a knowledge base is maintained, not filled

Step 4: serve it — every agent, claim-level, sourced

The honest edges

Build the corpus, not the pile

An Agent That Can Spawn Agents Is a Fork Bomb With Good Intentions

The privilege you're granting without noticing

How does your setup bound spawning today?

Bound 1: spawning is a role, and most agents shouldn't have it

Bound 2: depth — the recursion has a floor it can't dig past

Bound 3: breadth — no single agent fans out into a swarm

Bound 4: a child can't out-privilege its parent

The honest edges (what bit me building this)

Give it a team. Keep the blast radius finite.

'Approve All' Is How Your Agent Ships the Dangerous One

The line everyone draws in the wrong place

How do you gate a risky call today?

Rung 1: make the tool declare its own risk

Rung 2: the permission relay — a pause, not a wall

Rung 3: put an external check on the write — and stage the commit behind it

The honest edges (the gotchas that bit me)

Give it the keys, keep the ignition

The series — Orchestration, Honestly

You're Optimizing the Part of Your Agent You Don't Own

You rent the model. You own the harness.

Which era are you working in?

Rung 1: a loop grounded in truth, and nothing more

`permissions watch`: your agent stopped asking permission

The same treatment for `serve --connect`