# Loop Engineering — Enclavia.ai Technical Whitepaper

> Source: /resources/whitepapers/Enclavia%20Loop%20Engineering%20Whitepaper.pdf

## Compound Value or Compound Risk

A quantitative architecture brief on self-prompting agent loops — the five moves, the generator/evaluator separation, the four silent costs — and why the missing layer is governance, identity, and sovereign control of the loop itself.

Audience Research scientists, ML/data-science leads, Chief Architects, VP Engineering, and platform teams building or governing autonomous agent loops in regulated environments.

## Dev Roy CEO & Co-Founder, Enclavia.ai

June 2026 · v1.0

## Your Data · Your AI · Your Way

Your Data · Your AI · Your Way 1 © 2026 Enclavia.ai · Confidential

## Executive Summary

In the first week of June 2026, three engineers independently described the same shift. Peter Steinberger (creator of OpenClaw, now at OpenAI) posted that you should stop prompting coding agents and start designing the loops that prompt them — a post that crossed roughly eight million views. Boris Cherny, who leads Claude Code at Anthropic, said his job is no longer to prompt Claude but to write loops that prompt Claude and decide what to do next. Addy Osmani (Director, Google Cloud) named the pattern in writing on June 7. One ignition, one echo, one name, inside a single week.

The technical claim underneath the virality is precise and consequential: loop engineering is a fourth abstraction layer above prompt, context, and harness engineering. It does not make the practitioner better at the work — it removes the practitioner from doing the work at all, replacing them with an autonomous control system that discovers work, hands it to isolated agents, verifies results with an independent evaluator, persists state, and re-fires on a schedule.

This brief treats the loop as a distributed control system, not a prompting trick. We decompose one loop turn into its five moves and six realizing components, formalize the generator/evaluator separation as a measurable reliability mechanism, and quantify the four costs that accrue silently — verification debt, comprehension rot, cognitive surrender, and token blowout. The central finding is structural: The finding Loops drive the marginal cost of code generation toward zero. They do nothing for the cost of judgment. The same loop, built by two people, yields opposite outcomes — one compounds verified work they understand; the other compounds unreviewed decisions faster than anyone is watching.

Reliability comes from the quality of the constraints around the loop, not the size of the model inside it. Most published guidance stops at “add a verifier sub-agent.” That is necessary and insufficient. An autonomous loop with file-system write access, MCP connectors into issue trackers, databases, staging APIs, and Slack, running unattended on a timer, is a privileged, non-deterministic actor inside your trust boundary. The component nearly every explainer omits is the governed workspace: scoped identity, least-privilege writes, tamper-evident audit trails, deterministic policy gates, budget circuitbreakers, and fast rollback — applied to the loop itself.

Section 7 maps this missing layer onto the Enclavia.ai platform. Loop engineering is, in our reading, the strongest argument yet for sovereign, governed, model-independent agent infrastructure: the place where generation is cheap, judgment is scarce, and control of the loop is the asset.

Your Data · Your AI · Your Way 2 © 2026 Enclavia.ai · Confidential

- Why “Another XX-Engineering Term” Is Actually a Layer

Change Over two years the field has accreted a sequence of “XX engineering” terms, each tracking a modelcapability release. They are not synonyms; they are a stack, and each layer automates one more thing the practitioner used to do by hand.

Layer What it optimizes Unit of work Human's role Prompt engineering A single instruction, one turn The words you type Author of each turn Context engineering What the model can see per call The assembled window Curator of context Harness engineering The scaffold around one agent run Tools, loops-of-one, retries Builder of the runtime Loop engineering The autonomous system that prompts, checks, and re-fires A scheduled, self-driving cycle Designer of the engine The distinction matters because of where the leverage sits. Prompt, context, and harness engineering all teach you to do the work better. Loop engineering moves you out of the work. As Osmani frames it, the weight of the sentence falls on replacing yourself as the entity that issues the prompt — you become the person who designs the engine, not the engine.

### The architectural lineage

Loop engineering did not appear from nowhere. It is the productization of a six-year control-theory lineage:

- ReAct (2022) — interleaved reasoning and action steps so a model could call external tools within a

turn.

- AutoGPT (2023) — open-ended autonomous task decomposition; high ambition, weak verification

and state.

- The Ralph loop (early 2026) — Geoffrey Huntley’s minimal pattern: run an agent inside a plain

while loop against a written spec, reset context each iteration, stop on a verifiable “all tasks done” signal. Proof that you need persistence, an external state file, and a stopping criterion — not a clever harness.

- Productized loops (June 2026) — the while loop becomes a scheduled automation; the context

reset becomes a worktree plus sub-agent; the done-check becomes a /goal condition graded by a separate model. Native primitives in Claude Code (/loop, /goal, /schedule) and OpenAI Codex (Automations, /goal added in Codex CLI 0.128.0 on April 30 2026), with connectors on both built on MCP.

Control-theory framing The loop structure — goal → act → observe → reflect → repeat — is borrowed directly from classical closed-loop control. The decisive difference: the element inside the loop is non-deterministic and can generalize. You gain adaptivity (the path can handle situations the designer never anticipated) and you pay for it in predictability and cost variance. That trade is the entire engineering problem.

Your Data · Your AI · Your Way 3 © 2026 Enclavia.ai · Confidential Sources: Osmani, “Loop Engineering” (addyosmani.com / O’Reilly Radar, Jun 2026); Steinberger (X, Jun 7 2026); Cherny (WorkOS “Acquired Unplugged,” The New Stack, Jun 2026) — practitioner statements. Lineage per BDTechTalks (Jun 22 2026). Command behavior per Anthropic/OpenAI docs as of Jun 2026. All vendor- or author-stated; not independently benchmarked.

Your Data · Your AI · Your Way 4 © 2026 Enclavia.ai · Confidential

- Anatomy of One Loop Turn: Five Moves, Six Components

A loop that runs unattended is not one long prompt. It is a small distributed system. A single turn decomposes into five moves; six concrete components realize them. Five components are capabilities; the sixth — memory — is the spine that carries state between runs.

### The five moves

Move Function Failure mode if absent

## Discovery

The loop finds its own work — reads failing CI, open issues, recent commits, PR comments — and decides what is worth acting on, instead of being handed a task list. Loop runs blind; needs a human to feed it, defeating autonomy.

## Handoff

Each task is assigned to one coding agent inside an isolated git worktree, so parallel agents never collide on shared files. Parallel agents corrupt each other’s working state; nondeterministic merge damage.

## Verification

A separate evaluator agent — instructed to assume the code is broken — reviews the diff, runs (not reads) the code, confirms tests/gates, and rejects shortcuts (e.g., deleting tests to pass). “Done” is a claim, not a proof. Generator self-praise ships silent defects.

## Persistence

Result, decision, run-log, and next state are written somewhere durable — a PR, issue, state file, board, or DB — never left in a context window that gets flushed. State evaporates on context reset; the loop re-derives the project from zero each cycle.

## Scheduling

A timer, webhook, CI event, or queue trigger re-fires the loop. This is what converts one agent run into an actual loop. You have a one-off session, not a loop. “Check CI every morning” never happens unattended.

### The six realizing components

The “orange-book” decomposition maps the five moves onto six shippable parts that now exist as native product primitives rather than bespoke bash:

- Automations — cron, webhooks, CI triggers, cloud routines, queue events that wake the loop

without a human pressing go.

- Worktrees — isolated branch boundaries so parallel agents don’t step on each other; every run gets

a clean review surface.

- Skills — project knowledge written down once (conventions, build steps, “we don’t do it like this

because of that incident”) so the agent reads intent every run instead of re-guessing. Skills are the authoring format; a plugin is how you ship them across repos.

- Connectors — MCP-based access to issue trackers, databases, staging APIs, Slack. A loop that

can only see the filesystem is a tiny loop; connectors are also where the privilege surface — and the token tax — expand.

- Sub-agents — the generator/evaluator split made concrete: distinct agents for making and for

skeptically checking.

- Memory — the durable spine (CLAUDE.md / AGENTS.md indices, state files, skills) that holds

context between runs. Without it the loop has no continuity; with it, work compounds. Your Data · Your AI · Your Way 5 © 2026 Enclavia.ai · Confidential The intent-debt economics of skills An agent starts every session cold and fills any gap in your intent with a confident guess. A skill externalizes intent once, where the agent reads it every cycle. Without skills, a loop re-derives the entire project from zero on every run — paying the same discovery cost repeatedly. With skills, intent compounds and per-cycle token cost falls. This is not a style preference; it is a direct lever on the token-blowout cost quantified in Section 4.

Sources: Osmani (O’Reilly Radar / Substack, Jun 2026); loopengineering.run, loopengineering.app reference patterns; “orange-book” sixpart decomposition (GitHub, Jun 2026). Author/community-stated. Your Data · Your AI · Your Way 6 © 2026 Enclavia.ai · Confidential

- The Generator/Evaluator Separation as a Reliability

Mechanism The single most load-bearing claim in the loop-engineering literature is empirical and falsifiable: an agent asked to grade its own output tends to praise it. Self-evaluation is positively biased. Therefore the worker that wrote the code must not be the judge that decides whether it is done.

### Why self-grading fails, formally

Frame each loop turn as a generate-then-judge pipeline. A generator G produces an artifact a; an evaluator E emits an accept/reject decision. When G and E are the same model instance sharing context, the judgment is conditioned on the same latent state that produced the artifact — including the rationalizations that justified it. The decision correlates with the generation rather than testing it. The observable result is a high false-accept rate: defects pass because the grader is invested in the work.

Splitting E into an independent instance — ideally a smaller, cheaper model with an adversarial system prompt (“assume this code is broken; reject until proven otherwise”) — decorrelates judgment from generation. Two practical findings recur across the corpus:

- Tuning a skeptical evaluator is more tractable than making a generator self-critical. You can

push an independent E toward high recall on defects without degrading G’s fluency; trying to make G critical of its own work degrades generation and still under-detects.

- The evaluator should run the artifact, not read it. Execution-grounded verification (tests pass, diff

is clean, endpoint returns 200) converts “done” from a linguistic claim into a checkable proposition. Design rule Separate the maker from the checker. Give the checker a verifiable, preferably binary, pass/fail signal and the authority to say no. A loop becomes safe precisely when “it’s done” is produced by something other than the thing that did the work — and even then, “done” is a claim, not a proof, until a human gate confirms anything irreversible.

### Reliability comes from constraints, not model size

The Stripe “Minions” pipeline (Section 5) is the reference proof: it interleaves deterministic gates with probabilistic LLM steps. A human triggers the run; a deterministic orchestrator assembles context; the LLM writes code; a hard-coded gate runs immediately and cannot be skipped by the agent; if lint fails the agent must fix it; a hard-coded step commits; a human reviews. The reliability budget is spent on the gates, lints, tests, and workflow — not on a hotter model. A well-designed loop multiplies a good engineer; a badly-designed loop multiplies a bad decision just as fast, with less of anyone watching.

Sources: HyperAI/IEEE note abstract (Jun 2026); Osmani (Jun 2026); community summaries of the generator/evaluator separation. The selfpraise tendency is reported as an empirical finding in the source note; specific false-accept rates are not publicly quantified and are presented here as a mechanism, not a benchmarked figure.

Your Data · Your AI · Your Way 7 © 2026 Enclavia.ai · Confidential

- The Four Silent Costs (and How to Instrument Them)

Loops fail quietly. None of the four costs below trips an alarm while the loop is running; each accrues like interest. For a technical audience the useful move is to treat each as a measurable quantity with a leading indicator and a control.

## Cost Definition Leading indicator (instrument

this) Control Verification debt The gap between “the loop says done” and “it is provably done.” Grows whenever a turn merges without an independent, execution-grounded check. % merges with no independent evaluator pass; test-coverage delta per merged PR; reverts within N days.

Mandatory separate verifier; executiongrounded gates; human gate on irreversible actions. Comprehension rot The faster a loop ships code you didn’t write, the larger the gap between what exists in the repo and what any human actually understands.

Ratio of machine-authored to humanreviewed LOC; bus-factor on looptouched modules; time-to-explain a random diff. Enforced human read of merged diffs; review SLAs; skills that keep architecture legible. Cognitive surrender The comfortable posture of accepting whatever the loop returns without forming an opinion. Same action as designing a loop with judgment

- opposite intent, opposite

outcome. Accept-without-comment rate; declining reviewer edit frequency; “rubber-stamp” latency on approvals. Keep the engineer in the design and review path; require a recorded judgment per merge. Token blowout Once you have automations + sub-agents + connectors + retries, spend stops being a billing line item and becomes a systems property. An unbounded loop burns a fortune while looking productive.

Tokens per closed unit of work; cost variance run-to-run; retry depth; MCP context tax per connector call. Budget policy = stopping condition; circuit breakers; demote deterministic steps out of the LLM. The budget-policy theorem If your loop has no budget policy, it has no stopping condition — only a failure mode. Token economics is the one cost that is simultaneously a runaway financial risk and the cleanest hard signal for a circuit breaker. A loop that detects identical file states, repeating console errors, or no measurable progress across three consecutive runs should trip the breaker, terminate, and alert a human.

### Distill and demote

A maturity move specific to loops: analyze the stabilized loop’s execution logs and identify predictable, repetitive LLM calls — identical text parsing, structural refactors the model performs the same way every time. Strip those out of the non-deterministic prompt and rewrite them as compiled, deterministic script blocks in the harness. This acknowledges the core limitation: LLMs can perform many tasks but are rarely the most reliable or cheapest tool for each one. Every step demoted from probabilistic to deterministic reduces token blowout and verification debt simultaneously.

Your Data · Your AI · Your Way 8 © 2026 Enclavia.ai · Confidential Sources: cost taxonomy from Osmani (Jun 2026) and the HyperAI/IEEE note; “budget policy = stopping condition” framing per puppyone.ai (Jun 2026); circuit-breaker and distill-and-demote per BDTechTalks (Jun 22 2026). Indicators and controls in this table are Enclavia’s operationalization, not vendor-stated metrics.

Your Data · Your AI · Your Way 9 © 2026 Enclavia.ai · Confidential

- Three Loops in Practice: From One Engineer to Enterprise

Scale The source note surveys three real loops spanning four orders of magnitude in throughput. They share one shape and differ entirely in the constraint scaffolding around them.

### The morning-triage loop (individual)

A single engineer’s scheduled automation wakes each morning, performs discovery and triage across CI and issues, and surfaces what needs attention — designed once, then unattended. The point of the smallest case: you designed it one time and prompted none of the steps. That is the entire thesis made concrete.

### Stripe “Minions” (enterprise)

At the other end, Stripe’s enterprise pipeline merges over 1,300 machine-written pull requests per week. The architecture is explicitly a deterministic-gate sandwich around probabilistic steps:

- Human trigger initiates the run.
- Deterministic orchestrator assembles context (not the LLM).
- LLM agent writes code.
- Hard-coded gate runs immediately — the agent cannot skip it. Lint fails → the agent must fix.
- Hard-coded step commits the verified change.
- Human review closes the loop.

Throughput at this scale is a function of how trustworthy the gates are, not how large the model is. The 1,300+/week figure is the headline; the deterministic interleaving is the lesson.

### The scheduling reality (infrastructure)

Where the loop runs is a real architectural decision with a cost and sovereignty profile: Execution locus Advantage Cost / constraint Local loop / desktop scheduled task Frequent execution; direct access to local files; no per-run cloud floor; data never leaves the machine.

Machine must stay powered on. Cloud routines / GitHub Actions schedule Runs untethered from local state while you sleep. One-hour minimum cadence floor; data and execution leave your boundary. Sovereignty read The local-vs-cloud choice is not just operational — it is a data-residency and control decision. A loop that reads your codebase, your tickets, and your database, then re-fires every hour in someone else’s cloud, is continuous egress of regulated context. For healthcare, federal, and other regulated buyers, where the loop executes is a compliance boundary, not a convenience setting.

Sources: three-loop survey and Stripe Minions architecture per HyperAI/IEEE note abstract (Jun 2026) and orange-book summary; “1,300+ machine-written PRs/week” is vendor/press-reported, not independently audited. Scheduling trade-offs per the same note. Sovereignty interpretation is Enclavia’s.

Your Data · Your AI · Your Way 10 © 2026 Enclavia.ai · Confidential Your Data · Your AI · Your Way 11 © 2026 Enclavia.ai · Confidential

- The Missing Layer: Governing the Loop as a Privileged Actor

Most loop-engineering guidance ends at “add a verifier.” That closes one failure mode and ignores the larger one. Step back and describe what a production loop actually is: Threat model in one sentence A loop is a non-deterministic, self-prompting actor with write access to your filesystem and, through MCP connectors, to your issue tracker, database, staging APIs, and chat — running unattended on a schedule, capable of taking irreversible actions, and capable of making mistakes unattended.

That is a privileged service account that reasons. The discipline it demands is not prompt craft; it is the same discipline you would apply to any autonomous system inside your trust boundary — plus a few loop-specific controls. The component the explainers skip is a governed workspace wrapped around the loop, with five properties:

- Scoped identity. The loop runs as a first-class, least-privilege identity — not a developer’s ambient

credentials. Every connector call carries that identity.

- Least-privilege writes. Writes are allow-listed by path, repo, table, and action. The loop can touch

what its job requires and nothing else; “safe / allow-listed” actions proceed, everything else stops at a gate.

- Tamper-evident audit. Every discovery decision, diff, evaluator verdict, connector call, and token

cost is logged durably and immutably — the evidence trail a maintainer (or an auditor) can reconstruct after the fact.

- Deterministic policy gates. Irreversible actions — merge, deploy, issue-close, external send,

schema change — require a passed policy check and, where warranted, a human gate. Policy is code, not a prompt the model can talk its way around.

- Budget circuit-breakers + fast rollback. A hard spend ceiling and a no-progress detector

terminate runaway loops; every change has a clean branch boundary so rollback is one revert, not an archaeology project. Notice that four of the five properties are orthogonal to which model the loop calls. Identity, writescoping, audit, and policy live in the workspace, not the model. This is the precise reason loop engineering is an argument for governed, model-independent infrastructure rather than for any single frontier vendor.

Sources: “governed workspace / identity, scoped writes, audit trails, fast rollback” framing per puppyone.ai (Jun 2026); human-gate and allow-list pattern per cobusgreyling/loop-engineering reference (GitHub, Jun 2026). Threat-model synthesis and the five-property workspace are Enclavia’s.

Your Data · Your AI · Your Way 12 © 2026 Enclavia.ai · Confidential

- How Enclavia.ai Operationalizes Loop Engineering

Enclavia.ai is a sovereign AI infrastructure platform built on four pillars — data, model, architecture, and compute sovereignty. Loop engineering is the workload that makes those pillars concrete. Where the public discourse stops at “add a verifier,” Enclavia ships the governed workspace from Section 6 as the platform itself. The mapping is one-to-one.

### The Shephard system as a loop-control plane

Enclavia’s Shephard system is, structurally, a loop engine with governance built in rather than bolted on: Loop-engineering requirement Enclavia component What it delivers Discovery + handoff + scheduling Meta-Agent (planner/router) +

## Meta-Meta-Agent (hardware

allocator) Plans work, routes each task to the right worker, and allocates the right hardware — discovery and handoff as a managed control plane, not ad-hoc cron. Generator/evaluator separation Local-first worker pool (38 purpose-built agents) + Drift Monitor Distinct maker and checker roles; the Drift Monitor adds a quantitative skeptic — token-distribution variance, hidden-state entropy vs. baseline, and semanticrepetition signals catch the “no measurable progress” failure the circuit breaker needs.

Persistence / memory Governed RAG + durable state,

## Zero Data Retention boundary

State and evidence persist under policy; sensitive context is retrievable without leaking to a third-party model. Connectors as privilege surface OPA-enforced governance over tool/connector calls Every connector action is checked against policy-ascode (Open Policy Agent) before it executes — leastprivilege writes and deterministic gates from Section 6.

Trust over time Trust scoring: new = (α·reward) + ((1−α)·current), α=0.15 Worker reliability is tracked as an exponentiallyweighted score, so routing favors agents with demonstrated verified outcomes — a direct control on verification debt and cognitive surrender.

### Mapping the four costs to platform controls

- Verification debt → enforced generator/evaluator separation across the worker pool, with the Drift

Monitor as an execution-grounded skeptic and OPA gates on irreversible actions.

- Comprehension rot → governed RAG and durable audit keep loop-authored work legible and

attributable; human-gate policy enforces a recorded judgment before merge/deploy.

- Cognitive surrender → trust scoring and tamper-evident logs make rubber-stamping visible and

measurable instead of invisible.

- Token blowout → hybrid local-first routing keeps ~85–95% of inference on local compute with

frontier-API fallback only when justified; the Drift Monitor’s no-progress signals drive budget circuitbreakers. This is the structural answer to the cost the whole field is worried about.

### Why sovereignty is the decisive differentiator for loops

The economic argument Your Data · Your AI · Your Way 13 © 2026 Enclavia.ai · Confidential Loop engineering drives generation toward free, then multiplies it by a scheduler. Run that against metered frontier APIs and token blowout is not a tail risk — it is the expected case. Frontier API pricing is widely viewed as VC- and hyperscaler-subsidized; analysts flag material upward normalization within 12–24 months. A loop architecture that assumes cheap tokens forever is a balance-sheet liability. Enclavia’s local-first routing makes the marginal cost of an extra loop cycle a known, owned quantity rather than a metered surprise.

The control argument The four governance properties that make a loop safe — scoped identity, least-privilege writes, tamper-evident audit, deterministic policy — are model-independent and belong in the infrastructure. For healthcare (HIPAA/HITECH/21 CFR Part 11), federal, and air-gapped environments, a loop that egresses regulated context to a third-party cloud every cycle is a non-starter. Enclavia’s AI-in-a-Box supports fully disconnected operation, and Governance-as-a-Service makes the policy layer itself a product. Where the loop executes, under whose identity, and against what policy is the compliance boundary — and Enclavia owns that boundary on the customer’s behalf.

### The one-line position

The industry just discovered that the loop — not the prompt and not the model — is the unit of leverage. Enclavia.ai is the platform that makes the loop sovereign, governed, and economically bounded: generation is cheap, judgment is enforced, tokens are owned, and control of the loop stays with the customer. Your Data · Your AI · Your Way — now applied to the autonomous loop itself.

Enclavia platform capabilities (Shephard system, Drift Monitor, hybrid local-first routing, ZDR, OPA governance, trust scoring, AI-in-a-Box, GaaS) are vendor-stated Enclavia.ai architecture. Token-subsidy normalization (12–24 months) is an analyst-cited forecast, not a benchmarked figure. Loop-engineering requirements per Sections 2–6.

Your Data · Your AI · Your Way 14 © 2026 Enclavia.ai · Confidential

- Conclusion: Generation Is Free, Judgment Is the Asset

Loop engineering is a genuine layer change, not a rebranding. It moves the engineer from issuing prompts to designing the autonomous system that issues them, and in doing so it collapses the marginal cost of generation while leaving the cost of judgment untouched. Every durable claim in the corpus reduces to one asymmetry: the loop makes producing code nearly free and makes deciding what to keep the scarce, expensive, human-owned resource.

For research scientists and platform teams the practical implications are sharp:

- Build the generator/evaluator separation in from day one — and make the evaluator run the artifact,

not read it.

- Instrument the four silent costs as live metrics; a loop without a budget policy has no stopping

condition, only a failure mode.

- Spend your reliability budget on deterministic gates and constraints, not on a larger model; distilland-demote repetitive steps out of the LLM.
- Treat the loop as a privileged actor and wrap it in a governed workspace: scoped identity, leastprivilege writes, tamper-evident audit, deterministic policy, budget breakers, fast rollback.
- Decide where the loop executes as a compliance and economics decision, not a convenience one.

These requirements are, in aggregate, an argument for sovereign, governed, model-independent infrastructure — the layer where the loop is owned rather than rented. That is the layer Enclavia.ai builds. The same loop, in two pairs of hands, yields opposite outcomes. The platform’s job is to make the good outcome the default: cheap generation, enforced judgment, owned economics, and uncompromised control of the loop.

## About Enclavia.ai

Enclavia.ai is a sovereign AI infrastructure platform — Your Data · Your AI · Your Way — built on data, model, architecture, and compute sovereignty. Through the Shephard system, hybrid local-first routing, Zero Data Retention, OPA-enforced governance, governed RAG, multi-LLM portability, AI-in-a-Box disconnected deployment, and Governance-as-a-Service, Enclavia lets technology leaders in regulated industries run autonomous agent loops they can prove they control.

Dev Roy · CEO & Co-Founder · Enclavia.ai · Fairfax, Virginia · June 2026 Your Data · Your AI · Your Way 15 © 2026 Enclavia.ai · Confidential