Loop Engineering Is the Executive Function Your Model Lacks

Ask a coding agent to state the rule and it will state it perfectly. Never touch the public API. Always run the suite before opening a pull request. Escalate anything that changes deployment config. It recites the constraint back to you with the calm fluency of a model that has understood completely. Then, eleven minutes into a long task, with the context window full of tool output and half-finished reasoning, it edits the public API, skips the tests, and ships.

This is not a storage failure. The rule was never lost — interrupt the run and ask, and the model recites it again, flawlessly. Nor is it a comprehension failure. It is a failure to enact a goal that is known, present, and momentarily outcompeted by everything else pulling at the next token. The instruction is still in the context. It has simply stopped controlling the output.

Cognitive neuroscience named this long before the transformer existed. It is called goal neglect: the disregard of a task requirement that has been understood and remembered. John Duncan's group spent decades documenting it in the study of frontal-lobe function and fluid intelligence — the gap between knowing what to do and doing it, widening precisely as a task grows richer and the relevant goal has to fight to keep control. Patients with executive impairment show it. Healthy people under load show it. Long-running agents show something uncomfortably close. The mechanism is not the same; the failure looks the same, and — this is the part that matters — the fix is the same.

In the classic account of cognitive control, executive function is not a store of rules. It is the machinery that keeps the currently relevant rule causally active. Miller and Cohen described prefrontal control as the active maintenance of goal representations that bias activity everywhere else in the system towards task-appropriate behaviour. That is the missing ingredient in a long-running agent: not the ability to state the rule, but the ability to keep the rule exerting force while tool output, local subgoals, error messages, and seductive partial solutions compete for the next action. A model that can recite the constraint but not stay governed by it does not have a knowledge problem. It has a control problem.

This is the most useful lens on the discipline now forming around agents — the one Addy Osmani and others have started calling loop engineering. Strip away the tooling and a loop is one thing: external executive function for a system with formidable local cognition and no reliable supervisory control of its own. The model can reason, plan, explain, and repair within a step. It cannot reliably hold a goal across a hundred of them. The loop is the supervisory layer the architecture never came with, and building it well is the entire job.

From prompt, to context, to loop

The first craft around language models was prompt engineering: how to ask for a useful next completion. The second was context engineering: what should be present — examples, tools, memories, policies, intermediate state — when the model is asked to act. Loop engineering is the third, and it asks a harder question than either. What recurrent system decides what the model sees, what it does, how its work is checked, what it keeps, when it retries, and when it must stop?

These are not rival disciplines. They are nested. Prompt engineering is local instruction — role, goal, constraints, schema, refusal boundaries. Context engineering generalises that to the whole window: task state, retrieved knowledge, tool definitions, prior decisions, compacted history. Anthropic frames it as configuring the finite set of tokens the model can attend to, so the highest-value information is present under hard limits on attention and cost. Loop engineering sits above both and makes the choice cyclical. It decides which state persists, which is discarded, which facts are re-read from source, which decisions are summarised, which artefacts are checked outside the model — and it makes that decision again, and again, every time the agent acts.

The cleanest way to say it: context engineering configures a moment; loop engineering governs the sequence of moments. And the sequence needs governing for exactly the reason goal neglect exists. Attention is finite. A goal that is merely present is not a goal that is in control. Over a long run, tool results, dead branches, stale plans, and irrelevant observations pile up, and the instruction that was perfectly clear at token zero becomes one faint signal among thousands. We have a fashionable name for this — context rot. It is goal neglect under accumulated load, and a larger context window no more cures it than a larger desk cures someone who keeps forgetting why they sat down.

Why this is control, not automation

A cron job runs a fixed procedure. A CI pipeline executes a fixed graph. Neither decides anything. A looped agent operates inside a bounded decision process: observe the state, assemble context, choose an action, execute through tools, read the result, update memory, and decide whether to continue, retry, escalate, roll back, or stop. That last clause is what makes it a control system rather than a script.

Treat the model honestly and it is a stochastic controller embedded in a larger engineered system — powerful, and not self-validating. It can infer and plan; it can also hallucinate progress, rationalise failure, overfit to the wrong signal, and burn budget until something interrupts it. A frontier model with no loop is cognition with no supervisor: brilliant within the step, unreliable across the task. Intelligence without control is not a lesser intelligence. It is an ungoverned one. The loop is where prompting, context, tools, evaluation, memory, cost, and permission stop being separate concerns and become one governable architecture.

The unit of work is the trajectory

One-shot prompting optimises an output. Loop engineering optimises a trajectory — a sequence of state transitions: issue selected, repository read, hypothesis formed, patch applied, tests run, failure interpreted, fix revised, reviewer invoked, pull request drafted, human notified. The artefact is not the patch. It is the path the system took to reach it.

Cognition is built the same way. One of the more durable ideas in cognitive science — event segmentation theory — holds that the mind does not take in continuous activity as an undifferentiated stream; it carves it into discrete events at boundaries where prediction, situation, or task structure shifts. Each segment is governed by a locally coherent event model: what is happening, what matters now, what to expect next. That is exactly the grain a good loop should have. An iteration is an attentional episode — one bounded unit of work, one re-asserted goal, a clean boundary at which state is checkpointed and the next goal is loaded. Loops fail when they refuse to segment, letting one enormous, goal-blurred episode run until the model has quietly stopped being governed by the task it started. The fix for context rot is rarely a bigger window. It is episodic structure: compact the trace, clear stale tool output, write durable notes, re-cue the goal, isolate the subproblem, and begin the next clean episode. A good loop does not remember everything. It remembers the right things, in the right form, at the right boundaries.

The messiness is the capacity

What a loop keeps is a representation, and a representation has a shape that decides how readily it rots. Cognitive neuroscience has something exact to say about that shape, and it is the part that looked like a recording error until it didn't. Rigotti and colleagues recorded prefrontal neurons while monkeys performed a task with several moving parts — which object was shown, where it fell in a sequence, which task was in force — and found that most cells refused to encode any of these cleanly. They fired for nonlinear mixtures: this cue at that position under this task, in combinations no single variable could predict. For a while that heterogeneity read as noise, the kind of messy tuning you average away to find the "real" signal. It is not noise. Nonlinear mixed selectivity lifts the task into a high-dimensional representation, and high dimensionality is exactly what lets a simple downstream readout carve an enormous number of distinct mappings out of the same population. That is the capacity, not a flaw in it. It is how one network does many things.

A transformer's internals are messy in the same load-bearing way. Its units are polysemantic — single neurons firing for unrelated things — and interpretability has had to learn the lesson Rigotti's recordings taught the neuroscientists: a distributed, mixed, individually-illegible code is not a defect to be tidied away but the price and the source of generality, the reason one fixed set of weights can take on an unfamiliar task from nothing but a prompt. The bill comes attached. Rigotti found that on error trials the representation collapsed — its dimensionality fell — so the very richness that supports complex behaviour is also what degrades when behaviour fails. A high-dimensional mixed code is expressive and fragile in the same breath. The flexibility that lets a model instantiate a novel task is the flexibility that lets the wrong variables bleed into the mixture as irrelevant context accumulates, until the representation of the task is no longer cleanly separable from everything packed in around it. That is context rot one level below the window: not tokens running out, but a task that has stopped being held distinct. It is the first thing a loop is for — not to scrub the messiness, which is doing the work, but to protect what the messiness is asked to mix, curating the inputs so the right combination stays legible to the readout.

A hierarchy of abstraction spaces

Curating the mixture keeps a task legible; it does not tell a system how to attack a problem too large to hold all at once. That is a question of structure, and the structure is older than the field's amnesia usually allows. In 1974, Earl Sacerdoti — then at SRI, in the robot-planning programme that had produced Shakey and STRIPS — described planning in a hierarchy of abstraction spaces. His planner, ABSTRIPS, never searched the full detailed problem at all: it assigned each precondition a criticality, built a skeleton plan in an abstraction space where the low-criticality detail was simply invisible, and only then refined that skeleton downward, space by space, introducing finer detail once the level above had already fixed the shape of the solution. Settle the structure where the search is small; let that structure constrain the search where it is large. The combinatorial payoff was the paper's headline result, and the principle outlived the program — almost every serious planner since is an elaboration of it.

The frontal lobe appears to have reached the same trick for the same reason. Cognitive control is built as a rostro-caudal abstraction hierarchy — anterior prefrontal cortex holding the abstract goal or task-set, posterior regions binding the concrete stimulus-response rule — and a novel task is prepared by running through that hierarchy rather than around it, the abstract level configured first and the detail filled in beneath it. Two systems that could not have copied each other, a 1974 planner and the primate prefrontal cortex, meet novelty the same way: plan abstractly, defer detail.

Loop engineering has not fully absorbed the lesson. A loop that runs at one grain — action after action, token after token — is exactly the flat search Sacerdoti abandoned more than fifty years ago. A serious loop is a hierarchy of abstraction spaces: its goal and milestones are the skeleton plan, settled in the top space where the search is cheap; the episodes beneath refine it downward, detail deferred by criticality, each a bounded unit of work the level above has already constrained; verification and re-cueing are applied where they bite, not uniformly across every step. The flat loop fails the way ABSTRIPS was built to avoid, and the way an overloaded frontal lobe fails a novel task — it drowns in detail it should not yet be looking at, and loses the shape of the goal in the noise. The model does not impose the hierarchy on itself. That is the loop's job.

Verification is the centre, and the centre is a dissociation

Without verification, a loop is an unattended hallucination machine with tools. The model's account of its own progress is not evidence; it is narration, and the model is a persuasive narrator of its own success. A loop that asks the same agent did you succeed? has built a mirror, not a verifier.

One of neuropsychology's sharpest instruments is the double dissociation: you show two functions are genuinely separable by finding that one can fail while the other stays intact, and the reverse. Loop engineering should steal the logic outright. Separate the maker from the checker on purpose. The agent that generates must not be the agent that approves; the function that proposes a change must be dissociated from the function that certifies it. Prefer deterministic checkers wherever they exist — tests, typecheckers, linters, schema validators, cost accounting, diff review — because a deterministic verifier cannot be charmed. Use an independent reviewer agent where judgement is unavoidable, but never mistake two agents agreeing for the truth; correlated models confabulate in chorus. The whole reliability of a loop rests on the integrity of the boundary between doing and checking. Engineer that boundary as deliberately as a neuropsychologist engineers a contrast.

This is why the best loop engineers will not be the people who write the most elaborate prompts. They will be the people who can define observable progress — who can turn "make this better" into a target, a set of constraints, a verification procedure, and an escalation rule, and who know exactly where the model should be creative and where it should be boxed in.

The anatomy of a loop

Executive function was never one faculty. The cognitive literature splits it into separable components — shifting between task sets, updating and monitoring working memory, inhibiting the wrong response — related but distinct. A serious loop decomposes the same way. It has at least eight control surfaces, and each is an executive function the model will not perform on itself.

A trigger — initiation. The loop begins because time passed, a ticket changed, a test failed, a message arrived, a deployment regressed, or a human gave a command. Claude Code's scheduled tasks and loop primitives show the direction of travel: prompts that recur on a schedule, poll for a condition, or run as persistent tasks.

An observation model — perception. The loop must know what it may inspect: repositories, CI logs, issue threads, dashboards, mail, databases, design files, external documents. Connectors are the agent's senses and hands; they fix what it can perceive and what it can change. Connector design is not an integration afterthought but the agent's epistemology, which is much of why a standard like MCP matters — it settles how a system reaches the world.

A context policy — selective attention. What enters the window at each step: system rules, relevant files, retrieved knowledge, prior decisions, tool schemas, examples, compacted state. Skills are one mechanism — a package of procedural instruction loaded only when the situation calls for it, so the model carries the right rules at the right moment instead of every rule in every prompt.

An action space — inhibition. The model must not be able to do everything. Bounded tools, scoped credentials, sandboxed execution, rate limits, explicit permission boundaries. A coding agent does not get production write access because it can fix a unit test. In a loop, permissions are not only a security control; they are a constraint on behaviour — the inhibition the model does not supply for itself.

Isolation — the task-set and transaction boundary. Worktrees, sandboxes, branches, containers let multiple agents or multiple hypotheses proceed without corrupting shared state. Parallel agent work without isolation is non-deterministic in the worst sense: agents overwrite each other, tests stop meaning anything, and rollback becomes a guess.

Role separation — functional dissociation. Subagents are not a multiplication of intelligence; their value is context isolation and adversarial specialisation. One generates, another reviews; one searches, another synthesises; one patches, another inspects the diff against house style. Each spends its own token budget — parallel minds are not free.

Memory — working-state externalisation. External state stops each run from being amnesic and stops the raw transcript from being the only record. Good loop memory is structured, sparse, inspectable: decisions made, facts verified, commands run, files touched, assumptions still open, failures hit, reasons for stopping. Bad loop memory is a heap of summaries nobody trusts.

Brakes — inhibitory control and a stopping policy, the part everyone discovers last and regrets skipping. Iteration limits, budget limits, no-progress detection, retry caps, timeouts, escalation paths, human approval gates. The economics are already real enough that large firms are installing brakes: reporting on Uber's AI-tool spend, citing Bloomberg, described a per-employee monthly cap on agentic coding tools imposed after the budget burned through unusually fast. A loop without brakes does not converge. It spends.

Two further functions sit above those eight and watch the loop itself. Verification is performance monitoring: not "is this artefact correct?" alone, but "are we making progress, are we stuck, is the verifier strong enough, is the cost still justified?" Escalation is meta-control: the decision to stop optimising and hand judgement back to a human. Put the whole machine on one page, and the mapping is the argument.

None of these is exotic. Each is a function brains evolved to impose on their own cognition — and not one a language model performs reliably for itself.

A short lineage

Loop engineering did not appear from nothing in mid-2026. The loops were always there; what changed is that they became products, and then became load-bearing. ReAct made the reasoning–action–observation pattern explicit: interleave thought with action against an environment, and let each observation update the next step. Reflexion added verbal self-feedback stored as memory and reused across attempts without touching the weights. Voyager pushed the idea into a long-horizon world, pairing an automatic curriculum with a growing library of reusable skills. AutoGPT popularised autonomous agents running open-ended workflows — stronger as a demonstration than as a dependable system, but it set the expectation. Read in sequence, these are early, crude attempts to bolt supervisory control onto a capable model from the outside. Anthropic's own work on long-running agent harnesses states the lesson plainly: a high-level goal plus a frontier model is usually not enough, because the agent loses context and guesses when uncertain, and needs a harness that preserves useful state while allowing incremental progress. Loop engineering is the engineering response to that exact failure.

Generate, criticise, optimise — and the amplifier problem

The most telling pattern in the recent research is not any single paper; it is a control topology that keeps reappearing: a generator, a critic, a memory, an update. Proposals are made, measured, criticised, revised, and tried again, with critique acting as something like a textual gradient. The principle underneath should reorganise how people think about reliability: an unreliable one-shot model can be made into a reliable system by embedding it in a measurement-rich loop. Recurrence plus external signal compensates for a great deal of single-shot noise.

But the same property has a sharp edge. A loop amplifies whatever signal it is given. Weak verifier, and the loop learns to satisfy weak verification. Misspecified goal, and it optimises the wrong thing with great diligence. Invisible cost, and it spends until interrupted. Poisoned context, and it propagates the poison faithfully into every iteration. A loop is an amplifier, not a moral agent, and it will magnify your judgement and your mistakes with precisely the same enthusiasm.

The failure modes are control failures

Every way a loop breaks has a recognisable signature in the cognitive-control literature.

Vague success is goal underspecification. "Improve the codebase," "make the UI better," "clean this up" are not goals; they are invitations to unbounded search. A loop goal needs an observable terminal condition — the suite passes, the benchmark clears a threshold, the migration completes on sample data, the open-issue count reaches zero, the reviewer has no blocking findings.

Self-report is confabulation. The agent will give you a coherent story about its own progress whether or not the progress occurred. Trust the deterministic check, not the narrative.

Context decay is goal neglect under load — the failure this essay opened on. The answer is not a bigger window but better episodic structure: compact, clear, externalise, re-cue, segment.

Runaway cost is the absence of inhibition. Agentic systems have heavy-tailed spend because they can always ask, search, test, rewrite, and delegate once more. Budgets are first-class design parameters, not a finance problem discovered after the invoice.

Privilege drift is blast-radius creep. A loop that starts as a harmless assistant quietly accrues access to repositories, trackers, calendars, documents, and credentials. Least privilege, scoped tokens, approval gates for irreversible actions, traceable tool use.

Cognitive surrender is the human cost. Osmani's own warning is the one to take most seriously: a loop can keep producing useful artefacts while the people responsible for it slowly stop understanding how those artefacts are produced. The answer is not to abandon loops but to insist on legible traces, reviewable diffs, explicit assumptions, and human checkpoints exactly where judgement matters — to keep a mind in the loop that still understands the loop.

A loop contract

A mature loop does not begin with a prompt. It begins with a contract — the specification of the supervisory control you are imposing from outside. It states the goal in verifiable terms. It names the authorised observations. It bounds the action space. It sets the context policy: which skills to load, which memory to read, which state to write, when to compact. It defines the verifier — commands, tests, reviewers, schemas, evidence. It sets budgets in tokens, money, wall-clock, iterations, retries, and subagents. It defines escalation: the conditions under which the loop must stop and hand judgement back. And it defines the trace: what must be recorded so the run can be audited afterwards.

A minimal one reads like this:

Goal:
  Resolve issue #184 without changing public API behaviour.
Observations:
  Read repository, issue thread, failing CI logs, existing tests.
Actions:
  May edit source and tests in a disposable worktree.
  May run tests and static checks.
  May not push, merge, alter secrets, or change deployment config.
Context:
  Load coding-standards skill and test-strategy skill.
  Maintain state.md: hypotheses, commands, failures, decisions.
Verifier:
  Unit tests pass. Typecheck passes.
  No unrelated files changed.
  Independent reviewer agent finds no blocking regression risk.
Budgets:
  Max 3 implementation attempts. Max 2 reviewer cycles.
  Max 60 minutes wall-clock equivalent.
  Stop if the same test fails twice without a new hypothesis.
Escalation:
  If API behaviour is underspecified, stop and ask for a human decision.
Output:
  Patch summary, commands run, evidence, risks, open questions.

That is the whole distance between prompting the agent and engineering the loop. The contract specifies not only what the agent should do, but how the system will know whether it is still usefully doing it — and the moment its known goal has quietly slipped out of control.

Why it matters

Loop engineering reframes agentic AI from a conversation problem into a control problem, and the reframing is overdue. The field spent years improving the local interaction — better prompts, better exemplars, better system messages, better retrieval, better tool descriptions. All of it still matters. But the moment an agent works across hours, repositories, tickets, and teams, the single prompt stops being the meaningful design unit. The loop becomes the unit, and the loop is a control system whether or not anyone designed it as one.

The best loop is not the most autonomous loop; it is the loop with the right autonomy. The distinction is old: routine action can run on its own, but non-routine action needs a supervisor to bias, inhibit, and reconfigure it. Bounded, verifiable work should run unattended — triaging logs, refreshing snapshots, reproducing failing tests, drafting first-pass diffs, gathering source-backed research. Work whose evaluation function is ambiguous, political, aesthetic, or strategically consequential should stay human-led. Knowing which is which — what to automate, what to instrument, what to constrain, and what to keep outside the loop entirely — is the discipline's central act of judgement.

None of this is unprecedented. Cybernetics, control theory, software reliability, and cognitive neuroscience have circled the same insight from different sides: raw capability is not the bottleneck; control is. A mind solved this with executive function — a system that holds a goal, segments activity into episodes, inhibits the wrong response, monitors performance, and steps in when things drift. We did not give our models any of that. Loop engineering is how we supply it from outside.

So the future belongs less to the person who can coax a clever answer out of a model, and more to the person who can build the control the model lacks — who can take uncertain, distractible, formidable cognition and wrap it in a structure that holds a goal, checks its own work, spends within its means, and fails gracefully. We have a forty-year map of this exact failure, drawn from minds that know the rule and still fail to act on it. Loop engineering is the attempt to build, outside the model, the architecture that keeps the rule in force.