Loop Engineering
For the last couple of years, the core skill in working with AI was writing a good prompt. You'd craft careful instructions, send them off, read the response, and decide what to ask next. You were the loop — the human sitting between every action the model took.
That's starting to change. As models have gotten reliably good at using tools, reading their own output, and correcting course, the interesting engineering problem has moved up a level. It's no longer just "what do I say to the model right now?" It's "what system keeps this agent moving toward a goal, on its own, without me typing the next instruction?"
That discipline has a name now: loop engineering. This article walks through what it actually means — from the vocabulary that surrounds it, to the anatomy of a single loop, to the building blocks you assemble one out of, to the different kinds of loops that show up in production systems.
1. Prompt Engineering, Context Engineering, Harness Engineering, and Loop Engineering
These four terms get used almost interchangeably in casual conversation, but they describe different layers of the same stack. It helps to think of them as concentric circles, each one wrapping around the last.
Figure 1.1 The four layers of AI engineering, with loop engineering forming the outermost layer.
Prompt engineering is the practice of shaping the words you send to a model to get a better single response. It's about phrasing, examples, formatting, and instructions for one turn of conversation. A good prompt fixes that one exchange — it says nothing about what happens next, when the task is actually done, or who checks the work.
Context engineering is the practice of deciding what information the model actually sees at any given moment — not just the instruction, but the surrounding files, memory, tool outputs, retrieved documents, and conversation history that get assembled into the model's working context. Where prompt engineering asks "how do I word this?", context engineering asks "what does the model need in front of it right now to do this well, and what should I leave out so it doesn't get lost or drown in irrelevant detail?" This becomes critical the moment a task spans more than one turn, because context windows fill up fast and stale or bloated context degrades performance.
Harness engineering is the practice of building the environment a single agent runs inside: its tools, its permissions, its guardrails, its verification step, and the scaffolding that tells it how to structure its thinking. A harness is the floor the agent stands on — things like a build-and-test setup a cold agent can use from a clean checkout, a written-down definition of "done," bounded cost and blast radius, and a place for project-specific knowledge to live so the agent isn't re-guessing intent on every run.
Loop engineering is the outermost layer, and the one that ties the rest together. It's the practice of designing the system that repeatedly acts, observes, and decides what to do next — on a schedule or in response to events — instead of a human supplying the next prompt by hand. A loop uses good context engineering at every step, runs inside a harness, and often issues many individual prompts along the way. If prompt engineering optimizes one turn and context engineering optimizes what the model can see, loop engineering optimizes the entire system that keeps turns happening until a goal is actually met.
Put simply: you engineer a prompt, you engineer the context around it, you engineer the harness it runs in, and then you engineer the loop that drives all of it forward without you.
2. Agentic Loop Stages: Goal, Action, Observation, Adjustment
Strip away the tooling and vocabulary, and every agentic loop is running the same basic cycle underneath. It shows up under different names in different frameworks — Reason/Act/Observe, Perceive/Plan/Act/Observe — but the core shape is consistent:
Figure 2.1 The fundamental Goal → Action → Observation → Adjustment cycle of an agentic loop.
Goal. The loop starts with something concrete to aim at. Not "improve the dashboard," but a specific, checkable target — "reduce initial dashboard load time while keeping existing filters working." A vague goal produces a vague loop; a testable goal gives the agent something it can actually verify against.
Action. The agent takes one bounded step toward that goal — it calls a tool, edits a file, runs a command, queries an API, or delegates to another agent. Good loops favor small, reversible actions over large, sweeping ones, because small actions are easier to evaluate and easier to undo if they're wrong.
Observation. The agent looks at what actually happened. This might be a test result, a stack trace, a file diff, an API response, or a screenshot. The quality of the whole loop depends heavily on the quality of this observation — an agent that can't clearly see the outcome of its own action can't meaningfully learn from it.
Adjustment. Based on the observation, the agent updates its plan — try again with a different approach, move on to the next step, escalate to a human, or decide the goal has been met and stop. This is also where the loop's "memory" matters: without some record of what's already been tried, an agent can fall into repeating the same failing action over and over.
Then it repeats — Goal stays fixed (or gets explicitly revised), and Action → Observation → Adjustment cycles again, until a stopping condition fires.
3. Agentic Loop Anatomy: Goal, Tool Set, Context Management, Explicit Termination/Escalation Logic, Error Handling
If the four stages above describe what happens on each turn of a loop, the anatomy below describes what you have to design to make a loop trustworthy enough to run unattended. A well-built loop has five load-bearing parts:
| Part | Purpose |
|---|---|
| Goal | The goal needs a testable termination condition baked in, not just a description of the desired end state. |
| Tool set | Defines the concrete actions the agent is allowed to take and the ceiling of what it can accomplish or accidentally break. |
| Context management | Keeps the agent's working context useful over many iterations rather than allowing it to balloon or go stale. |
| Explicit termination/escalation logic | Provides safety rails and defined ways to stop or hand off to a human. |
| Error handling | Determines what happens when an action fails, a tool errors out, or an observation is ambiguous. |
Goal. As above, but from a design perspective: the goal needs a testable termination condition baked in, not just a description of the desired end state. "All tests in the auth suite pass and lint is clean" is a goal a system can check automatically. "Make the auth code better" is not.
Tool set. The concrete set of actions the agent is allowed to take — read/write file access, shell commands, test runners, search, API calls, or other agents it can delegate to. The tool set defines the ceiling of what the loop can accomplish and, just as importantly, the ceiling of what it can accidentally break.
Context management. How the loop keeps the agent's working context useful over many iterations, rather than letting it balloon or go stale. This includes deciding what gets summarized, what gets dropped, and what gets re-injected at every step — for example, keeping the original goal visible in every observation so the agent doesn't quietly drift onto an adjacent task by iteration five.
Explicit termination/escalation logic. The safety rails. A loop needs a defined way to stop: the goal check passes, a maximum number of iterations is hit, a time or cost budget runs out, or the agent hits something it shouldn't handle alone and needs to hand off to a human. Without at least one explicit stop rule, a loop can keep running indefinitely, burning time and budget without making real progress — this is one of the most common production failure modes.
Error handling. What the loop does when an action fails, a tool errors out, or an observation is ambiguous. Good error handling produces a genuine adjustment — a different approach, a narrower next step, a request for help — rather than a blind retry of the exact thing that just failed.
Together, these five pieces are what separate a loop you can trust to run overnight from one that quietly spins in circles or does something you didn't want.
4. Primitives of Loop Engineering
If the anatomy above is the blueprint, the primitives are the actual parts you assemble a loop out of. Most modern agent platforms converge on a similar set, even though they use different names for them:
- Autonomy / Scheduling. The mechanism that starts a loop without a human typing a prompt — a recurring cadence, a cron-style schedule, a background routine that survives a restart, or a trigger tied to some external event. This is what turns a one-off session into something that actually recurs.
- Hooks. Small pieces of logic — often shell commands or scripts — that fire automatically at specific points in the agent's lifecycle: before an action runs, after a tool completes, when the loop is about to terminate. Hooks are how you bolt on guardrails and side effects without rewriting the agent's core instructions every time you learn something new.
- Context Engineering. As described above, but as a primitive it's the ongoing discipline of curating what the agent sees at each iteration — trimming, summarizing, and re-injecting so the loop stays coherent instead of drowning in its own history.
- Tool Access. The specific tools and permissions granted to the agent for this loop — file access, code execution, search, external APIs, connectors into real systems like issue trackers or chat tools. Scoping tool access tightly is one of the simplest ways to bound how much damage a misbehaving loop can do.
- Worktrees. Isolated working copies — most commonly git worktrees — that let multiple agents (or multiple iterations of the same agent) operate on the same underlying project without colliding. When more than one loop is touching a codebase at once, isolation stops simultaneous edits from clobbering each other, the same way it would for two engineers working the same lines without talking.
- Skills. Packaged, reusable, task-specific knowledge — instructions, conventions, examples — that an agent can reference for a recurring job instead of having that context re-explained (or re-guessed) on every run. Skills are how project-specific know-how survives across loop iterations without bloating every prompt.
- Subagents. Separate agent instances spun up to handle a bounded piece of work, often with their own tools, instructions, and context. A common pattern splits "maker" from "checker" — one agent drafts a change, an independent agent reviews it — because a model checking its own work tends to be a weaker safeguard than a separate one doing the checking.
- Spine. The durable, on-disk record of state that persists between iterations and between runs — what's been tried, what passed, what's still open. The spine is what lets a loop pick up tomorrow morning exactly where it left off last night, instead of starting cold and repeating mistakes it already made.
None of these primitives does much on its own. What makes a loop reliable is composing them: scheduling triggers the run, the spine tells it what's already been done, tool access and worktrees define what it's allowed to touch and how it stays isolated, skills give it the knowledge it needs, subagents split the work and check it, and hooks enforce the guardrails around all of it.
5. Types of Loops in Production Systems
Once a loop is running in production rather than in a single session, it tends to stack into several distinct layers, each solving a different problem. A useful way to break these down is into four levels:
Figure 5.1 Four stacked levels of loops in production systems.
Agent Loop. The innermost loop — the one described in Section 2. A model calls tools, observes results, and keeps going until a task is complete or a limit is hit. This is the loop that does the actual work.
Verification Loop. A layer wrapped around the agent loop that grades its output against a rubric or test suite and sends it back for another pass if it doesn't hold up, rather than trusting the agent's own judgment that it's done. This costs extra latency and compute, but for most production use cases where quality matters more than raw speed, it's worth it — and it's often where a human acts as the grader for judgment calls a script can't make.
Event-Driven Loop. The layer that connects an agent to the systems around it. Instead of being invoked manually, the agent sits inside a larger system and runs when something happens — a new document lands, a schedule fires, a webhook arrives, a message posts in a chat channel. This is what turns an agent from something you have to remember to run into something that's simply present in your workflow. It also introduces its own challenge: event streams like chat threads or email chains can bloat the context window over time, which is where the context-management discipline from Section 4 becomes essential again.
Hill Climbing Loop. The outermost, slowest-moving loop, and arguably the one with the most long-term leverage. Every run of the loops above produces a trace — a record of what the agent did, which tools it used, how it was graded. The hill climbing loop feeds those traces into an analysis process that looks for systemic problems — a prompt that keeps failing, a tool that keeps erroring — and updates the harness configuration in response. Each iteration of this outer loop makes the inner loops more effective, which is what makes it self-improving rather than just self-running.
Stacked together, these four levels form a pattern where automation and improvement compound on each other: the agent loop does work, the verification loop keeps that work honest, the event-driven loop keeps the whole thing running without a human remembering to kick it off, and the hill climbing loop steadily makes all three of the others better. Human judgment doesn't disappear from this picture — it just moves up a level, from approving individual actions to approving harness changes and reviewing what the system as a whole is learning to do.
Closing Thought
The shift loop engineering describes isn't that models got better at following instructions — it's that they got reliable enough that the interesting design problem moved from what do I tell it to do to what system decides what it does next, and when it should stop. Prompt engineering is still part of that system. So is context engineering and harness design. Loop engineering is what holds all of it together and lets it run without you standing in the middle of every cycle.
