The Loop and the Harness

“You’re not supposed to prompt Claude. You’re supposed to build a system that prompts itself.”

— Boris Cherny, Head of Claude Code, Anthropic, 2026

This sentence, offered quietly in conversation and widely circulated in the months since, captures something that has become apparent to almost everyone who has tried to scale AI-assisted development beyond a single engineer’s workflow. The bottleneck is no longer the model. The bottleneck is the system around the model.

Through the first half of 2026, a new vocabulary has consolidated around this insight. The term loops now appears everywhere in the AI software delivery discourse — conference talks, Hacker News front pages, internal memos at firms moving fast and quietly. But the term is being asked to do too much work. It refers simultaneously to execution, to validation, to improvement, and to governance — and the slippage between these meanings obscures something important. Each is a distinct loop, with a distinct purpose, operating at a distinct cadence, and the way they interact under AI acceleration is the real story.

This essay separates the loops, defines what each one is for, surveys the field evidence from software delivery — where the pattern was discovered first — and then generalises. The aim is not to explain how to build a harness. The aim is to understand what the harness pattern reveals about knowledge work itself, and why every domain of complex human effort is about to experience the same structural shift.

The Two Meanings of Loops

The term entered the discourse with two referents. Understanding both is necessary, but it turns out that neither is sufficient.

Inner and Outer: The Pipeline That Is Out of Sync

Software delivery has long been understood through a pair of nested cycles. The inner loop is where developers write, debug, build, and unit-test code. It is fast, creative, high-cadence work — the think-make-check rhythm that defines the experience of writing software. The outer loop is everything that surrounds it: requirements gathering, integration testing, compliance review, deployment, monitoring, and the slow return of user feedback. The inner loop runs in seconds or minutes. The outer loop runs in hours, days, or weeks.

This model traces back to continuous integration thinking in the DevOps movement, was refined by the DORA research programme and Google Cloud’s developer productivity teams, and has been adopted widely in platform engineering. For years, the inner and outer loops operated in rough equilibrium. A developer might spend four hours coding and two days waiting for integration test results, security review, and deployment. The ratio was frustrating but stable.

AI has broken the equilibrium. The inner loop has been dramatically accelerated — tools like Claude Code, OpenAI Codex, and GitHub Copilot can generate functions, entire modules, or test suites in seconds that would have taken a developer hours. The inner loop has never been faster.

The outer loop has barely moved. Integration tests still take twenty minutes. Compliance reviews still wait for a human in a different timezone. Deployment pipelines still gate on manual approval. Security scanning still runs overnight.

As Rob Zuber, CTO of CircleCI, observed in June 2026: “The loops of software delivery are out of sync. The inner loop, where developers write, debug, and build, has never been faster. But the outer loop — where code is integrated, tested, secured, deployed, and measured — has barely moved.”

The result is a traffic jam — but not where the conventional diagnosis places it. The DevOps pipeline, once mature, is repeatable and fast: a well-instrumented CI/CD system with parallelised runners, canary deployments, and automated rollbacks can move code from commit to production in minutes. The bottleneck is not shipping. It is everything that sits between code-complete and deploy-ready — the human-mediated validation layer. And that layer has three distinct problems, each deeper than the last.

The first is validation latency: the human gates — code review, architecture review, security sign-off, stakeholder approval — run at the speed of trust, not the speed of compute. A pull request generated in seconds can sit for days waiting for a human to read it. The machine can generate code faster than humans can agree that the code is correct, safe, and fit for purpose.

The second is design drift: an agent working across dozens of files over 77 iterations makes micro-decisions — about abstractions, interfaces, data flow — that accumulate into an architecture no human explicitly designed. The final system is not the one anyone envisioned at the outset. It is the one that emerged from the agent’s choices. Some of those choices are good. Some are not. All of them must be understood by someone before the code can be trusted. A test suite can verify that the code behaves correctly. It cannot verify that the abstractions are coherent or that the design decisions made in iteration 34 will not cause maintenance problems in month six.

The third and deepest is problem-solution co-evolution: the oldest truth in software is that you do not fully understand the problem until you try to solve it. Building surfaces edge cases, clarifies requirements, exposes contradictions. When a human builds slowly, these insights arrive at a manageable pace — the developer pauses, rethinks, and adjusts. When an agent builds at speed, the insights accumulate faster than the human can absorb them. The agent finishes the build before the human has finished understanding what the build revealed about the problem. And those insights — if they could be absorbed — should change what gets built next. The feedback from execution to governance must close at the speed of the build, not the speed of the org chart.

Organisations that poured AI into the inner loop without addressing these three layers discovered, sometimes painfully, that they had accelerated their way into a bottleneck. The bottleneck shifted downstream — but not to the pipeline. To the human.

Observe, Plan, Act, Reflect: The Agent Loop

The second meaning is newer, more radical, and is the one generating the most heat in mid-2026. It describes a paradigm shift in how developers interact with AI systems — from single-shot prompting to autonomous iterative loops.

In this framing, the developer does not write a prompt and accept whatever comes back. The developer designs a system that observes the codebase, plans an action, executes it, reflects on the result, and repeats — autonomously, over hours or days, until a verifiable goal is met. The human is not in the middle of each iteration. The human is on the loop, watching the system from above, intervening only at pre-defined boundaries.

The intellectual lineage is clear enough, though it draws from a deeper well than is usually acknowledged. The ReAct pattern, published by Princeton and Google DeepMind researchers in 2022, demonstrated that interleaving reasoning steps with action steps — think, act, observe, think again — substantially improved model performance on complex tasks. But the feedback loop itself is far older. It has been independently discovered in manufacturing (Plan-Do-Check-Act, Shewhart and Deming, 1930s–1950s), military strategy (Observe-Orient-Decide-Act, John Boyd, 1970s), organisational learning (double-loop learning, Chris Argyris, 1970s), and entrepreneurship (Build-Measure-Learn, Eric Ries, 2011). The feedback loop is not a new idea. What is new is the operator: an AI agent running the loop autonomously, while the human designs the system that shapes its behaviour.

AutoGPT and BabyAGI in early 2023 proved, crudely and expensively, that chaining LLM calls in autonomous loops could produce results beyond what single prompts could achieve. The community then moved through a sequence of refinements: prompt engineering (2022–2024: “What should I say?”), context engineering (2025: “What information do I provide?”), and finally harness engineering (2026: “What system do I build?”).

The progression is not merely terminological. It marks a genuine shift in where intelligence resides. In prompt engineering, intelligence is in the text. In harness engineering, intelligence is in the architecture — the tools, gates, guardrails, and feedback mechanisms that surround the model and shape its behaviour over time. The model becomes a component, not the centre.

A Vocabulary for Loops

Before surveying the evidence, it is worth being precise about what we mean by a loop. The term is currently being asked to carry at least four distinct ideas, and the slippage between them creates confusion. Disentangling them reveals a structure that recurs at every scale of human organisation.

Four Purposes

Every loop serves one of four purposes. They are not variations on a theme. They are different in kind.

These four purposes are not hierarchical — one is not “above” another — but they operate at fundamentally different cadences. Execution runs in seconds or minutes. Validation runs in minutes or hours. Improvement runs in days or weeks. Governance runs in weeks or months.

Two Mechanisms

The agentic community has developed specific mechanisms for the first two purposes:

• The execution mechanism is Observe-Plan-Act-Reflect: the agent surveys its environment, decides what to do, does it, evaluates the result, and repeats.
• The validation mechanism is the self-verification loop: the agent runs its own output through deterministic gates — a linter, a test suite, a type checker — and self-corrects before a human ever sees the result.

The improvement and governance mechanisms are, for now, still human activities. The improvement loop is the retrospective: a human reviews the trajectory log, identifies failure patterns, and adds gates or tools to the harness. The governance loop is goal-setting: a human defines what “done” looks like, and encodes that definition into verifiable acceptance criteria.

The Key Distinction: Improvement Is Not Governance

A common confusion, visible throughout the discourse, is treating the improvement loop and the governance loop as the same thing. They are not.

• The improvement loop asks: “The agent keeps making this class of error. Should we add a gate?” It makes the system better at what it does.
• The governance loop asks: “Is the agent optimising for the right thing? Does the goal need to change? Is the harness encoding our actual intent?” It questions what the system should be doing.

The improvement loop is methodological. The governance loop is teleological. Both are essential, but they are answers to different questions, done at different cadences, by people with different decision rights. Conflating them — treating “add a gate” and “change the goal” as the same kind of activity — obscures where human judgment is most needed. The deepest layer of the governance loop cannot be automated, because that is where intent itself is defined, and bare intent is not computable from data.

The Governance Loop and the Cognitive Absorption Rate

The governance loop has a second, less visible function beyond periodic goal-setting: it is the channel through which execution insights are absorbed into intent. Every time an agent builds something, the build reveals things about the problem — edge cases that were not in the specification, design tensions between requirements, unstated assumptions that turned out to be false. These insights should change what gets built next. But the channel through which they flow is human cognition, and human cognition has not accelerated.

An agent can generate ten files in two minutes. A human cannot review, understand, and reorient at that pace. The binding constraint in the framework is not validation latency or shipping speed. It is the cognitive absorption rate — the speed at which a human can comprehend what the agent built, what it implies about the problem, and whether the goal should change in response. The governance loop is slow not because governance is inherently slow, but because the comprehension it depends on is. And that comprehension — the formation of fresh judgment about something just built — cannot be handed off, because it is where judgment meets intent.

This is the deepest of the three bottleneck layers. Validation latency can be addressed with better gates. Design drift can be addressed with architectural review patterns. But problem-solution co-evolution — the feedback from building back to intent — runs at the speed of human thought, and human thought has not gotten faster.

The Fractal Property

These four purposes are not unique to the agent level. They recur at every scale of human organisation. A delivery team has its own execution loop (the sprint), its own validation loop (QA, integration testing), its own improvement loop (the retrospective), and its own governance loop (backlog prioritisation). So does the enterprise. So does the market. The pattern is self-similar.

This is why the “inner/outer loop” terminology, useful as it is, can be ambiguous. When someone says “the outer loop,” they might mean validation at the agent level (CI/CD for generated code), validation at the delivery-team level (integration testing), or governance at the value-chain level (business case approval). Same word, different level, different purpose. The framework that follows uses purpose and level explicitly, so that when we say “validation,” we can specify whose validation, of what, at what cadence.

Harness and Scaffold

A note on vocabulary, because one word is already straining under the load. Throughout the discourse — and in the first draft of this essay — harness is used to name everything: the linter bolted to the model, the test runner, the approval gates, the goal-setting structure, the whole multi-level apparatus. That is precisely the overloading this section set out to avoid, committed one level up. The fix is the same as before: split the word.

Let harness mean the deterministic machinery wrapped directly around the model — the tools it can invoke and the gates that verify its output. The harness serves execution and validation. It is close to the metal: a compiler, a linter, a type checker, a sandboxed test runner, a permission boundary enforced at the engine level. It is computational, fast, and binary — the part of the system you could, in principle, prove correct.

Let scaffold mean the organisational system that surrounds the harness — the retrospectives that decide which gates to add, the goals that define what “done” means, the trajectory reviews where a human absorbs what was built and decides whether the goal should change. The scaffold serves improvement and governance. It is not close to the metal; it is close to intent. It is human and agentic, slow, and judgment-laden — the part of the system no one can prove correct, only judge.

The harness wraps a model. The scaffold wraps the harness — and, at higher levels of the fractal, wraps the teams and value chains that run many harnesses at once. Engineers iterate on harnesses. Organisations iterate on scaffolds. Keeping the two words apart keeps the two activities apart, which is the entire point of a vocabulary.

A Literature Survey: What Worked, What Didn’t, and What the Failures Reveal

The stories that follow are drawn from the public record — Hacker News posts, company blogs, conference talks, and the broader discourse — and they are selected not for novelty but for what each reveals about the conditions under which loop engineering succeeds or fails. Each case is tagged with the loop purpose and organisational level it primarily illuminates, so that the pattern across them is visible not just as narrative but as structure.

1. Anthropic — Internal Engineering at Scale

Primarily illuminates: execution + validation at the agent level; governance at the delivery-team level

Boris Cherny, Head of Claude Code, has disclosed in talks and online discussions throughout 2025–2026 that Anthropic engineers using harness engineering ship eight times more code daily than before, and that by May 2026 Claude authored over 80% of merged production code at the company. The specific pattern Cherny credits is the self-verification loop — the validation mechanism described above: the agent runs its own output through deterministic checks, observes failures, and self-corrects before a human ever sees the code. He claims a 2–3× quality improvement from this pattern alone.

The numbers are not independently verified and come from the organisation with the strongest incentive to make the case. But they are consistent with everything the independent stories demonstrate at smaller scale. The architecture works. The question is not whether — it is what it costs to build well.

2. envref — The Purest Public Demonstration

Primarily illuminates: execution at the agent level; governance at the individual level

In February 2026, a single developer posted to Hacker News about envref, a Go CLI tool for managing environment variable references across seven secret backends. The developer did not write the tool. They defined a goal, set up an agent loop with Claude Code (Opus 4.6), and walked away.

The loop terminated not because the agent decided it was done, but because every item in the backlog had been implemented and every gate — compiler, linter, test suite — passed. The governance decision (the goal) was verifiable. The execution loop ran. The validation gates determined when the work was complete.

What the story does not capture — because it is not visible from the outside — is the governance work that preceded the run and the comprehension work that followed it. The goal did not write itself. The backlog was structured for autonomous execution. The verification gates were defined. And after the agent finished, the developer still had to understand the architecture that emerged across those 77 iterations — the design decisions the agent made, the abstractions it chose, the trade-offs it embedded in the code. The eight hours and forty-one minutes of autonomous execution were the output of a governance decision; the governance itself required design, and the comprehension of the output required time. Execution accelerated. Comprehension did not.

3. Altimate Code — The Harness as Empirical Advantage

Primarily illuminates: validation at the agent level

In March 2026, Altimate Code — founded by Anand and Pradnesh, who previously built dbt Power User and Datamates VS Code extensions with over 750,000 combined installs — posted a direct A/B test on the dbt Labs ADE-bench. The results were striking:

The harness includes: deterministic column-level lineage at 0.26 milliseconds per query across a 500,000-row benchmark, 26 SQL anti-pattern rules with zero false positives, local schema validation in 2 milliseconds without touching the warehouse, and engine-level permission enforcement. Every component is deterministic. None involves a model call.

The Altimate result is the clearest empirical evidence yet that the validation mechanism, not the model, is the binding constraint on quality. The implication is uncomfortable for an industry that has organised itself around model capability rather than system design. Returns on harness investment compound; returns on prompt investment do not.

4. Gus and Runtime — The Solo-to-Team Wall

Primarily illuminates: governance + validation at the delivery-team level

Gus, founder of Runtime (YC P26) and previously of Mentum (YC S21), posted in May 2026 about a pattern that has become one of the most-discussed in the loop engineering discourse — because it is a failure story, and the failures are more instructive than the successes.

As a solo developer, Gus shipped four full-stack products in three months using coding agents. The workflow was fluid, high-bandwidth, and effective. When he tried to roll the same workflow to his entire team, it collapsed:

• PRs turned into unmergeable “slop” — generated code that passed no shared quality bar
• Context was trapped in one person’s head — the implicit understanding of what “good” meant
• Non-engineers could not safely touch a real codebase — no guardrails existed
• The agents produced code at different quality levels because different team members had different implicit standards

The failure directly led to building Runtime as infrastructure for team-scale agent loops. The fix was to externalise the governance and validation mechanisms — shared context, deterministic validation, permission boundaries, sandboxed execution — from the individual developer’s head into a shared, executable system. Runtime now has multiple YC scaleups live on the platform, including a fintech unicorn that built an on-call inspector agent wiring PagerDuty → Sentry → repo to autonomously find root causes and open PRs with unit tests before anyone gets paged.

5. The OAuth Developer — Four Years of Failure, Three Weeks of Shipping

Primarily illuminates: execution at the agent level; governance at the individual level

One of the more striking personal narratives in the discourse is the developer who spent four years trying to build an OAuth 2.0 server — PKCE, DPoP, MFA, WebAuthn/Passkeys, EU sovereign requirements — and never finished it. After discovering agentic coding loops, they shipped it in three weeks with 91% test coverage.

The story controls for the developer — same person, same project, same domain knowledge. The only variable was the technique. Four years of hand-coding produced an unfinished project. Three weeks of loop engineering produced a shipped product. The difference is not a speedup; it is the difference between completion and abandonment.

But the loop did not eliminate the need for human comprehension. OAuth 2.0 with modern extensions involves dozens of RFCs, subtle interactions between grant types, and cryptographic requirements that interact with deployment topologies. The agent executed faster; the developer still had to understand what was built and why. The 91% test coverage implies review, adjustment, and the absorption of what the build revealed about the protocol’s complexity. Execution accelerated dramatically. The governance loop — understanding the implications of the built system for the problem it was meant to solve — remained a human activity, running at the speed of human cognition.

6. CircleCI Chunk — Moving Validation into the Inner Loop

Primarily illuminates: validation at the agent level

CircleCI’s Chunk sidecars, built by Olaf in the CTO office and posted in May 2026, address a specific failure mode in the validation mechanism: by the time CI catches a failure in agent-generated code, the agent has already moved on and useful context is gone.

Chunk runs scoped “microbuilds” in lightweight Firecracker microVMs that mirror the CI environment, triggering automatically during agent stop/evaluation events. Validation moves into the execution loop, so the agent sees failures while context is still fresh.

7. Loki Mode — Multi-Agent, Research-Backed

Primarily illuminates: execution + validation at the agent level (multi-agent)

Loki Mode, posted in January 2026, is an open-source multi-agent system that orchestrates specialised AI agents to take a PRD to a deployed product with zero human intervention. It implements virtually every scientifically-proven pattern from the 2025–2026 AI agent literature:

• Boris Cherny’s self-verification loop (validation mechanism, Anthropic)
• CONSENSAGENT (ACL 2025) — blind review + devil’s advocate, producing a 30% reduction in false positives
• GoalAct — global planning → skill decomposition → local execution, yielding a 12%+ improvement in success rate
• Multi-Agent Reflexion — structured debate between Implementer, Skeptic, Advocate, and Synthesizer roles (validation through adversarial review)

8. MCP Agent Mail — Cross-Agent Coordination Without a Human

Primarily illuminates: execution at the agent level (cross-agent)

MCP Agent Mail, posted in October 2025, demonstrated that multiple coding agents — Claude Code, Codex, and others — could coordinate across separate repositories by sending structured messages to each other, described by the creator as “like Gmail for coding agents.” The agents “take to this system like a fish to water”, sending detailed messages, coordinating naturally, giving each other feedback, and pushing back on bad ideas. Different frontier models (Claude + GPT + Gemini) were observed to collaborate in complementary ways without a human in the middle.

9. Patched — Automating the Outer Loop

Primarily illuminates: validation at the delivery-team level

Patched (YC S24), launched in October 2024, automates post-code tasks — code reviews, documentation generation, and patches — through customisable, self-hostable workflows. It directly addresses the validation bottleneck at the delivery-team level that CircleCI’s Zuber identified. An example automated PR generated SDK bindings with complex type information for the Stack Auth project.

The Pattern Across the Survey

Look across all nine cases and a clear shape emerges — not just in the narratives, but in the loop purposes and levels they illuminate.

1. The individual hero story repeats — and it is always about execution and governance. Gus shipping four products in three months. The envref developer building a CLI tool autonomously for $170. The OAuth developer finishing a four-year project in three weeks. In each case, one person defined the governance (the goal), the agent ran the execution loop, and the validation gates determined completion. The pattern works at the individual level. But even at the individual level, the governance loop — understanding what was built and what it means for the problem — remained a human activity. The agent accelerated execution. It did not accelerate comprehension.

2. The team scaling crash is the rule, not the exception — and it is always a governance failure. Every founder who succeeded solo hit a wall when rolling the same workflow to a team — Gus at Runtime, the pattern that Altimate Code’s founders observed at Fortune 500 data estates, the implicit standards problem that Anthropic solved by making the scaffold explicit and shared. The governance mechanism (the definition of “good”) was implicit in one person’s head. Brains do not compose. The fix is always the same: externalise governance — shared goals, shared gates, shared guardrails — into an executable system. But externalising governance does not externalise comprehension. The team still needs to understand what the agents built.

3. Deterministic validation beats probabilistic, every time. Altimate Code’s A/B test is the cleanest evidence, but the pattern is visible everywhere. envref’s Go compiler and test suite. CircleCI’s microbuild sidecars. The self-verification loop that Cherny describes. In every case, the highest-leverage investment in the validation mechanism is not a better model — it is a faster, cheaper, more reliable verification gate. Deterministic validation addresses the first bottleneck layer (validation latency). It does not address design drift or problem-solution co-evolution.

4. The infrastructure layer is emerging, fast — and it is organised by loop purpose. Runtime targets governance and validation at the delivery-team level. CircleCI Chunk targets validation latency at the agent level. Altimate Code targets deterministic validation at the agent level. Patched targets validation automation at the delivery-team level. Loki Mode and MCP Agent Mail target execution coordination at the agent level. Each product is solving a different loop-purpose at a different organisational level. The market is voting, with increasing specificity, that this is not a fad.

These four patterns are specific to software, but the structural forces that produced them are not. Each one generalises.

The General Case

The loop-purpose framework is not really about software. It is about any complex human effort where fast, creative execution must eventually be reconciled with slow, high-stakes validation — and where someone must periodically ask whether the whole enterprise is pointed in the right direction. Software delivery happens to be a particularly clean instance of the pattern, but the pattern is everywhere.

The Four Purposes, Generalised

In every domain, execution is where the making happens — the iterative, judgment-heavy, flow-state work that practitioners find meaningful. Validation is where that work is reconciled with the world — checked, governed, made safe. Improvement is where the system that does the making and the checking is refined. And governance is where intent is set — the choice of what to make, and why.

The Fractal Property

The four purposes are not unique to any one level. They recur at every organisational scale, at progressively slower cadences — the delivery team, the enterprise, and the market each run all four. The structure is self-similar. And if the same four loops repeat at every level, the levels must connect to one another — which they do, in a specific and consequential way.

The Cascade

The governance output of one level becomes the execution input of the level below:

Strategic governance     →   "Enter the European market"
    ↓
Value chain execution    →   Formulate GDPR-compliance initiative
    ↓
Value chain governance   →   "Build consent management feature"
    ↓
Delivery team execution  →   Sprint backlog: consent API, consent UI, consent audit
    ↓
Delivery team governance →   "Implement POST /consent endpoint"
    ↓
Agent execution          →   Observe → Plan → Act → Reflect (write the endpoint)

Each level receives a governance decision from above, executes against it, validates the output, improves its process, and makes governance decisions for the level below. The cascade is how intent flows downward through an organisation. The harness is what governance at one level looks like once it has been encoded as execution constraints for the level below.

But the cascade also runs in reverse. Execution at each level produces insights that should flow upward and adjust governance at the level above. When an agent builds the consent endpoint, the build reveals things about the API design that the delivery team should know. When the delivery team ships the consent feature, the shipping reveals things about user behaviour that the value chain should know.

The upward flow is information; the downward flow is intent. The organisation functions when both flows are healthy — and when both run at cadences that match.

This is a restatement, in the language of organisational loops, of a systems principle that has been understood for decades. Russell Ackoff, the pioneer of systems thinking, put it bluntly: “If you optimize the parts, you sub-optimize the whole.” A system is not the sum of its parts; it is the product of their interactions. Improving one component in isolation — making execution dramatically faster — does not improve the system. It strains the interactions that connect execution to validation, to improvement, to governance. The parts accelerate; the interactions break.

This is why AI has not yet delivered the productivity revolution that its raw capability suggests. AI accelerates execution — one part of one loop at one level. It does not accelerate validation, which runs at the speed of trust. It does not accelerate improvement, which runs at the speed of pattern recognition. It does not accelerate governance, which runs at the speed of deliberation — and, under acceleration, at the speed of comprehension. Nor does it accelerate the upward cascade of information, which is the only mechanism by which execution insights can reach governance and adjust intent. Local optimisation has deoptimised the whole. It will continue to do so until the surrounding loops — and the cascade that connects them — are re-engineered to match the speed that AI has imposed on execution.

Where AI Disrupts the Cascade

AI enters at the execution level first — the agent loop. This is what the literature survey captures. But the disruption propagates upward:

1. Agent execution accelerates → delivery-team validation becomes the bottleneck. This is the three-layer traffic jam described earlier. The team can generate code faster than it can review, understand, and absorb it.
2. Delivery-team validation accelerates (through tools like Patched, CircleCI Chunk, Runtime) → value-chain governance becomes the bottleneck. The team can ship faster than the business can decide what to ship.
3. Value-chain governance accelerates → strategic governance becomes the bottleneck. The organisation can enter markets faster than leadership can choose which markets to enter.

The traffic jam Zuber identified is level 1. But the same structural problem will appear at levels 2, 3, and beyond, in sequence. Each level’s validation bottleneck is the next level’s governance bottleneck. The cascade is predictable.

And at every level, the deepest bottleneck is the same: the cognitive absorption rate. Generation accelerates; comprehension does not. The human who must understand what was built, what it means, and whether the goal should change — that human is the binding constraint at every level of the cascade.

The Meta-Loop: Governance Under Acceleration

When an AI agent is the executor — when the inner execution loop is no longer a human activity — the human’s role in the four-purpose framework shifts. The human is no longer in the execution loop. They are not primarily in the validation loop, though they set its thresholds. They operate in the improvement loop (refining the harness based on observed failure patterns) and, most importantly, the governance loop (defining what the system should do and why).

This is Kief Morris’s “humans on the loop” placed into the framework. The human reviews the system that wraps the model — the harness of tools, gates, and guardrails, and the scaffold of goals and retrospectives around it. When output is wrong, the human does not fix the output. They strengthen the harness. When strategy shifts, the human does not re-prompt the agent. They change the governance — the goal, the acceptance criteria, the definition of done.

And then, at the highest level of governance, the human reviews the trajectory — the log of what the agent did, why it did it, and whether the harness caught what it should have caught. In an agentic organisation, the audit trail is not the work product. It is the log of how the work was produced. The artefact is output. The trajectory is the record of judgment.

But the governance loop is not only the periodic, deliberate review of strategy. It is also — and under AI acceleration, increasingly — the rapid absorption of what execution reveals about the problem. Every time an agent builds something, the build surfaces insights: an edge case that was not in the specification, a design tension between two requirements, an unstated assumption that turned out to be false. These insights should change the goal. But they can only do so if a human absorbs them, understands their implications, and adjusts intent.

This is the meta-loop in its tightest form: build, review, learn, adjust. It must run at the cadence of the build, not the cadence of the quarterly strategy review. And it is the hardest loop to accelerate, because it runs at the speed of human comprehension — and human comprehension has not gotten faster.

This is visible across the literature survey. The envref developer did not review 77 iterations of Go code. They set the governance (the goal), let the execution and validation loops run, and then had to understand the architecture that emerged. Anthropic’s engineers do not review every line of Claude-authored code. They improve the harness when output is wrong, and they govern the goals when strategy shifts — but they still have to comprehend what the system produced. The OAuth developer did not hand-debug the token rotation logic. They let the execution loop iterate until the validation gates passed, and then they reviewed the result — absorbing what three weeks of autonomous iteration revealed about OAuth’s complexity.

The governance loop is where human judgment resides in an agentic organisation. Its deepest layer cannot be automated — not because the technology is insufficient, but because that layer is where intent is defined and comprehension is exercised, and neither is computable from data. Much of what we loosely call governance sits above that layer and is instrumental — derivable from a higher goal plus data — and that part will increasingly be automated; the distinction is drawn out below. But the floor remains. You cannot optimise your way to a purpose. And while you can accelerate the acquisition of understanding — AI has done exactly that, and spectacularly — you cannot yet outsource the formation of judgment about a thing you have only just made.

What This Means

The four-purpose framework suggests a reorganisation of human effort that is more profound than “AI makes us faster.” It suggests structural changes to how knowledge work is organised, how trust is built, and what skills are valued.

The Skillset Shift

In every domain, the core human activity shifts from execution to improvement and governance. From writing the code to designing the system that writes the code. From drafting the brief to defining the goals and gates that shape the brief. The skills that matter are no longer primarily domain execution — syntax, drafting technique, modelling fluency — though these remain valuable for harness design. What matters is the ability to specify goals precisely enough for an autonomous agent to execute against, to design validation gates that catch errors deterministically, to review trajectories rather than artefacts, and to distinguish between “the system needs improvement” and “the goal needs to change.”

This shift will be uncomfortable. The historical pattern I have written about elsewhere — surgeons resisting anaesthesia because it devalued their speed-based skill, master weavers burning power looms because they threatened a lifetime’s craft — is repeating across every domain AI touches. The resistance is not irrational, but neither is it likely to prevent the transition. As Addy Osmani of Google put it in 2026: “I’m skeptical, and you absolutely have to be careful.” The question for individual knowledge workers is not whether the transition will happen, but whether they will help shape the harness and the scaffold or be shaped by them.

The Cognitive Absorption Rate Is the Ultimate Constraint

For all the attention paid to model capability, token costs, and validation latency, the deepest constraint in the framework is the one that is least discussed: the speed at which a human can understand what an agent has built and what it means. Generation has accelerated by orders of magnitude. Comprehension has accelerated too, in part — AI is extraordinary at explaining an established concept, summarising a field, or walking a newcomer through unfamiliar code. But the part that matters here has not: the formation of novel judgment about an artefact that did not exist five minutes ago. There is no literature to summarise about a system the agent built this afternoon. You are its first reader, and that first reading runs at human speed.

This is not a technical problem. It is a cognitive one. And it means that the organisations that thrive under AI acceleration will not be the ones with the fastest models or the most elaborate harnesses. They will be the ones whose governance structures are designed for rapid comprehension: small batches of work that can be understood quickly, tight feedback loops between building and reviewing, and governance cadences that match the speed of human cognition rather than the speed of the calendar.

The envref developer understood this, perhaps implicitly. Eight hours and forty-one minutes of autonomous execution produced an output that could be reviewed in an afternoon. The batch was sized for comprehension. The OAuth developer understood this. Three weeks of iteration produced a system that could be understood against the RFCs it implemented. The batch was scoped to the problem. In both cases, the governance loop — review, absorb, adjust — could close at a human cadence because the batch was human-sized.

Validation Will Be Re-Engineered, Painfully

Every domain has its version of the validation loop — the compliance review, the editorial board, the deployment pipeline, the peer review committee — and every one of them is a bottleneck waiting to be broken. The organisations that re-engineer validation first will absorb the AI acceleration of execution instead of being crushed by it. The ones that do not will generate infinite drafts and ship none of them.

The re-engineering will not be comfortable, because validation is where power resides. Peer review is not just a quality mechanism; it is a gatekeeping function that determines whose work is published and whose is not. Regulatory approval is not just a safety check; it is a barrier to entry that protects incumbents. Editorial sign-off is not just a quality filter; it is a locus of editorial authority. Re-engineering validation means redistributing power, and power is never redistributed willingly.

Building the Harness Is Governance

Assembling the harness — choosing which deterministic gates to enforce, setting the goals and acceptance criteria the agent must meet, placing human-approval boundaries at dangerous thresholds, requiring trajectory logging for auditability — is not a software task. It is the scaffold’s defining act, and it is governance. It happened to be discovered in software because software is the domain where execution was accelerated first.

Every domain will need its own harness, and the governance to build one. Law will need deterministic gates for legal reasoning — does the brief cite precedent correctly? Does it address the relevant statutes? Medicine will need deterministic gates for diagnosis — does the proposed treatment align with established guidelines? Does it account for contraindications? Finance will need deterministic gates for modelling — does the model pass backtesting? Does it comply with regulatory constraints?

The domains that learn to build these harnesses first will be the domains where AI adoption is fastest and safest. The domains that do not will oscillate between two failure modes: rejecting AI entirely (and falling behind) or adopting AI without governance (and producing unreliable output at scale). Building the harness is the middle path, and it is the only path that scales.

Most Governance Is Instrumental

The improvement loop and the governance loop are easy to confuse in practice, and the confusion is expensive. Adding a gate is improvement; changing the goal is governance. An organisation that treats every failure as an improvement problem — “let’s add another gate” — will eventually build a harness so constraining that the agent cannot execute. An organisation that treats every failure as a governance problem — “maybe we’re building the wrong thing” — will never stabilise long enough to ship. The art is knowing which loop you are in, and when to switch.

But even governance is not one thing, and there is a tempting overstatement lurking in this framework that honesty requires naming. To say flatly that “governance cannot be automated” is to repeat, one level up, the very overloading this essay set out to expose. Governance splits, just as loops did.

Most of what the framework calls governance is instrumental: a goal derived from a higher goal plus data. “Enter the European market” is not a sovereign act of human will — it is a conclusion that should fall out of total addressable market, margin structure, competitive density, and regulatory cost. “Prioritise the consent feature” is a scheduling decision derivable from risk exposure and dependency order. These set goals for the level below, and so they are governance — but they are computable governance, and as the context available to agents deepens, they will increasingly be proposed, and then made, by agents. An agent with the right data may well make the European call better than a biased executive defending last year’s strategy.

What does not reduce to data is terminal governance: the choice of what to value in the first place. Why enter any market. What the enterprise is for. Which goods count as goods. There is no higher goal from which to derive this one — it is where the regress of goals stops. This is what cannot be optimised, because optimisation presupposes an objective function, and terminal governance is the act of choosing the objective function itself.

The honest trajectory, then, is not the comfortable “humans keep governance.” It is narrower and more unsettling: the human-owned region contracts over time — from all governance, to instrumental governance, to terminal governance alone. The instrumental layer drains upward into the agents. What remains is the answer to why do any of this at all — and the genuinely open question is not whether that layer survives, but how few people a civilisation needs to hold it, and who they turn out to be.

One caution against filing this under “future problem”: terminal choices are load-bearing now, not merely eventually. The data that would justify entering Europe is itself shaped by prior terminal commitments — what the organisation chose to measure, what it counts as success, whose welfare even enters the model. Instrumental governance always runs on rails that terminal governance laid down. The rails are invisible, which is precisely why they are so easy to mistake for nothing.

And laying those rails depends on comprehension — you cannot govern what you have not absorbed. The loops that matter most are the ones that cannot be automated.

Conclusion: The Harness and the Scaffold

The discourse around AI-assisted development has spent three years focused on the model — its capabilities, its limitations, its trajectory. That focus was appropriate when the model was the binding constraint. It is no longer appropriate, in software or anywhere else. The binding constraint is now the system around the model: the tools it can invoke (execution), the gates that verify its output (validation), the process by which the system improves (improvement), the goals that tell it what to do and why (governance) — and the speed at which humans can comprehend what all of that produces.

The stories surveyed above all point to the same conclusion, and that conclusion generalises. The envref developer did not succeed because of a clever prompt. Altimate Code did not outperform a more expensive model because of a better model. Gus’s team did not fail because the model was insufficient. The OAuth developer did not ship in three weeks because the model was a better programmer than he was. Anthropic’s 8× output gain did not come from a model upgrade. In every case, the difference was the harness and the scaffold around it — the machinery that executes, and the system that decides what the machinery is for.

But the harness does not eliminate the need for human comprehension. It channels it. The human who designs the harness, reviews the trajectory, absorbs the insights, and adjusts the goal — that human is doing something no AI can do. They are exercising judgment. They are setting intent. They are understanding what was built and what it means.

The harness pattern is not about software. It is about how complex human effort is organised when the speed of thought is no longer the binding constraint. The domains that understand this — that distinguish execution from validation from improvement from governance, that build a harness and a scaffold at each level, that recognise the fractal and cascade properties of the loops they inhabit, and that design for the cognitive absorption rate of the humans who must comprehend what the machines produce — will thrive. The domains that do not will generate infinite drafts and ship none of them.

The loop is not the point. The harness and the scaffold are. The harness — the deterministic machinery wrapped around the model — is the artefact engineers will iterate on. The scaffold — the organisational system that decides what the harness is for, and absorbs what it produces — is the artefact the rest of us will iterate on. At every level, in every domain, for the next decade.