Docs / What is loop engineering?

Article · Definition

What is loop engineering in AI

Loop engineering is the practice of designing the system that prompts an AI agent — the triggers, tools, stopping conditions, gates, and verification steps that run around the model call — instead of writing the prompt itself. It is what Marily Nika named as "your new job" in mid-2026 and what Addy Osmani, LangChain, and Prefect have since converged on: the human's role in the age of capable agents is not to talk to the model, it is to build the harness that talks to the model on a schedule, checks the output, and knows when to stop. This page defines the term, walks the stack it sits inside, separates it from the two neighbours it is most often confused with — graph engineering and harness engineering — and names where the frame is oversold.

Where the term came from — and why it stuck this quarter

The phrase surfaced in mid-2026 in two independent places within a few weeks of each other. In June 2026 Marily Nika published "Prompt Engineering Is Dead" and its follow-up "Loop engineering is your new job: how to design for silence," arguing that PMs and builders working with agents now design autonomous systems — with explicit stopping conditions, tool audits, context budgets, and human-interrupt stakes — because vague goals make agents loop forever.¹ Around the same time, Addy Osmani's "Loop Engineering" essay landed the same idea from the coding-agent side, with two quotes that carried the frame across the industry: Peter Steinberger's "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents," and Boris Cherny's (head of Claude Code) "I don't prompt Claude anymore… my job is to write loops."²

What made those posts stick is that they weren't naming a new capability — the loop primitive had been there since ReAct and AutoGPT — they were naming a shift in whose job it is. Prompt engineering asked a human to write the best possible instruction for one call. Loop engineering asks a human to build the system that decides when to call the model, with what context, against which check, and when to stop. The centre of gravity moved from the prompt string to the runtime around it.

Prompt engineering vs loop engineering (the stack)

By late 2026 the industry has settled on a stack for what an agent is actually running, and the two layers this piece cares about sit on top of two older layers people still confuse them with:

• Prompt engineering is the craft of the single instruction the model sees on one call. It still matters — the string that reaches the model is still the string — but it is one line of one call in a much longer runtime.
• Context engineering is assembling what the model sees on every call: retrieval, memory, tool definitions, prior state, task framing. This layer became the SERP darling in early 2026 because it is where the biggest lifts live.
• Harness engineering is the runtime around one agent — the tools it can call, the permissions, the state it can read and write between turns, what survives after the session ends. This is the layer ttoss argues you should invest in first, before either loops or graphs, because it is where the cheapest wins live.³
• Loop engineering is the system that runs the whole thing on a schedule or a trigger, checks the output against evidence, decides whether to iterate, escalate, or stop, and hands off to a human when taste is needed. It is the layer that turns "a good prompt" into "a shipped outcome."

The honest way to see the difference from prompt engineering is not replacement — it is containment. Prompt engineering is one line in a loop-engineered system. A team that only does prompt engineering has one long conversation with a model. A team that does loop engineering has a system that runs many short conversations on its own, checks each one, and pings a human on the ones that need judgment. Where prompt engineering asks what should I say, loop engineering asks what should run, when, against which check, and when should it stop.

Loop engineering vs graph engineering: same idea, two words

The most common source of confusion in the 2026 discourse is whether "graph engineering" (LangChain, Prefect) is a different thing from loop engineering. LangChain's 3 Years of Graph Engineering with LangGraph cites David Khourshid on the point: an agent loop is the simplest directed cyclic graph. LangChain's own framing in the same post is that graph engineering, loop engineering, and harness engineering are three names circling one idea — the runtime around the model call.⁴ Production agent graphs are not DAGs, because agents need cycles: retry, ask user, revise, pause for a human, resume. Most teams that think they are running a linear loop are actually already running a graph — Claude Code's sub-agent fan-out is one, LangGraph's checkpointed state machine is another.

Prefect's Jeremiah Lowin traces the progression as one continuous line: prompt engineering → multi-prompt scripts → loop engineering → graph engineering — where a "directed agentic graph" is a loop whose nodes are parameterised and whose transitions are explicit, aimed at reproducibility rather than a new capability.⁵ The Graph Harness scheduler survey puts numbers on it: across the systems it categorised, Agent Loop was the dominant scheduler pattern at roughly 60%, event-driven at ~15%, state-machine at ~10%, graph/flow at ~5%, hybrid at ~10%.⁶ The takeaway is that most of what "graph engineering" advocates propose is graph vocabulary for a loop that was already there.

The practical read: loop-vs-graph is a terminology choice at the same layer, not a capability gap. Framework marketing that presents graphs as a replacement for loops is what Prefect calls the tendency to "boil powerful ideas down to the dumbest version." The interesting question is not whether to call your system a loop or a graph — it is whether the primitives underneath (stopping conditions, human gates, durable memory, sub-agents, MCP connectors) are explicit and reproducible.

Loop engineering vs harness engineering: the three-layer decomposition

The most useful engineering counterpoint to the loop discourse is ttoss's August 2026 essay You Probably Don't Need a Graph, which decomposes the runtime into three layers you can attribute failure to independently:³

• Harness — the environment one agent runs in: tools, memory, permissions, what survives between sessions.
• Loop — the feedback cycle: how work is checked, when it iterates, when it stops.
• Graph — the explicit topology: which step is next, what runs in parallel, where the mandatory human gate lives.

The diagnostic move — attribute a failure to a layer before you fix it — is the single most useful idea in the current writing on this topic. A hallucination on a tool call is usually a harness problem (wrong tool, wrong permissions, wrong context). A run that never terminates is a loop problem (no stopping condition, no evidence-based check). A pipeline that skips the wrong step is a graph problem (topology, not iteration).

The corresponding investment order — harness first, loop second, graph last — is a direct challenge to the framework-first temptation. Cheap harness wins come from Tool Minimalism: fewer, atomic tools, deletion is often the highest-leverage move. Loop wins come from a simple rule: do not loop on confidence, loop on evidence — tests passing, schema validating, citations resolving, an output the checker can verify. Not "the agent says it's done."

Two loop failure modes are worth naming because they show up in every long-horizon deployment:

1. Cost-leak loops — no ceiling. A loop without a success predicate, a budget, and an escalation path will burn compute until something else stops it. "Bounded iteration" is the name to know: every loop needs a max-step count, a token/dollar budget, and a named escalation pathway when either trips.
2. Proxy collapse — a loop that runs long enough starts optimising for its checker rather than the actual outcome. The gradient, as ttoss puts it, "points at green, not at correct." The mitigation is not a better checker — checkers are always Goodhart-able — it is a human gate on the taste decision, on a schedule the human is actually going to keep.

And the corollary: a graph earns its place only when properties of the process require it, not properties of the model. Those properties are a mandatory human gate that must be enforced rather than requested, an audit requirement, expensive parallel stages with deterministic joins, and durable resumption (interrupt at hour six, restart at step nine). Where those properties are absent, a well-designed loop is enough. Where they are present, the graph is doing real work that no amount of prompting will do for you.

The horizontal primitives every loop-engineered system uses

Across Claude Code, Codex, and self-hosted stacks, the same six primitives show up in every loop worth shipping. Osmani's essay mapped five of them 1:1 across the two major coding agents, and the pattern generalises to non-code work:²

• Scheduled or event triggers. The loop fires on a schedule, an inbox event, a metric threshold, or a state change — not on a human typing a prompt.
• Sub-agents. A parent agent fans out narrower work to purpose-scoped sub-agents with their own context windows, so parallelism and isolation are safe.
• Skills or worktrees. Named, reusable units of work an agent can invoke (SKILL.md files, worktree templates), rather than reinventing the same instruction each run.
• MCP connectors. A shared tool surface an agent can call across integrations (Slack, GitHub, PostHog, a database) — the MCP-native workspace design pattern is what makes this reusable across model vendors.
• Durable memory outside the model's context. "The agent forgets, the repo doesn't." State that has to survive across handoffs lives in a typed store — a repo, a graph, a database — not in the context window. This is the primitive the stateful orchestration substrate piece unpacks in detail.
• A human gate on taste decisions. Not human review of every step — a scheduled, named interrupt where the human sets direction, approves a bet, or accepts a shipped outcome. Chase's notify / question / review interrupt taxonomy at LangChain is the cleanest published version of this.

Osmani's phrase for the effect is the memorable one: "the agent forgets, the repo doesn't." Loop engineering is largely the discipline of choosing which primitives to make first-class in the surface your team actually touches — because the primitives are universal, but the wrapper product is where teams either buy or build.

Silence and stopping conditions: the real design frontier

Nika's follow-up post named the sharpest edge of the whole practice: designing for silence. A prompt-engineered call finishes when the model finishes generating. A loop-engineered system has to know when to stop — and "the agent decided it was done" is not a stopping condition, because agents that never stop and agents that stop too early both cost real money.

The reason "let the model self-diagnose the stop" is a bad plan is that the model is not a reliable judge of its own run. This is the same failure mode the observability literature has been pointing at for two years — long agent trajectories are hard for anything, including the model that produced them, to reason about after the fact. A design that assumes the model will self-check its way to a stop is a design that will silently drift.

The stopping-condition literature and the controllability/safety writing have quietly converged on the same three moves:

• Interruptibility as the backstop. OpenAI's Practices for Governing Agentic AI Systems argues periodic time-outs until a human reauthorizes are the critical last defence when everything else fails.⁷
• Controllability, not just alignment. The CONTROLBENCH work argues alignment is not enough — authority, runtime monitoring, intervention, and audit are the last line of defence against a loop that has learned to pass its own tests.⁸
• Bounded iteration + mandatory human gate. The Springer survey on controllability in agentic AI names three oversight levels (guardrails, adaptive control, agent-in-the-loop) and lands on the same recommendation: HITL adds the normative authority no constraint can internalise.⁹

A loop-engineered system that ships with an explicit stopping condition, a bounded step/budget cap, and a named human gate is what the governance literature calls a controllable agent. One that doesn't is what your finance team calls next month's bill.

Where the loop-engineering frame is oversold

The frame is genuinely useful, and it's still oversold in ways worth naming — because a piece that only sells the frame will not survive contact with a shipped system. The honest limits:

• It's a coding-agent-first idea, retrofitted to everything else. Almost every worked example in the 2026 corpus — Osmani's essay, the Steinberger and Cherny quotes, the Ralph loop, the "harness first" argument — comes from the coding agent world, where a repo, a test suite, and a CI signal give you unambiguous evidence for the loop to close on. Knowledge-work loops (customer feedback, competitor intel, sales notes, roadmap synthesis) don't have that. There is often no test suite, no schema validation, no green/red signal that says "this loop can stop now." The frame transfers, but the evidence layer it depends on has to be built by hand, and the SERP largely doesn't cover that.
• A well-loop-engineered system can still fail on a bad harness or a bad model. Bounded iteration + human gate + evidence-based stop is a real discipline, and none of it rescues a loop wired to the wrong tools, running on a model that isn't strong enough for the reasoning, or drawing from stale context. Loop engineering is the layer that decides when to run and when to stop; it is not the layer that decides what the agent can do. Treating "we have a stopping condition" as a substitute for "we have the right tools and enough model" is the most common mis-adoption of the frame.
• The three-layer diagnostic is cleaner in an essay than in production. "Attribute the failure to a layer before you fix it" is a beautiful heuristic. Real failures cross layers: a run that never terminates might be a stopping-condition problem and a bad tool that keeps returning "try again" and a missing capability the agent is silently working around. Teams that mistake the diagnostic for a checklist end up fixing the wrong layer in confidence. The diagnostic is a lens, not a bisection algorithm.
• Human gates decay when the human stops showing up. The mitigation for proxy collapse — put a human on the taste decision, on a schedule they'll keep — is only as strong as the schedule. In every long-running deployment worth watching, the human gate is where the discipline erodes: approvals get batched, then rubber-stamped, then skipped. The literature is quiet on this because it's an operator problem, not a research one, but any team taking loop engineering seriously has to design the review cadence with the same care it designs the loop, and accept that it will still soften over time.
• "The primitives are universal" is aspirational, not observed. MCP is real and its adoption is genuine, but connector quality varies wildly, sub-agent frameworks are on different maturity curves, and "durable memory outside the model's context" means something concrete in Claude Code and something much fuzzier in most other stacks. The pattern generalises; the interop does not, yet.

None of that unmakes the frame — it just moves it from doctrine to discipline. A loop engineer who takes the limits seriously ships a system that survives its own users; one who doesn't ships a demo.

Maskin: loops as first-class workspace objects

All of the above is what Maskin's loop object type expresses at the workspace layer. A Maskin loop is a typed object with a trigger (schedule or event), steps (each an agent invocation with its own prompt, model, and MCP tool surface), a close condition, and named human gates where the loop pauses for taste. The trigger is the entry edge; the steps are the nodes; the close condition is the termination; the human gate is a first-class transition, not a hope.

The reason to shape a loop as an object rather than a script is that it lives in the same graph as the work it produces. An insight fires a loop; the loop opens a bet; a step on the bet produces a task; the task closes with evidence written back to the object. The whole path is inspectable, the audit trail is the object graph's own history, and swapping the model on one step is a metadata change, not a rewrite. The agentic workspace cornerstone covers the shape from the workspace side, bet vs backlog covers the object model shift, and ambient agent workspace covers the UX camp the loop-object sits inside.

The practical corollary of taking loop engineering seriously is that most of what a serious team needs — durable memory, HITL gates, MCP connectors, reproducible sub-agent fan-out, close conditions on state — is productisable rather than codable. That is the wager Maskin makes: loop-vs-graph is a terminology choice, harness/loop/graph is an investment order, and the primitives underneath are horizontal enough that a team should not be rebuilding them per vertical.

FAQ

What is loop engineering in one sentence?

Loop engineering is the practice of designing the system that runs an AI agent — trigger, tools, context, checker, stopping condition, human gate — instead of writing the prompt the agent will use on any one call. The industry's short version, coined by Peter Steinberger and popularised by Addy Osmani, is that you stop prompting the agent and start designing the loops that prompt the agent.²

Is loop engineering the same as prompt engineering?

No — loop engineering contains prompt engineering. Prompt engineering is a craft of the single string that reaches the model on one call; loop engineering is the design of the runtime that decides when to call the model, with which context, against which check, and when to stop. A well-loop-engineered system still has good prompts inside it. It also has the harness, memory, and stopping condition around them.

What's the difference between loop engineering and graph engineering?

At the runtime layer, none in kind — an agent loop is the simplest directed cyclic graph, per David Khourshid and LangChain.⁴ "Graph engineering" is what you call it when the topology becomes explicit enough that reproducibility and durable resumption become the point; "loop engineering" is what you call it when the emphasis is on the feedback cycle and the stopping condition. Production agent graphs are not DAGs because agents need cycles; framework marketing that presents graphs as a replacement for loops is renaming, not replacing.

What's the difference between loop engineering and harness engineering?

The cleanest decomposition, from ttoss's August 2026 piece, is three layers: harness (one agent's environment — tools, memory, permissions), loop (the feedback cycle around one agent — checking, iterating, stopping), and graph (explicit topology across many agents).³ The investment order that essay defends — harness first, loop second, graph last — is the honest engineering read: most "we need a graph" conversations should have been "we need a better harness" or "we need a real stopping condition."

Do I need a framework (LangGraph, CrewAI, Temporal) to do loop engineering?

No — you need the primitives (trigger, tools, memory, checker, stopping condition, human gate). Frameworks package those primitives with different trade-offs: LangGraph gives you a typed state graph with checkpointing and HITL; CrewAI gives you role-based collaboration and fast prototyping; Temporal gives you durable execution with a strong audit log. Any of them is a legitimate substrate, and none is required — you can loop-engineer with a scheduler, a tool-calling model, and a database. The decision is whether the primitives are explicit and reproducible, not whether the runtime carries a specific brand.

When should I not reach for a loop?

When a single call, a single deterministic script, or a single verb-surface command does the job. A loop earns its overhead once the work is iterative, has a checkable stopping condition, or spans a duration where the user won't wait synchronously. If your task is "summarise this document," you don't need a loop. If your task is "scan every new customer complaint, cluster them, and open a bet when one crosses threshold," you do.

Where does loop engineering fall short?

Three places worth flagging. First, the evidence layer knowledge-work loops depend on has to be built by hand — there is no test suite or CI signal for "did the competitor-intel loop find the right thing?" the way there is for a code loop. Second, a stopping condition doesn't rescue a bad harness or a weak model; loop engineering is only the layer that decides when to run and when to stop. Third, the human gate is the discipline that erodes first — approvals get batched, then skipped — so the review cadence has to be designed with the same care as the loop itself.

Who coined loop engineering?

The phrase surfaced in independent places within weeks of each other in mid-2026. Marily Nika's June–July 2026 posts ("Prompt Engineering Is Dead" → "Loop engineering is your new job") named the shift from the PM side.¹ Addy Osmani's "Loop Engineering" essay named it from the coding-agent side, with quotes from Peter Steinberger and Boris Cherny that carried it into practitioner discourse.² LangChain and Prefect then wired it into the graph-engineering literature.⁴⁵

Own the loop, not the prompt

If the frame lands — the human's job is the system that prompts the agent, not the prompt itself — the shape of the tool you want is a workspace where the loop, the tools, the memory, the stopping condition, and the human gate all live as typed objects you can inspect, swap, and hand off. That is what Maskin is: an open-source, MCP-native, self-hostable workspace where loops are first-class objects a team configures rather than code an engineer writes. Self-host free forever under Apache 2.0, or start a hosted trial with EU/US data residency.

Sources

1. Marily Nika, Prompt Engineering Is Dead (2026-06-22) and Loop engineering is your new job: how to design for silence (2026-07-01), AI Product Academy on Substack. The PM-side framing of the shift from prompt to loop and the "design for silence" thesis on stopping conditions.
2. Addy Osmani, Loop Engineering (Jun 2026), addyosmani.com/blog/loop-engineering. The coding-agent-side framing plus the Peter Steinberger and Boris Cherny quotes that carried the term into practitioner discourse. Includes the primitives mapping across Claude Code and Codex and the durable-memory-outside-the-conversation principle.
3. ttoss, You Probably Don't Need a Graph (2026-08-08), ttoss.dev/blog/2026/08/08/you-probably-dont-need-a-graph. The three-layer harness/loop/graph decomposition, the harness-first investment order, Tool Minimalism, and the "loop on evidence, not confidence" rule. Also the source for the two loop failure modes named here (cost-leak loops, proxy collapse).
4. Harrison Chase / LangChain, 3 Years of Graph Engineering with LangGraph, langchain.com/blog/3-years-of-graph-engineering-with-langgraph. David Khourshid's line that an agent loop is the simplest directed cyclic graph, and LangChain's framing that graph, loop, and harness engineering are three names for the same runtime layer.
5. Jeremiah Lowin / Prefect, Loops vs. graphs (Jul 2026), prefect.io/blog/loops-vs-graphs. The progression prompt → multi-prompt → loop → graph, the "directed agentic graph" framing, and the caveat that some of the "death of loops" wave is marketing relabeling (the Ralph loop being the exhibit A).
6. Hu Wei et al., Graph Harness (position paper), arXiv 2604.11378. The scheduler-continuum survey with the ~60% / 15% / 10% / 5% / 10% breakdown across Agent Loop, event-driven, state-machine, graph/flow, and hybrid schedulers.
7. OpenAI, Practices for Governing Agentic AI Systems, cdn.openai.com/papers/practices-for-governing-agentic-ai-systems.pdf. Interruptibility as the critical backstop, periodic time-outs until a human reauthorises, HITL approval for irreversible actions.
8. Li, Feng, Sun, AI Safety Requires Effective Controllability (CONTROLBENCH), arXiv 2605.27117. The controllability-not-alignment argument: authority, runtime monitoring, intervention, and audit as the last line of defence.
9. On Controllability in Agentic AI: A Survey, Minds and Machines (Springer). Three oversight levels (guardrails, adaptive control, agent-in-the-loop) and the HITL-normative-authority argument.