Loop Engineering and Autonomous Agent Systems
The Bottleneck Is Not the Model. It is you. Stop being the loop. Start designing the system that does the work.
Loop Engineering and Autonomous Agent Systems
Prompt Engineering.
Context Engineering.
Vibe Coding.
Spec-driven development.
Agentic Code Engineering.
Deep Agents.
Harness Engineering.
Loop Engineering.
Our industry never runs short on the latest, greatest buzzword. And here we are again: another term has entered the chat, morphed through a few names and focus areas, and now arrived as Loop Engineering.
If you have used it, you already see the value.
If you have not, you should probably learn about it.
One thing is clear: Loop Engineering has entered the zeitgeist.
The Bottleneck Is Not the Model
You have probably felt it. You open a chat window, type a prompt, read the output, decide what is wrong, type another prompt, read the output again. That cycle is the exact bottleneck loop engineering is designed to break. The model does something impressive on step three, then misses something obvious on step four, and you are right back in the loop manually, except you are the loop. You are the verification step. You are the feedback signal. You are the part that decides whether to try again.
That is the bottleneck, and it has nothing to do with raw model capability. Modern AI agents can write code, debug it, refactor it, generate tests, and explain their reasoning. The capability is there. What is missing is the design pattern that lets a model use that capability without a human holding its hand through every turn.
The bottleneck is that most developers are still writing prompts when they should be practicing loop engineering: designing autonomous systems that verify their own output and drive themselves toward a goal. As defined in this article, loop engineering is not a new model capability; it is a design discipline.
That is why the phrase has started showing up in the AI tooling conversation. Addy Osmani recently framed the shift as loop engineering, citing Peter Steinberger’s line: “You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.” Osmani also cites Boris Cherny, head of Claude Code at Anthropic, saying that he no longer prompts Claude directly. Instead, his work is writing loops that prompt Claude and decide what to do next. (Addy Osmani)
From Single Prompts to Autonomous Agent Loops
A prompt is a single instruction. You write it, the model responds, and then you read the response and decide what to do next. You are in control, which sounds good, but it means you are also on the hook for every iteration. You are the one noticing when the output is wrong. You are the one formulating the correction. The model is a very capable responder, but it is not driving itself anywhere. It is waiting for you.
Designing Autonomous Agent Feedback Loops
A loop changes the architecture entirely. Instead of sending a single instruction and waiting, you design an autonomous feedback loop: the model picks the next action, executes it, verifies the result against a criterion, and feeds that result back into the next action. That cycle runs again and again until a gate says the goal is met or a stop condition ends it. The model is no longer waiting for you to read the output and formulate the next step. It is driving itself.
The shift sounds subtle. In practice, it changes what you build, how you think about failures, and what your job actually is.
The Architect’s Role in Self-Correcting Agentic Workflows
Here is the thesis, stated plainly: the skill that separates developers who get real results from agentic systems from those who are just typing faster is learning to design self-correcting loops. And the payoff of that skill is a role change: from manual instructor (the person writing each prompt) to system architect (the person who defines the goal, builds the verification gates, and then lets the system run).
The rest of this article earns that role change. It is not a promise about where AI is headed. It is a design pattern you can use right now.
The four stages of that pattern, action, execute, verify, and feedback, are simple to name and easy to underestimate. Most developers have heard of feedback loops. Fewer have designed one that actually works without human steering at every turn. The difference lives in a single stage most people skip.
The Anatomy of an AI Agent Feedback Loop
What does an autonomous agent loop actually look like, stage by stage? Four stages. They cycle. That is the whole structure.
Action. The model decides the next step toward the goal. Not the whole plan: just the next concrete action. Edit this file. Run this test. Call this tool. Write this draft section. The action is always specific and executable.
Execute. The decided step runs. Something real happens in the world: a file changes, a command runs, a tool returns a result. Execution is what separates an agent from a planner. In practice, the planning step carries few immediate costs, while execution (file edits, command runs, API calls) produces real-world consequences the loop must be designed to handle.
Verify. The result of execution is checked against a criterion. Did the test pass? Did the linter report errors? Does the output meet the stated quality bar? This is the stage most developers skip or shortcut, and skipping it is what collapses a loop back into a chain of calls. More on this in a moment.
Feedback. The verification result feeds back into the next action. If the test failed, the failure output becomes the input to the next action decision. If the quality check flagged a problem, that flag becomes context. The model is not starting fresh; it is learning from what just happened inside this loop, not across sessions, but within this run.
The cycle continues until one of two things happens: a verification gate passes (goal met, output accepted, work is done), or a stop condition is reached (maximum iterations, budget exhausted, unrecoverable failure). Stop conditions are a first-class design concern, not an afterthought. A loop without a stop condition is not autonomous; it is a runaway process.
Why the Verify Step Defines Autonomous Agent Loop Design
Here is the sharpest point of this whole article, so pay attention.
The VERIFY step is what makes a loop a loop.
Without real verification, you do not have a loop. You have a chain of calls. The model takes an action; you move to the next call. The model takes another action; you move to the next call. No signal comes back. No gate checks whether anything worked. The loop shape is there on paper, but it has no mechanism to catch its own failures. It is just sequentially hoping.
A chain of calls with no verification is not autonomous. It is an unsupervised guess that runs until it stops.
This is why cheap verification is not a shortcut; it is a trap. An “always passes” gate does not make the loop self-correcting; it just makes failures invisible until they ship. The loop will confidently execute all its iterations, produce output, call it done, and deliver something wrong. With confidence.
Verification is the thing worth investing in. Not just the prompt, not just the model choice, not just the toolchain. The verification signal is what gives a loop its intelligence. If the signal is weak, the loop is weak.
Implementing AI Agent Feedback Loops: A Concrete Example
A concrete sketch helps here. Imagine a loop that writes and fixes a function until its tests pass:
goal = "implement merge_sorted_lists with passing tests"
context = initial_context(goal) # ①
while not done:
action = model.decide(context) # ②
result = executor.run(action) # ③
verdict = verify(result) # ④
if verdict.passed:
done = True
elif verdict.iterations > MAX:
raise StopCondition("max iterations reached")
else:
context = update(context, result, verdict.feedback) # ⑤① Set up the initial context: the goal, the relevant files, any prior constraints. This is what the model sees before its first action.
② The model decides the next step: in this case, probably “write the function body.” On subsequent iterations, it might decide “fix the off-by-one error the test caught.”
③ The decided action runs. The code change happens. The tests execute.
④ The verification check runs. Tests pass or fail. This is the gate. A failed gate does not end the loop; it generates feedback.
⑤ The context is updated with what just happened: the failure output, the current state of the file, the iteration count. The model sees this on the next pass. The loop continues informed, not blind.
This is the skeleton every autonomous agent loop hangs on. The sophistication lives in the verify step and the context update, the stages most people underinvest in. Here is what that sophistication looks like in practice.
Two Verification Patterns Worth Knowing
The example above uses a deterministic verify: tests pass or they do not. That is the strongest signal available. Unambiguous. Repeatable. No opinion involved. Use it whenever objective criteria exist.
But some goals do not have a test suite. When you are asking “is this explanation clear?” or “does this API design hold together?”, you cannot write a test for that. You need a different kind of verify.
That is where the LLM-as-judge pattern comes in. A secondary model reads the primary model’s output against a rubric and returns a verdict. The loop structure is identical; only the verification function changes.
def verify_with_judge(output, rubric):
prompt = f"""
Evaluate this output against the rubric below.
Rubric: {rubric}
Output: {output}
Return PASS or FAIL, then a one-sentence reason.
"""
verdict = judge_model.call(prompt) # ①
return parse_verdict(verdict) # ②① The judge model receives both the output and a specific rubric. Concrete criteria work better than vague instructions. “Does this explanation avoid assuming the reader already knows X?” beats “is this good?” ② The verdict is parsed into the same pass/fail interface the deterministic verify uses. The rest of the loop does not know or care which pattern ran.
The tradeoff: a judge-based verify is itself non-deterministic. The same output can get different verdicts on different runs. The mitigation is a clear, specific rubric and, on borderline cases, averaging across multiple judge calls rather than trusting a single verdict.
Reserve the judge pattern for subjective qualities that genuinely cannot be tested. Use deterministic gates for everything that can.
Stop-Condition Design
The skeleton shows MAX iterations as a stop condition. That is the minimum. A production loop benefits from three distinct stops, designed explicitly:
Max iterations. A ceiling on the loop count. When you hit it, the loop stops and surfaces what it has rather than running indefinitely. The ceiling also forces a useful question: if this loop cannot converge in N iterations, what does that tell you about the goal definition or the verification signal?
Budget exhaustion. Loops consume tokens, compute, and time. A budget stop exits cleanly when a resource ceiling is reached. Without it, a stuck loop can become expensive before it fails.
Failure pattern detection. Some failures signal that the loop cannot make forward progress: the same error appears three iterations in a row, a required tool is unavailable, output is structurally malformed. Detecting these patterns and stopping early beats exhausting the iteration limit first.
Stop conditions are not edge-case error handling. They are part of the loop’s success definition. Knowing when to stop trying is as important as knowing what to try next.
What This Looks Like at the Tool Level
The four-stage structure is not theoretical. Claude Code now exposes this pattern directly through /goal, which sets a completion condition and keeps Claude working across turns until that condition is met. Anthropic’s docs describe the mechanism plainly: after each turn, a small fast model checks whether the condition holds. That is loop engineering as a product feature: define the goal, let the agent act, verify progress, and continue until the gate passes. (Claude Code)
OpenAI Codex has converged on the same pattern. Its /goal feature lets a developer set an objective, pause it, resume it, clear it, and keep Codex working independently across turns. OpenAI’s cookbook describes goals as persistent objectives that define what should be true, how success should be checked, and what constraints must remain intact. (OpenAI Developers)
Other tools expose pieces of the same architecture even when they do not call it /goal. Grok Build has Plan mode and /plan, plus headless operation and skills that can appear as slash commands. That makes it suitable for planning, approval, scripted execution, and custom loop construction, even though I did not find an official Grok Build /goal command in the current docs. opencode takes the extensibility route: its official docs support custom slash commands and plugins, and a separate third-party opencode-goal-plugin adds an experimental session-scoped /goal command that keeps the goal in context, auto-continues when the assistant goes idle, and stops when the goal is complete, blocked, or a safety limit is reached. (xAI Docs)
Open-weight models designed for agentic behavior, such as Hermes from Nous Research, support tool calling that makes this same loop structure available with locally deployable models. The same goes for higher-level frameworks: Open Claw lets you wire up goal-driven loops, and Auto Research does too, with the added twist that it folds its own results back into the next iteration so the loop improves itself as it runs. None of this is special to one tool. Loop engineering is an idea, a pattern, and you can build it into most agentic frameworks. The pattern is not tied to any specific provider. It is the structure that matters, not the framework or model behind behind it.
The sophistication in every working agent loop, whether in a production tool or a hand-rolled script, lives in three places: how the verify signal is designed, how context is managed across iterations, and how stop conditions are defined. Everything else is plumbing.
The verification signal determines how reliably a loop corrects itself. But not all signals are the same kind of thing. A deterministic gate and an LLM judge are not interchangeable. They handle fundamentally different kinds of questions, with different failure modes and different costs when they give a bad answer.
Deterministic vs Non-Deterministic Loops
Not all verification is the same. The type of verification signal you choose determines how reliably a loop can drive itself toward correct output without human intervention.
Some criteria produce a clear, unambiguous pass or fail. A unit test either passes or fails (no partial credit, no interpretation required). A linter either reports zero errors or it reports some. A type-checker either clears the file or it flags a type mismatch. A build either compiles or it does not. A script exits 0 or it does not. These are deterministic verification signals: the same output, checked against the same criterion, gives you the same verdict every time. There is no opinion involved. No probability. Just a result.
Other criteria cannot be reduced to a script. Is this API design clean? Is this prose clear enough for a developer unfamiliar with the domain? Does this explanation actually make sense to someone reading it for the first time? You can write rubrics for these things, but you cannot write a test that returns a reliable pass/fail. For these qualities, the common pattern is to use a secondary model as the judge: a second LLM that scores or critiques the primary model’s output against stated criteria. This is the LLM-as-judge pattern, and it is genuinely useful for extending loops into territory where deterministic checks cannot reach.
In Agentic AI systems, the distinction matters more than it might look. A soft signal where a hard gate would do the job does not just cost you confidence in the result; it introduces variance that accumulates across iterations and makes the loop harder to reason about.
Deterministic loops verify objective, measurable properties (tests pass, linter clean, build succeeds) using an unambiguous pass/fail from a script or tool. Failure is specific: the error message, the exit code, the line number.
Non-deterministic loops evaluate subjective qualities (clarity, design, ergonomics, tone) using a verdict from a secondary LLM judge. The signal is softer; the same output can get different verdicts on different runs.
The decision rule: use deterministic gates whenever you can make the criterion objective. Reserve the LLM judge only for qualities that genuinely cannot be scripted.
Deterministic Verification: The Strongest Foundation for Autonomous Loops
Take the deterministic case first, because it is the stronger foundation.
When verification is deterministic, the feedback signal is unambiguous. The test failed on line 23, with this assertion error, because this value did not match that expected value. The loop does not have to guess at what went wrong. It can read the failure output and use it directly. This is cheap to run, repeatable across machines and runs, and completely free of opinion. If you can make your verification deterministic, you should. It is the most reliable foundation for an autonomous loop.
LLM-as-Judge: Extending Autonomous Loops Into Subjective Territory
Non-deterministic verification is a different animal. The LLM-as-judge pattern works by placing a second model between the agent’s output and acceptance. The judge receives the output and a rubric (a set of criteria about what “good” looks like for this particular quality) and returns a verdict. That verdict might be a score, a pass/fail, a list of specific objections, or some combination. The primary model receives the verdict as feedback and revises.
This is genuinely useful. There are real qualities you care about that no script can reliably evaluate, and a secondary model with a clear rubric can catch things that would otherwise slip through undetected. The limitation is equally real: the judge is itself non-deterministic. Run it on the same output twice and you may get different verdicts. A well-crafted but flawed output can sometimes fool it. The signal is softer than a failing test.
The practical mitigations are not complicated. Use clear rubric criteria so the judge has specific guidance rather than vague instruction. “Does the explanation assume less prior knowledge than the reader is likely to have?” is better than “is this clear?” Average across multiple judge runs to reduce variance on close calls. Reserve the LLM judge for qualities that genuinely cannot be scripted; do not use a soft signal where a deterministic gate will do the job.
Agent-as-Judge: Evaluating Loop Process, Not Just Final Output
An emerging direction extends the judge concept further: instead of evaluating the final output, an agent-as-judge inspects intermediate steps. Did the planning phase produce a reasonable decomposition? Did the tool selection match the stated task? Were the handoffs between steps coherent? This is promising as a direction for catching process failures rather than only output failures. It is not a settled standard yet, but it points at a real gap: most judge patterns evaluate what came out of the loop, not whether the loop ran sensibly in the first place.
The practical takeaway: start with deterministic verification wherever you can. Add LLM-as-judge for the genuinely subjective qualities where deterministic checks cannot reach. Be honest with yourself about which category each criterion falls into, because assigning a soft judge to something objective just introduces unnecessary variance into a signal that could be clean.
The goal in both cases is the same: a feedback signal strong enough to guide the loop toward correct output. The type of signal changes; the requirement for real signal does not.
A loop with strong verification signals can still lose coherence at scale. Not because the signals are wrong, but because the model’s context window fills with noise and it loses track of why it started. And without named checkpoints in the workflow, even clean signals cannot stop a failure from propagating before it is too late. These are the two structural concerns that verification patterns alone do not address.
Context Management and Verification Gates in Autonomous AI Loops
What keeps a self-correcting loop coherent across many iterations? Two practical concerns: what the model sees on each iteration, and where the checkpoints live.
Context management is a design responsibility, not a feature the model handles automatically. Every iteration, the model executes an action; something happens, and the result accumulates in history. Prior actions, prior results, prior failures, files in play, intermediate outputs: all of it builds up. The model has a finite context window (think of it like a whiteboard that can only hold so much before you have to erase something to make room). If you do not actively manage what goes into it, you will hit one of two failure modes: you truncate arbitrarily, losing critical signal, or you flood the window with noise until the model loses coherence and starts drifting from the original goal.
The design decision is explicit: what does this model need to see on this iteration to take the right next action? Keep the failing test output: that is the live feedback. Keep the current goal statement: that is the anchor. Keep the files currently in play: that is the working surface. Shed the five previous iterations of intermediate results that are no longer relevant. Shed the scaffolding output from earlier stages that has already been acted on.
Good context management is what keeps a long Agentic AI loop coherent instead of confused. The model is not drifting because it is bad at long tasks. It is drifting because the signal-to-noise ratio in its context collapsed five iterations ago and it is now responding to noise.
Designing AI Verification Gates as Workflow Checkpoints
Verification gates are the structural counterpart: checkpoints that work must pass before the loop continues or terminates. A gate is not just a check you run at the end; it is a named point in the workflow that has explicit pass/fail semantics. The test suite gate. The linter gate. The code review gate. The prose clarity gate. Each one sits between stages of the loop and decides: keep going, loop back with feedback, or stop.
The key structural insight is this: you cannot place a gate on a monolithic prompt. A single-shot “do the whole thing” instruction has no seams. There is nowhere to put a checkpoint between “draft the function” and “verify the function passes tests” because there is no boundary between them. It is all one call. The output either works or it does not, and by the time you know that, you have already shipped it.
Task Decomposition Creates Gate Seams for Loop Engineering
Decomposing a task into named steps creates the seams where gates can sit. First: write the function signature. Gate: does this signature match the expected interface? Second: implement the body. Gate: do the tests pass? Third: clean up the implementation. Gate: does the linter pass? Each decomposed step has an entry point and an exit condition. That structure is what transforms a sequence of calls into a self-correcting workflow.
The Loop Engineer’s Role: System Architect over Manual Instructor
Put these pieces together and the human’s role becomes clear.
Once the self-correcting loop exists and the verification gates are in place, the developer stops typing the next instruction and starts designing the system the model runs inside. That is the role shift loop engineering delivers: from manual instructor to system architect.
The architect has four jobs.
Define the goal. What is the loop trying to accomplish? What does a successful outcome look like? The model needs this as its anchor across every iteration. A vague goal produces a loop that confidently converges on the wrong target.
Define what “done” means. This is the gate design. Which criteria must pass for the output to be accepted? Which qualities get deterministic checks and which require a judge? Where do the gates sit in the task decomposition? “Done” is not a feeling; it is a set of gate conditions that have all passed.
Manage the context budget. What does the model see on each iteration? What is kept, what is shed, and when? Long loops fail here when nobody made these decisions explicitly.
Set the stop conditions. What ends the loop if the goal is not reached? Maximum iterations? A time budget? An unrecoverable error pattern? A loop without stop conditions is not autonomous; it is indefinitely running. Stop conditions are how you define the loop’s boundaries without being in the inner loop yourself.
This is not abstract architecture work. AI agents that can drive their own action-feedback cycles already exist, and the tooling around them is becoming more explicit. Claude Code exposes /goal as a user-facing loop feature. OpenAI Codex exposes a similar /goal feature. Grok Build exposes Plan mode, /plan, headless execution, and skills. opencode exposes custom commands and plugins, with an experimental goal plugin already implementing the pattern. The Claude Agent SDK sits one layer lower: it does not need to expose a single magic command to be relevant, because it gives developers the agent loop, tool execution, slash command dispatch, and hooks needed to build their own goal-driven systems. Anthropic’s SDK documentation says the loop evaluates a prompt, calls tools, receives results, and repeats until the task is complete. (Claude Code)
The Honest Limits: Why Verification IS the Design
Now for the honest part.
A self-correcting loop is only as good as its verification. A weak gate does not protect you; it gives you a loop that confidently iterates toward the wrong output and reports it as done. The LLM judge can be fooled by a plausible-sounding result that does not actually meet the bar. A deterministic gate can have gaps if the test suite is incomplete. The loop will find those gaps.
This is why /goal is only as good as the completion condition behind it: a vague goal creates a vague loop, while a verifiable goal creates an agent that can actually know when to stop. (Claude Code)
The investment that pays off is not in writing better prompts. It is in building stronger verification. Better test coverage. Clearer judge rubrics. More precisely named steps with tighter gate conditions. In loop engineering, the verification IS the design. A loop with excellent prompts and weak verification will still fail. A loop with adequate prompts and strong verification will converge.
The developers who get the most value from agentic systems will not be the ones with the cleverest prompt phrasing. They will be the ones who learn to architect loops: define the goal, build the gates, manage the context, set the stop conditions, and then let the system run.
That is the whole move.
Related Articles
If this article sparked ideas you want to follow further, these pieces cover the patterns directly:
Architecting Production-Grade Agents through LLM Orchestration and Agentic Loops The implementation companion to this article. It goes beyond the four-stage design pattern to show how production teams wire LLM orchestration into durable, observable agentic loops, covering checkpointing, tool routing, and the infrastructure choices that separate a working prototype from a system that runs unattended.
Harness Engineering vs Context Engineering: The Model is the CPU, the Harness is the OS Establishes the mental model that underpins loop engineering: the harness is the operating system the model runs inside, and context is its working memory. Explains why loop architects must own both, and why conflating prompt engineering with harness design produces systems that cannot self-correct.
What Is Harness Engineering? The Engineering Discipline for Production AI Agents The foundational primer for readers new to the discipline. Defines harness engineering, maps it to the feedback-loop design patterns covered in this article, and explains why prompt writing alone cannot produce autonomous systems, the essential context for anyone starting their loop engineering journey.
Why Single-Agent AI is Dead: Inside Anthropic’s New Blueprint for Long-Running Agents Shows where loop engineering leads at scale, when a single action-execute-verify cycle is no longer enough and work must span hours, tools, and coordinated sub-agents. Covers Anthropic’s architectural guidance for long-running agents and how the stop-condition and context-budget principles from this article extend into multi-hour autonomous runs.
The Eleven Patterns Behind Every Production Agentic System (And Where JSON Schemas Actually Earn Their Keep) Extends the loop engineering pattern library into a full catalog of recurring structures found in production agentic systems. Directly relevant to readers who have grasped the four-stage feedback loop and want a map of what comes next, including tool selection, output validation, and structured handoffs between stages.
References
Addy Osmani, “Loop Engineering.” Source for the term itself and the Peter Steinberger and Boris Cherny references. Addy Osmani, Loop Engineering
Anthropic Claude Code docs, “Keep Claude working toward a goal.” Source for
/goal, completion conditions, and verification after each turn. Claude Code docs, Keep Claude working toward a goalOpenAI Codex docs, “Follow a goal” and “Using Goals in Codex.” Source for the Codex
/goalfeature, persistent objectives, pause, resume, clear, and success checks. OpenAI Codex, Follow a goal and OpenAI Cookbook, Using Goals in CodexxAI Grok Build docs, “Modes and Commands” and “Introducing Grok Build.” Source for Plan mode,
/plan, plan approval, headless workflows, and skills. No official Grok Build/goalcommand was found in the current docs. xAI Docs, Modes and Commands and xAI, Introducing Grok Build. According to Grok Build “I do not have the update_goal tool, so /goal is not active here. Typing /goal ... is treated as normal text, not as a goal command./goal works in native Grok CLI when goal mode is enabled and that tool is wired in. In Cursor + Grok, it is not supported in this integration right now.” There is also a plugin called opengoal that you can install. It seems like there is some support but it is not enabled by plan or by feature flag.
opencode docs. Source for official custom slash commands and plugins. opencode docs, Plugins
opencode-goal-pluginthird-party. Source for the experimental, session-scoped/goalcommand built on opencode’s plugin system, separate from official opencode features. willytop8/OpenCode-goal-plugin on GitHubClaude Agent SDK docs, “How the agent loop works,” slash commands, and hooks. Source for the lower-level loop primitives the SDK exposes, distinct from a single product command. Claude Agent SDK, Agent loop, Claude Agent SDK, Slash commands, and Claude Agent SDK, Hooks
About the Author — Claude Certified Architect
Rick Hightower helps companies become AI-first through practical mentoring, executive and team training, and custom AI solution development. A former Senior Distinguished Engineer at a Fortune 100 company, Rick focused on bringing ML and AI insights into real front-line business applications.
Rick is a Claude Certified Architect, AI systems practitioner, builder of production multi-agent systems, creator of Skilz, and author of an upcoming Manning book on Harness Engineering.
Ready to make your company AI-first? Connect with Rick on LinkedIn, Substack or Medium, book him to speak or train your team, or visit Spillwave to explore mentoring, training, and custom AI solutions for your organization. Check out Rick Hightower’s SpeakerHub.