Prompt engineering had a ceiling nobody needed to name, because everybody felt it: an agent moved only as fast as a human could type the next instruction. Loop engineering removes that ceiling and quietly replaces it with a different one. A loop does not wait on the next keystroke. It decides its own next step, dozens or hundreds of times, without asking. The limit that remains is not tokens, not concurrency, not even compute. It is how much of what the loop already did a human can actually read, verify, and stand behind before the next batch of work lands. Call it the orchestration tax.
Boris Cherny, the creator of Claude Code at Anthropic [1], put language to the shift: “I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.” [2] Peter Steinberger, whose framing Matt Van Horn sets directly against Cherny’s [3], puts the identical reversal from the other side of the desk: “You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.” [2]
That reframe sounds like a productivity win, and in one sense it is. It is also a relocation. We trace five sources here, none with an interest in the others’ conclusions, from a Google engineer’s essay to Anthropic’s own engineering leadership to a competing framework vendor’s own maturity ladder to a pharma analytics firm’s public postmortem to an open-source scoring tool that accidentally proves the point, all converging on the same constraint: the number of loops a team can actually run is set by how much it can review, not by how many it can launch.
Figure 1 - The bottleneck relocated: Prompt engineering was rate-limited by how fast a human could type. Loop engineering replaces that limit with a new one further downstream, how fast a human can read and trust what the loop already did. The orchestration tax is the cost of that relocation.
What a loop actually is
Not every automated process is a loop. An automation runs a fixed script start to finish. It does not check whether the outcome was right, and it does not decide to run itself again. A loop adds one piece an automation lacks: a decision node inside the body that asks whether the goal was met, then branches. An automation is a cron job. A loop is a cron job with a decision maker wired into the middle of it, one with authority to send the whole process back around instead of letting it finish.
Addy Osmani, the Google engineer whose essay gave the practice its name and most of its vocabulary [2], breaks a working loop into six pieces:
- Automations: the scheduled discovery-and-triage layer that gets the loop moving in the first place.
- Worktrees: isolated parallel workspaces so agents running side by side cannot contaminate each other’s changes.
- Skills: codified project knowledge the loop reuses on every pass instead of relearning it from a blank context each time.
- Plugins and connectors: the tool integrations that let a loop reach past its own context window into external systems.
- Sub-agents: separate agents holding distinct roles, most importantly separating whoever does the work from whoever checks it.
- External memory: a state file, a board, anything durable that outlives a single conversation and survives a compaction event.
Skills carry disproportionate weight in that list. Matt Van Horn names why: “The loop is plumbing. The asset is the skill it calls. If you do something more than once, turn it into an automated skill, and if you do something hard, turn it into a skill afterward so next time is free.” [3] The harness does not compound in value on its own. The skill layer does, and a skill is exactly the artifact a human authors and refines under review, which is the first sign of where this article’s ceiling actually sits.
This anatomy will look familiar to anyone who has read our own breakdown of what an agent harness is built from, What Is an Agent Harness, Really? Nine Components Most Builders Miss [4]. A loop is a harness with one addition: the decision node that keeps it running past a single turn.
Figure 2 - Anatomy of a loop: Six pieces make a loop run: automations trigger it, worktrees isolate parallel work, skills codify durable knowledge, plugins and connectors reach outside the context window, sub-agents separate doing from checking, and external memory survives a compaction event. The skill layer is where durable value accrues.
Four rungs of autonomy, one constant
Where a team lands on the loop-maturity ladder is not a single jump from prompting to fully autonomous. Sydney Runkle of LangChain lays out four composable levels, each escalating how much the loop decides on its own [5]:
- Agent loop: the base model-plus-tools primitive, reason, call a tool, observe, repeat.
- Verification loop: a separate grader checks the output against explicit criteria before anything is accepted.
- Event-driven loop: a Slack message, a GitHub issue, or a webhook puts the agent to work instead of leaving it idle between requests.
- Hill-climbing loop: a background agent mines run traces and proposes changes to prompts, tools, and memory, gated by an eval suite before anything merges.
LangChain builds a competing agent framework to Anthropic’s, which makes their conclusion worth weighing on its own: “At every level, there are natural points where human oversight adds value.” [5] Two companies building different products in the same space, neither reporting to the other, land on the identical design choice. Keep a human checkpoint at every escalation of autonomy rather than build toward one that has none.
Figure 3 - Four rungs, one constant: LangChain’s four loop levels escalate autonomy from a base agent loop to a background hill-climbing loop that rewrites its own prompts and tools. A human checkpoint sits at every rung, by the vendor’s own design, not bolted on as an afterthought.
KEY INSIGHT: When two vendors building competing products for different markets both keep a human checkpoint at every rung of their own maturity ladder, that convergence is a stronger signal than either company’s marketing copy on its own.
Three ways a loop breaks the human watching it
Osmani describes three failure modes that make the review ceiling non-negotiable rather than a nice-to-have [2]. The short labels below are ours, his own section headings run longer:
- Verification burden: “A loop running unattended is also a loop making mistakes unattended.” Every error the loop produces becomes review debt, silently, whether or not anyone is watching for it.
- Comprehension decay: the gap between what the loop ships and what the engineer actually understands widens with every pass reviewed a little less carefully than the last.
- Cognitive surrender: the most insidious of the three, designing loops to avoid thinking about a problem rather than to move faster on a problem already understood.
“Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go.” [2] Osmani’s closing line on the subject draws the boundary as sharply as it can be drawn: “The loop doesn’t know the difference. You do.” [2]
These three modes explain why a vague seed spec is more dangerous inside a loop than inside a chat window. In a conversation, a vague prompt produces a vague answer, a human corrects it, and the exchange converges within a turn or two. Inside an unattended loop there is no next-turn correction. If the seed spec leaves the goal underspecified, the loop does not guess once. It guesses confidently in the same direction, hundreds of times, and the failure is never loud. It is quiet, competent-looking work that has drifted somewhere nobody was watching closely enough to catch.
Figure 4 - Three ways a loop breaks its supervisor: Verification burden turns every silent error into review debt. Comprehension decay widens the gap between what ships and what the engineer understands. Cognitive surrender uses the loop to avoid thinking rather than to move faster on understood work. All three compound with every unattended pass.
Not a token ceiling
It is tempting to read “orchestration tax” as a euphemism for compute being expensive, and the vendor documentation makes clear that is not the constraint. Claude Code’s dynamic workflows feature, which lets a session spin up its own fleet of sub-agents at runtime, documents hard architectural caps: “up to 16 concurrent agents, fewer on machines with limited CPU cores” and “1,000 agents total per run” [6]. Those numbers describe a generous machine ceiling. A team that never gets near either cap can still hit the orchestration tax on its very first loop, because the ceilings do not describe the constraint that actually bites: how many of those agents’ outputs a human can read.
The distinction matters for how a team budgets. Our earlier look at where a billion daily output tokens actually go, Token Billionaire Economics [7], traced the cost side of running loops at scale. The orchestration tax is the companion constraint on the other side of the ledger, the one no invoice itemizes. A team can solve the token-cost problem completely, stay well under 16 concurrent agents and 1,000 per run, and still run out of the resource that actually gates how many loops it can operate: the hours a qualified human has to spend reading what came back.
Figure 5 - Two ceilings, only one bites first: Claude Code’s documented limits, 16 concurrent agents and 1,000 per run, describe a generous machine ceiling. A team can stay well inside both and still exhaust the resource that governs how many loops it can run: the hours a qualified human has to spend reading the output.
The bottleneck relocated. It did not disappear.
Nobody has said this more plainly than Anthropic’s own engineering leadership. Fiona Fung, Director of Engineering for Claude Code and Claude Cowork, described what happened inside her own team once agentic coding became the default way of working [8]:
“On the Claude Code team, writing code, writing tests, and refactoring rarely slows us down anymore. But the bottlenecks didn’t go away when agentic coding took away the actual need to type code. Verification, code review, and security took their place.” [8]
The scale at which that verification bottleneck now operates is concrete, not abstract, by Fung’s own account: “I don’t think I’ve seen a non-Claude-assisted commit in the last four months.” [8] At that volume, review capacity is the workflow’s binding constraint, and Fung’s team restructured around that fact rather than the fantasy that typing speed was ever the real bottleneck. Two changes stand out.
The first is a code-review split by kind of judgment, not seniority: Claude handles style, linting, bug-catching, and tests, while humans keep the reviews where expertise is load-bearing: legal review, security-sensitive trust boundaries, and product sense and taste [8]. The second is just-in-time planning, prototype-first instead of roadmap-first: “Our planning ritual shifted away from design docs toward discussions in PRs or prototypes… let’s prototype, get a lot of internal users on it, and start acting on their feedback.” [8] Both changes are the same move applied at different points in the pipeline. Stop spending the scarce resource, human judgment, on work a loop already handles, and concentrate it where a wrong call is expensive.
Figure 6 - The bottleneck moved, it did not vanish: Before agentic coding, typing speed gated how fast a team shipped. After, verification, code review, and security became the new constraint, at a volume where the Claude Code team’s own engineering director reports not having seen a non-Claude-assisted commit in four months.
KEY INSIGHT: When typing stops being the bottleneck, the bottleneck does not vanish. It moves to whatever step still requires a human to be right, and a team that does not deliberately redesign around that new bottleneck just discovers it the hard way.
When nobody owns the whole picture
Fung’s team relocated the bottleneck on purpose. ZS Associates found out what happens when nobody relocates it at all. Subbiah Sethuraman and Abhilash Asokan, from ZS Associates’ AI engineering leadership, described a pharma commercial-analytics pipeline they built, then killed, at the AI Engineer conference [9]. Four agents mirrored a human analyst’s four-step workflow: detect a signal, localize its source, attribute a driver, synthesize a recommendation. Each agent, individually, did its job correctly.
The system correctly detected an 18% prescription drop in a territory and correctly identified the cause, a payer had moved the drug to a lower coverage tier, making it unaffordable for patients. It then recommended sending more sales reps to talk to doctors, a fix aimed at a problem that had nothing to do with sales coverage, because the weight of the insurance-coverage finding never survived the handoff to the synthesis agent. Every individual agent was right. Nothing was coherent end to end. Sethuraman and Asokan’s own summary: “It’s not the LLM which failed. It’s the way how we split the work.” [9]
Their fix named three causes and applied three matching corrections [9]. Deterministic statistical work (deciding whether a drop is a real anomaly or just noise) had been assigned to an LLM. They pulled it out of the agentic system entirely and ran it as a plain statistical pipeline ahead of any agent. Reasoning distributed across agents lost context at each handoff, so they consolidated judgment into one agent that owns the reasoning chain end to end, delegating investigation legwork to sub-agents but never the final call. No agent shared a common model of the business domain either, so agents inferred relationships from raw tables that sometimes did not exist. ZS built a domain knowledge graph with subject-matter experts and treated it as a control plane the agent navigates, not a lookup table it queries.
The reported result, by the team’s own account and not independently audited, took a task that previously ran 3-4 weeks down to 20-30 minutes [9]. The more durable lesson sits underneath that number: fan-out multiplies how much output exists to review, and a system with no single point of accountable judgment produces locally correct, globally incoherent output, silently. Our earlier piece on multi-agent pipelines, Multi-Agent Pipelines in Claude Code [10], argued for the same clean separation of roles at the harness level. ZS’s postmortem is the production-scale version, arrived at by watching a pipeline fail in front of paying clients.
Figure 7 - Correct at every step, wrong end to end: ZS Associates’ four-agent pipeline correctly detected a signal and its cause, but the weight of that cause never survived the handoff to the synthesis agent, which recommended an unrelated fix. No agent owned the reasoning chain, so none caught the incoherence.
What a maturity score actually measures
If the orchestration tax is real, it should be possible to measure how ready a team’s own harness is to carry it. An open-source CLI toolkit, cobusgreyling/loop-engineering, tries to do exactly that: MIT licensed and, as of 2026-07-25, 9,387 GitHub stars spanning 13 tool directories plus five companion repos, grounded explicitly in Osmani’s essay [11]. Its loop-audit command produces a Loop Readiness Score out of 100.
When we ran it against this project’s own harness on 2026-07-18, against tool version v1.6.0, the score came back 35 out of 100, Level L0, “not loop-ready” [11]. Read at face value, that says this site’s article pipeline, which at the time ran 20 skills, 25 slash commands, 10 hooks, and a documented maker-checker split between a writer agent and a read-only reviewer agent, is not ready to run a loop. Read the tool’s own scoring logic and a different story appears: 46 of the 100 points were, at that version, gated behind hardcoded filename and skill-name matching, not behind anything the harness actually does. A state file has to be named literally STATE.md. A skill has to contain the literal string “verifier” in its name. This project’s reviewer agent performs exactly the adversarial verification role the score wants. It just is not spelled that way, so it scores zero on a signal it structurally satisfies.
The tool has since shipped v1.7, and the exact number would likely not reproduce today, so treat 35/100 as a dated, one-time observation. What endures is the structural critique: the heaviest-weighted signals, persistent state, kill switches, stall detection, escalation paths, all presuppose an unattended loop. A harness deliberately built with human-gated checkpoints, the design this article argues for, scores down for having them and up for having automated kill switches instead. That is a maturity tool measuring convention conformance and calling it capability, a category of mistake worth naming: a scoring system that penalizes the exact discipline it should reward.
Figure 8 - What the score actually measures: Nearly half the points in one open-source loop-readiness scorer were, in the version we audited, gated behind hardcoded filename and skill-name conventions, not capability. A harness with a genuine maker-checker split still scores zero if its reviewer agent is not literally named “verifier,” penalizing the human-gated discipline this article recommends.
KEY INSIGHT: Before trusting a maturity score for anything, agent harnesses included, check whether the signals it weights actually measure the outcome that matters, or just measure agreement with the scorer’s naming conventions.
The discipline that pays the tax down
None of this argues against loops. It argues for spending the review budget on purpose instead of discovering where it ran out. Three habits carry the weight.
Write the seed spec like it is going to run unsupervised for hundreds of steps, because it is. A vague prompt in a conversation gets corrected next turn. A vague spec at the top of a loop gets amplified, confidently, in the same wrong direction every pass, and the resulting failure is never loud. It looks like ordinary, competent-looking output nobody was watching closely enough to catch.
Save the human’s attention for judgment, not plumbing. ZS’s own fix drew this line explicitly: deterministic work, statistics, filtering, deduplication, does not belong inside an agent loop at all, and reasoning that requires a single accountable owner should not be scattered across sub-agents that each see only a slice of the picture [9]. The same discipline scales down to the individual engineer. If a correction to a running loop is going to recur, it belongs in a skill the loop can call, not a one-off fix applied by hand each time. Van Horn’s framing is the compact version of the whole argument: “The loop is plumbing. The asset is the skill it calls.” [3]
Build a review cadence that is sustainable, not aspirational. In a regulated-data practice like the pharma analytics work ZS describes, compliance review does not parallelize the way loops do. The review-team headcount, not the API rate limit, is the actual production ceiling. A sharp seed spec buys fewer surprises per loop, a deliberate human-agent split buys accountable judgment where it is expensive to get wrong, and a review cadence sized to what a team can sustain, rather than what the tooling makes theoretically possible, is what keeps the tax paid down instead of deferred.
Figure 9 - The discipline that pays the tax down: A sharp seed spec, a deliberate split between what agents judge and what humans judge, and a review cadence sized to what a team can sustain together keep the orchestration tax paid down as it accrues, instead of deferred as errors nobody caught.
Conclusion
Five sources, three of them with commercial reasons to argue the opposite, converge on one constraint: a loop is not limited by how many agents it can spin up. It is limited by how much of what those agents produce a human can actually read, verify, and stand behind. Osmani names the mechanism in three failure modes. Fung’s own team at Anthropic describes living inside the constraint at commit-ratio scale. LangChain, building a competing product, keeps a human checkpoint at every rung of its own maturity ladder for the same reason. ZS Associates shows what happens in production when nobody owns the whole picture. An open-source scoring tool, without meaning to, demonstrates that even measuring loop readiness is easy to get backwards when the score rewards convention over capability.
The number that matters is not how many agents a harness can run concurrently. It is how many of those runs a team can read closely enough to trust, and building loops that respect that number, rather than pretend it does not exist, is the discipline this article has argued for throughout. Claude Code’s published ceilings, 16 concurrent agents and 1,000 per run [6], describe what the machine will tolerate. The orchestration tax describes what the team will.
References
[1] WorkOS, “Boris Cherny on What Happens When AI Acquires Claude Code,” WorkOS Blog, 2026. https://workos.com/blog/boris-cherny-claude-code-acquired-interview-takeaways
[2] A. Osmani, “Loop Engineering,” Personal Blog, 2026. https://addyosmani.com/blog/loop-engineering/
[3] M. Van Horn, “WTF Is a Loop? Peter Steinberger vs. Boris Cherny,” LinkedIn Pulse, 2026. https://www.linkedin.com/pulse/wtf-loop-peter-steinberger-vs-boris-cherny-matt-van-horn-cpslc
[4] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “What Is an Agent Harness, Really? Nine Components Most Builders Miss,” 2026. /insights/claude-code-01-agent-harness/
[5] S. Runkle, “The Art of Loop Engineering,” LangChain Blog, Jun 2026. https://www.langchain.com/blog/the-art-of-loop-engineering
[6] Anthropic, “Orchestrate subagents at scale with dynamic workflows,” Claude Code Documentation, 2026. https://code.claude.com/docs/en/workflows
[7] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “Token Billionaire Economics: Where 1B Output Tokens Per Day Actually Go,” 2026. /insights/claude-code-09-token-billionaire-economics/
[8] F. Fung, “Running an AI-native engineering org,” Anthropic, Jun 2026. https://claude.com/blog/running-an-ai-native-engineering-org
[9] S. Sethuraman and A. Asokan, “Why We Killed Our Multi-Agent Pipeline,” AI Engineer Conference, 2026. https://www.youtube.com/watch?v=u6jJcIFDLE4
[10] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “Multi-Agent Pipelines in Claude Code: Researcher, Architect, Developer, Reviewer,” 2026. /insights/claude-code-03-multi-agent-pipelines/
[11] C. Greyling, “cobusgreyling/loop-engineering,” GitHub, 2026. https://github.com/cobusgreyling/loop-engineering
Building production AI, or modernizing a legacy system?
That is the kind of work we do at Dotzlaw Consulting. Book a free 20-minute intro call and tell us what you are trying to build, or what is slowing you down.