You Can Parallelize the Typing. You Can't Parallelize the Trust.

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.

There's a folk formula going around for the 2026 coding stack:

problems ≈ N · agents · parallelism

The more you fan out, the more problems you spawn. It gets nods because it
matches the felt experience — but it's wrong, and how it's wrong is the most
useful thing you can learn about this whole market.

Running one coding agent is a solved problem. Running five is a lifestyle
disease.

"Today I have Claude Code and Codex CLI and Codex Web running, often in
parallel." — simonw, HN

"I'm not convinced there is any hope for a productive, long-term,
burnout-free parallel agent workflow." — grim_io, HN

Between those two quotes sits the entire orchestration market. Everyone runs
multiple agents now; almost everyone is quietly burning out babysitting them.

MindStudio put a number on something I'd only felt: agent burnout hits at hour
4, not hour 8. Supervising agents swaps a few big decisions a day for dozens of
micro-decisions an hour, and that specific drain empties people in four or five
intense hours. Hitting
the wall early isn't a discipline problem. It's a signal — and the signal has a
name you already know.

The law nobody thought to apply to themselves

Amdahl's Law says the speedup you get from parallelism is capped by the fraction
of the work you can't parallelize. Throw a hundred cores at a job that's 10%
serial and you never beat a 10× speedup — ever. The serial part is the ceiling,
and buying more cores doesn't move it.

For a coding-agent fleet, the serial part is you: reading the diff, deciding
what's actually true, catching the thing the agent quietly slipped in. And you
don't fork.

The one idea, if you remember nothing else:
You can parallelize the typing. You can't parallelize the trust.

Agents made typing free and infinitely forkable. They did nothing for the part
that was always the bottleneck — someone deciding the work is correct before it
ships. Add agents past your review bandwidth and you don't go faster; you grow
the queue in front of the one worker who can't be cloned. That's not burnout as
a vibe; it's burnout as arithmetic.

The market read the symptom and sold the wrong cure. Practitioners consistently
report the limiting factor isn't generation speed, it's whether the output is
correct — the hours vanish into re-reading diffs for sneaked-in changes, an
agent reordering unrelated UI tabs during a one-line label change. Everyone
shipped you more cores. Almost nobody shipped you a smaller serial fraction.

So before you evaluate a single tool, answer one question: which shape is your
setup, and where exactly does it cap you?

Which orchestration shape are you stuck in?

Strip the branding and every tool is one of four shapes. Find yours, then find
its ceiling.

Shape 1 — the cockpit. An interface you sit inside and review from: TUIs
like Claude Squad (brew install claude-squad — tmux panes plus git worktrees
per task), Mac apps like Conductor and Nimbalyst, kanban boards like Vibe
Kanban. These are genuinely good; the cockpit wins decisively the moment two or
three tasks run at once, because it kills the manual worktree juggling.

Receipt. Crystal — the first GUI for parallel Claude Code sessions — was
deprecated in February 2026; Nimbalyst replaced it with feature parity and no
migration. The shape is durable even as individual apps churn.

The cockpit's ceiling is pure serial fraction. It optimizes how fast one human
reviews, and that wall arrives sooner than people plan for — the ladder piece
has the exact number. A nicer pane doesn't raise
the ceiling; it just makes 2am prettier.

Shape 2 — the loop / batch runner. "Keep going until done." The Ralph
technique (Geoffrey Huntley, July 2025) is the whole genre in one line:
while true; do cat prompt.md | claude --dangerously-skip-permissions -p; done.
Claude Code Agent Farm throws ~50 instances at a lint queue. Superb at grinding.

Receipt. Rule of thumb for an unbounded loop: cap it (~20 iterations for
small tasks, ~50 for large), budget ~$50–100 for a 50-iteration run, and treat
hitting the cap as "the task spec is wrong," not "retry harder."

The batch runner's ceiling is its completion check. Supervision here is a
watchdog — it keeps the process alive, it says nothing about whether the work is
right. Ship unreviewed loop output to production and "the agent wrote it" is not
a defense you get to use.

Shape 3 — the local daemon. A long-lived process that owns sessions behind
an API: Paseo and agentproto. Paseo runs agents on your machine and exposes
mobile/desktop/web/CLI clients to drive them from anywhere. It's the first shape
that runs unattended with a programmatic surface.

Receipt. A daemon can attach a completion gate to a turn-end and stage a
risky commit behind it — and because the gate lives in the daemon, it survives
your laptop closing. A cockpit's supervision dies with the screen lock.

The daemon's ceiling is how much you trust what it does while you're not
looking — which, unlike the other three, is a ceiling you can actually raise.

Shape 4 — vendor-native. Orchestration baked into the vendor's own stack:
Claude Code Agent Teams, Dynamic Workflows, Codex's TOML custom agents. Deepest
integration by far — and single-vendor by construction. (More on where that
helps and where it bites, below.)

Where are you? If your honest answer is "a human watches each pane,"
you're a cockpit at the bottom rung — and no number of extra panes moves you
up. Everything past here is about shrinking the serial fraction, one rung at a
time.

Rung one: put the check where the agent can't reach it

The first way to shrink the serial fraction is to stop being the thing that
verifies. When an agent says "done," something other than you has to decide
whether that's true before it becomes a commit.

The obvious shortcut — let the agent grade itself — fails in a now-documented
way. Anthropic's own harness team found self-grading doesn't underperform — it
plateaus; the full quote and the five-rung fix are in the supervision
ladder.

The texture is worse than the headline. A model acting as both author and
reviewer sees a button render and calls the feature done, or finds a real bug
and talks itself out of it. The judge has to sit outside the loop — ideally a
different model, told to refute rather than admire.

Two traps sit under "just run the tests," and both are load-bearing:

• Tests validate code, not decisions. An agent can call send_email() or execute_trade() with perfectly valid parameters, pass every test, and still do real damage.
• The trace can lie. Tool-call logs sometimes report actions that never ran. The agent says it ran the tests; it didn't.

So the check that actually shrinks your serial fraction isn't "the agent ran the
tests." It's that something external ran them, and the merge physically waited
on the result. That spectrum — from L0 (you watch) up to L4 (an external gate
with the commit staged behind it) — is the
supervision ladder, and it's the single axis that
sorts this whole market. Rung one is only where the climb starts.

Rung two: make one tool reach every agent

The second way to shrink the serial fraction is quieter, and almost nobody talks
about it. You are also the serial hop every time a new agent needs a capability —
because capabilities don't travel.

Open any serious agent repo in 2026 and you find the same sediment: a
CLAUDE.md, an AGENTS.md, a .claude/skills/ folder, Codex agents in TOML,
somebody's OPERATOR.md. Everyone discovered the same right primitive — agent
behavior as files in the repo — and everyone speaks a different dialect of it.

The tell. The dialects don't even agree on field names: skill.title in
one, skill.name in another, three flavors of AGENTS.md. It's Ethereum
before ERC-20 — the primitive is proven, the interop is zero.

The consequence is manual labor with your name on it. A tool you wired into one
product's config is invisible to the other four agents in your fleet, so you
re-wire it, by hand, every time you add a brand. That is the difference between
managing agents and building with them.

Infrastructure closes it: you write a capability once, and Claude Code, Codex,
and a cheap open model all get it from one place. Almost no tool does this today
— the daemons inject their own control tools; the vendors scope tools to their
product. What it would take to fix it with numbered specs instead of yet another
framework is its own companion.

The vendors are climbing the same ladder — inside their own house

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

What shipped, dated. Claude Code Agent Teams; Dynamic Workflows (Claude
writing its own orchestration script, June 2026 preview); Outcomes (a grader
forcing retries against your rubric, May 2026); Managed Agents (Anthropic's
hosted meta-harness, April 2026). If you're an all-Claude shop on a Team plan,
that's a real answer to rung one — closer to the model than I'll ever sit.

Two structural limits are why third-party orchestration outlives it. Every
vendor's stack is single-vendor: Agent Teams won't run Codex, and the
Advisor tool won't pair a cheap executor with a rival judge — read its
compatibility table and executor and advisor must both be Claude, with
Fable/Mythos advice returned encrypted, unreadable by your client. And it
all lives on their plans and their infrastructure.

The demand is already there. The one thing users keep begging vendors for —
agents that message each other directly instead of a human copy-pasting
between sessions — is still a manual workaround. OpenAI closed the Codex
feature request as a duplicate without shipping it.

Which leaves a real question standing: if the checking layer has to work across
vendors, and run where your code lives, whose job is that?

Why the checking layer has to be cross-vendor — and local

Two forces make "just use one vendor" a losing bet. The first is that open
weights caught up, and the second is that catching up opened a trap.

The receipt. Per the Stanford AI Index, the spread between the #1 and #10
model collapsed from 11.9% to 5.4% in one year. On SWE-bench Verified (July
2026): frontier is GPT-5.6 Sol (96.2) and Claude Fable 5 (95); the best
permissively-licensed models — GLM-5.2 (MIT, 82.8), Kimi K2.7 (78.2),
DeepSeek V4 (MIT, 76.2) — match proprietary frontier from a few months back,
at a fraction of the price.

The rational fleet in 2026 is therefore mixed: a frontier model plans, cheap
open models execute, a judge verifies — the routing math
is its own post. But the savings pitch skips the trap.

Cheaper per token is not cheaper per outcome. A model that costs 10–30×
less but fails one task in ten isn't cheaper once you count the wrong answers
and the cleanup. Compute cost per successful task, not per token.

There's a reliability argument too, not just a price one: when every agent runs
on the same foundation model, they share the same blind spots, and one flaw
cascades across the whole fleet at once. Mixing vendors is a hedge. But the
mixed fleet only pays off if something external catches what the $0.10 model got
wrong before it merges — rung one again, now with money riding on it.

And this is the part most write-ups skip: the checking layer can be yours,
cross-vendor, and fully local. agentproto is a daemon that runs on your
machine, with adapters for Claude Code, Codex, and open models via OpenRouter or
Hermes — so the turn-end gate and the shared toolbox work on any agent,
including local ones, with no single vendor holding the keys.

The point of open weights was never consumer-hardware bragging rights. It was
controlling where your code and your checks run — and a check you don't own
isn't really a check.

The part of the job you can't parallelize

So the folk formula had it backwards. More agents don't multiply your problems.
They multiply the load on the one part of you that never forked — the judgment
that decides "done" is true and hands out the next capability. Amdahl told us
where that ceiling was thirty years ago. The only way past it is to make the
serial part smaller: move the check outside yourself, and make one tool reach
every agent.

That turns the whole market into two questions you can ask in a sentence. When
your agent says "done," what — other than you — decides whether that's true? And
when you give one agent a new capability, how many of the others get it?
Steering tools answer neither; they add cores in front of the same bottleneck.
Run the nine major tools through those two filters and the field sorts itself
fast — which is exactly what
the nine coding-agent orchestrators, compared side by side
does, tool by tool.

Buy more agents if you want. Just know you're buying cores for a job whose
serial fraction is you — and the real work of the rest of 2026 is shrinking it.

If you think I've mis-rated your tool, or your setup breaks the law above, 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 (you're here)	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	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.