Anthropic’s 2026 agentic-coding trends report documents the industry’s open wound with numbers. Developers use AI in roughly 60% of their work, yet report being able to fully delegate only 0 to 20% of tasks. The report’s own name for the finding is the collaboration paradox; commentators have dubbed it the delegation gap. And the report’s Trend 4 draws the consequence: human oversight has to scale intelligently, or it becomes the bottleneck. Everyone can generate. Nobody trusts the result enough to stop watching.
Three approaches to that gap are on the table right now. From a distance they look similar: all of them orchestrate multiple agent sessions toward a goal. But they make opposite bets on the questions that matter. Who holds the plan? Who checks the work? When do you get asked?
This comparison is scored for one job, the coding problem in its hardest everyday form: shipping a feature into a codebase you have to live with. On other work the table tilts differently, and we will say where.
Answer one: the model writes the process
Claude Code’s dynamic workflows have the model author a fresh orchestration script per run: fan-out, verifier agents that adversarially cross-check findings, grader loops. The script executes in the background. It is genuinely impressive machinery, and its own docs state its human-interaction contract plainly: no mid-run user input (only permission prompts can pause a run, and subagents are barred from the question tool). If you want sign-off between stages, you split the work into separate runs. The plan is held by a script the model wrote minutes ago. Verification is models checking models. You are asked at launch, and then not at all.
Anthropic’s own write-up is admirably candid about why the machinery exists. Single-context agents suffer agentic laziness, self-preferential bias, and goal drift: “details like edge-case requirements or ‘don’t do X’ constraints can get lost.” Note the treatment, though. Goal drift is fought with decomposition, fresh context windows per subagent. But the orchestration script itself is written once, from a lossy read of your prompt. Every subagent inherits whatever the script-writer misread. Fresh contexts downstream of an unguarded translation.
This is the right shape for breadth work: exhaustive audits, research sweeps, migrations where volume wins and any individual miss is cheap.
Answer two: nobody holds a process
/goal sets a completion condition and lets the agent free-run until a fresh evaluator judges the condition met. There is no process at all. That’s the appeal. Persistence replaces structure. “Keep going until CI is green” is a perfectly good contract when the end state is measurable and the path doesn’t matter.
Note what the goal is here: a stop condition you paraphrased from your intent, capped at a few thousand characters, judged against the transcript. It answers “when to stop.” It does not answer “did you build what I asked, the way my codebase wants it.”
Answer three: a fixed pipeline with judgment seams
rpiv’s build makes the opposite bet on all three questions.
Who holds the plan? You do. The pipeline is code: versioned, the same nineteen-stage graph every run, not improvised per run. The dynamic-workflow pitch inverts this frame. A fixed workflow is generic, they argue, while a freshly written harness is tailor-made for your task. But fixed isn’t generic. It is specialized for one job, and it learns.
One repair arm shows the grain of that learning. In this pipeline, what a stage sees is a declared contract, not ambient context. There is no orchestrator holding findings in its head; the runner is deterministic code, and artifacts flow only along each stage’s reads. The elaborate stage declares reads: ["plans"], and its fanout hands each unit exactly one line: the plan path plus its phase number. Route a code-gate failure back through it, and the five verdict files would sit unread on their own channel while every unit rewrote its phase blind. The gate’s typical failures live in the plan text anyway (a fabricated edit anchor, a drifted line citation, a naming collision across phases), out of reach of a per-phase code rewrite. And a fresh rewrite sometimes regressed a dimension that had already passed. So the fix arm is amend instead. It declares reads: ["plans", fanin("code-verdicts")], so the runner hands it the plan plus every verdict as labelled flags, and it edits only what the findings cite before the gate re-judges. The coverage check is the same kind of lesson: it anchors to the first cut you confirmed, so a re-slice can’t pass by deleting the evidence.
A harness improvised per run relearns none of this. And tailor-made cuts the other way too. A process that changes every run is one you can never certify, never tune stage by stage, and never trust on run N because run N−1 went well. Repeatability isn’t the compromise. For work you have to live with, it’s the feature.
Who checks the work? Programs first. The slice gate is a script that passes or fails with zero LLM calls. The code splice is deterministic too, and its result goes straight back under the code panel’s judgment. Coverage conservation means a re-slice can redistribute your brief but never quietly drop a piece of it. Fresh-context panels second: one session per quality dimension, blind to the transcript that produced the artifact. You third. And the goal artifact makes “you” enforceable. Your brief is captured byte-for-byte before anything runs. Completeness, correctness, and final validation are all graded against that file, not against the plan’s own claims. The fix for the verification bottleneck isn’t more agents checking agents.
When are you asked? Mostly when the code can’t decide: a research ambiguity, the slice-cut confirm, a genuine design fork, a mismatch implement can’t reconcile. Two quick confirms bracket the run, one before research writes its document and one before commit lands. And one pause carries real judgment: the design review. Every slice’s design arrives in one consolidated summary. Adjusting an interface cascades to its dependents before synthesis. One high-leverage design decision instead of either extreme: not the approval fatigue of confirming every step, not the blind autonomy of confirming none.
The economics fall out of the same structure. Everything between gates fans out: designs per slice, panel dimensions, code per phase, each in a session that carries only its slice of the problem. The rigor is parallel rather than sequential. And the bounded context per session is precisely why affordable open-weight models hold up in the drafting seats.
Side by side
Scored for the job named above: a feature landing in a codebase you own.
| Dynamic workflows | /goal | rpiv build | |
|---|---|---|---|
| Who writes the process | The model, fresh each run | Nobody; the agent free-runs | You; versioned code, the same graph every run |
| Who checks the work | Models check models | One evaluator judges a stop condition | Programs, then fresh-context panels, then you |
| Intent custody | Your prompt, read once by the script-writer | A condition you paraphrased | Your brief, byte-for-byte, conserved and graded against |
| When you’re asked | At launch; after that, only permission prompts | Never | On real ambiguity, plus a design gate and two quick confirms |
| Repeatability | Improvised per run; can be saved and rerun | No process to repeat | The same nineteen stages every run |
| Cost profile | High; token use is their own stated caveat | Low overhead, unbounded runtime | Heavy for small changes; parallel and cheap-model-friendly at scale |
| Best at | Breadth: audits, sweeps, mass migrations | Measurable end states | A feature you must live with |
What ours costs
Fairness cuts both ways, so here is our side of the ledger. build is heavy machinery: nineteen stages and two five-dimension panels are the wrong tool for a two-file fix. That is why the ladder below it exists (chat, /skill:blueprint, /wf vet), and the honest advice is to stay low on it until decomposition itself is the work. The design gate means the run needs you once; it is not overnight fire-and-forget. There are exactly three shapes. Work that is neither a brief, a diff, nor an architecture review means authoring your own graph, or reaching for their tools. And mass parallel mutation in isolated worktrees, the headline migration story on their side, is theirs today: worktree isolation sits on our roadmap, not in the box.
Pick by the work, not the brand
These aren’t three competitors for one job. Condition-driven persistence is right when the end state is measurable and the path is disposable. Model-written orchestration is right when breadth beats precision and no single finding is load-bearing. A fixed, gated pipeline is right for the work you’d never blind-delegate: a feature landing in a codebase you have to live with, where the ask must not shrink, the interfaces deserve one real decision, and the diff carries your name.
The delegation gap closes from both ends. Their end widens what agents can do unattended. Ours narrows what actually needs attending: one seal.