Loop Engineering Stopped Being a Buzzword the Second People Started Teaching It
From Viral Reframe to Convergent Curriculum: How Loop Engineering Became Teaching Material in Weeks
Most developers are still focused on writing better prompts. In the last three weeks, the people building and teaching the most capable agent systems have already moved through context engineering and harness engineering and started designing the loops that actually run the work.
In this article: In June 2026, a small group of prominent AI engineering voices proposed a shift in how developers work with coding agents. Rather than prompting agents directly, they argued, the higher-leverage activity is designing the systems that manage prompting, observation, and continuation. Within weeks, that perspective moved from widely shared posts into structured teaching material. Multiple independent platforms and educators released detailed guides exploring agent loops and the architectures that support them. This article examines that rapid transition. It traces the original reframing, surveys the new wave of curricula, and compares how different sources describe the structure of reliable agent systems.
If you are a paid subscriber, thank you. Your support makes this work possible.
If you are a free subscriber and find these articles useful, please consider upgrading. A paid subscription is $80 per year or $8 per month.
Loop Engineering Is Now Teaching Material
Something shifted in mid-June 2026. By early July, it had a syllabus.
Addy Osmani, Peter Steinberger, and Boris Cherny (who leads Claude Code at Anthropic) all said the same thing in different words: stop prompting the agent by hand, and start designing the loop that prompts it for you. Within weeks, that idea stopped being a Twitter argument and turned into teaching material. MindStudio, Tosea.ai, Data Science Dojo, Requesty, AI Builder Club, Towards AI, and others shipped comprehensive guides that converge on the same structural picture: a loop inside a harness, with explicit verification, durable state, and hard termination.
That convergence is the story. Not whether loop engineering is a buzzword (it is, and the skeptics are right to say so), but that independent educators and platforms are now teaching the same six-component harness model and the same stacked-loop architecture. When vocabulary stabilizes that fast, the underlying pattern is load-bearing.
If you need the foundational mental model first, read Loop Engineering and Autonomous Agent Systems in this repo’s loop-engineering series. This article maps what happened after the name landed.
The June Moment: Three People, One Reframe
Here is the reframe in plain language.
A prompt is a single instruction you babysit. A loop is a recursive goal: the model acts, observes, verifies, and repeats until a stop condition fires. Your job moves from manual instructor to system architect.
The cultural moment crystallized over two days in June 2026.
On June 7, Peter Steinberger, creator of the OpenClaw agent project, posted what became the viral version: you should not be prompting coding agents anymore; you should be designing loops that prompt them. The post reportedly reached millions of views within days. The same week, Addy Osmani, an engineering lead at Google, published an essay titled Loop Engineering that gave the practice a name and an anatomy. He did not claim sole coinage. He cited Steinberger and Cherny explicitly.
Boris Cherny’s version, widely reported in practitioner writing, compresses the role change into one sentence: he does not prompt Claude directly anymore. He writes loops. The loops prompt Claude and figure out what to do next. Cherny, who created Claude Code after joining Anthropic as a founding engineer in September 2024, has not hand-written a line of code in roughly eight months; he instead manages hundreds to thousands of agents daily.
Why now? Because the agents finally run long enough to matter. When a single agent session can touch dozens of files over an hour, the highest-leverage work is not crafting the next prompt. It is designing the cycle that keeps the agent on goal, verified, and bounded while you are not watching.
From Viral Take to Curriculum
How does a practitioner term become a discipline? In a recognizable order.
First someone coins a term from lived practice. Then independent writers rediscover the same structure without coordinating. Then bootcamps, platforms, and vendor blogs ship comprehensive guides that all draw the same diagram.
Loop engineering hit stage three by early July 2026.
The guides differ in tone and product placement, but they agree on the engineering problem:
SourceWhat it emphasizesVerified dateData Science DojoLineage from ReAct through Ralph Loop and /goal; guardrails as non-optionalJune 9, 2026Tosea.aiFour-layer evolution: prompt → context → harness → loopJune 2026RequestyFour loop types (heartbeat, cron, hook, goal); production anatomyJune 17, 2026MindStudioLoop patterns, termination logic, error recoveryJuly 1, 2026AI Builder ClubVerifier as bottleneck; open vs closed loops; three-loop nesting2026AI Builder ClubSix-component harness decomposition2026Towards AILoop vs harness boundaryJune 2026
That is at least seven comprehensive guides from independent platforms in the weeks after the June coinage. They were not coordinated. They converged anyway. That is usually how you know a pattern is real.
Andrew Ng added institutional weight in a late June 2026 Batch letter, mapping three nested loops at different cadences (agentic coding, developer feedback, external feedback) and naming loop engineering explicitly as post-viral vocabulary. When the person who taught half the industry machine learning writes a letter about your term, you are past the novelty phase.
What Each Source Actually Says
The table above tells you what each guide emphasizes. It does not tell you what each one argues. Here is the substance, source by source, so you can see the agreements and the genuine disagreements.
Addy Osmani: “Loop Engineering”
Osmani named the practice and gave it an anatomy. His definition: a loop is a recursive goal; you define a purpose, and the AI iterates until it is complete. The key move is replacing yourself as the person who prompts the agent with a system that prompts the agent for you. He places the loop one floor above the harness: harness engineering is the environment a single agent runs inside; loop engineering is that harness running on a timer, spawning helpers, and feeding itself. His structural anatomy is five primitives plus state: automations (scheduled discovery and triage), worktrees (parallel isolation), skills (project knowledge injected each run), plugins and connectors (MCP, external systems), sub-agents (the maker/checker split), and external state (a markdown file or Linear board, because the model forgets everything between runs and “the agent forgets, the repo doesn’t”). He maps both Claude Code and Codex onto all five primitives and shows that they converge on the same feature set. His caveats are as important as his model: verification is still on you (”done” is a claim, not a proof), comprehension debt grows as the loop ships code you did not write, and cognitive surrender tempts you to stop having opinions. His thesis: build the loop, but stay the engineer.
Data Science Dojo: “Agentic Loops Explained: From ReAct to Loop Engineering”
This guide takes the lineage approach. An agentic loop is defined as a trigger plus a verifiable goal, with three trigger types (event-based, scheduled, human-initiated) and five internal stages (perceive, reason, plan, act, observe). It traces the family tree: ReAct (2022, Princeton and Google Research) as the foundation, Reflexion (NeurIPS 2023) adding a self-critique and memory layer, Plan-and-Execute, OODA, Microsoft’s Magentic-One inner/outer dual loop, multi-agent orchestration, the Ralph Loop (Geoffrey Huntley, July 2025; a shell loop that resets context each iteration and keeps state on disk), and finally /goal and /loop as productized versions (it reports Claude Code shipped /goal around version 2.1.139 in May 2026, with Codex following). Guardrails are treated as non-optional: hard iteration cap, token and cost budget, no-progress detection, circuit breakers, termination criteria defined before the loop starts, and human-in-the-loop checkpoints before irreversible actions. Its failure-mode catalog is the most complete of the set: infinite loops, goal drift, context overflow, silent failures, token cost explosion, and error propagation, with AutoGPT’s 2023 spiral as the canonical warning.
Tosea.ai: “What Is Loop Engineering? A Complete Guide”
Tosea frames loop engineering as the latest step in a four-layer evolution, each layer wrapping the previous without replacing it: prompt engineering (2022 to 2024, optimizing the words) → context engineering (2025, optimizing everything the model sees) → harness engineering (2026, the full environment) → loop engineering (2026, the iterative cycle itself). It cites Tobi Lütke, Andrej Karpathy, and Anthropic’s September 2025 context-engineering work to ground the middle layers. Its design principles are: a clear goal with a testable termination condition; a toolset that interacts with the real environment; context management; termination and escalation logic; and error handling that distinguishes recoverable errors from hard blockers. It names three hard parts: context management (context rot over long sessions), termination and no-progress detection (the signature bug of a naive loop), and verification as the reward signal, where deterministic verification (tests, type checkers, linters) is the gold standard, and LLM-as-judge is reserved for genuinely unquantifiable cases. Its failure modes include objective misspecification, reward hacking (deleting the failing test to make CI green), and hallucinated success. It is also the most explicit: loop engineering is not always the right tool; for many tasks, an interactive session with a good agent is faster and safer.
Requesty: “Loop Engineering: How to Build AI Agent Loops That Run Themselves”
Requesty is the most operationally concrete guide. It taxonomizes four loop types by trigger: heartbeat (seconds to minutes, for monitoring and drift detection), cron (scheduled, for batch work and daily reviews), hook (event-triggered, one run per PR or CI failure or Slack message), and goal (iterate until a success condition is met, for refactors and migrations of unknown scope). Its production anatomy comprises five components: worktrees for isolation, skills as versioned instruction sets, connectors via MCP, subagents with their own context windows and tool permissions, and state tracking via JSON checkpoints, git history, or a database. It attributes the practicality of loops to three recent capabilities: models now handle long tasks (it cites METR benchmarks showing Claude Opus 4.6 completing 50% of tasks that take 12 hours, versus roughly 1 hour 40 minutes a year earlier), loops are built into the tools (/loop, cron, the Codex Automations tab), and subagents prevent context degradation by giving each iteration a fresh window. Its distinctive contribution is cost: route each step to the right model tier (a cheap nano model for file scanning, a mid-tier model for drafting, a frontier model only for final review), combine with prompt caching, and a loop costing $50/day at frontier pricing can drop to $8 to $12/day. Its failure list (token runaway, context rot, overconfident termination, state amnesia) maps directly to its anatomy: each failure is a missing component.
MindStudio: “What Is Loop Engineering? The New Meta for AI Coding Agents”
MindStudio is the cleanest beginner-oriented guide. It defines a loop as act, observe, reason, repeat until a termination condition is met, and draws the chain-versus-loop distinction (a chain is linear A→B→C; a loop is dynamic and can retry with a modified approach). It identifies ReAct as the origin and argues coding is a naturally iterative domain where single-shot generation fails because it cannot catch runtime errors or verify that produced code actually works. Its anatomy is five parts: a clear goal with testable sub-tasks, a tool set (code execution, file system, terminal, search, test runners, without which the loop is “just guessing”), context management, termination logic (success conditions, failure conditions, escalation paths), and error handling that distinguishes recoverable errors from hard blockers. Its strongest claim is that agent quality depends more on loop design than on the base model. It catalogs four loop patterns (retry, plan-and-execute-verify, explore-and-narrow, and human-in-the-loop) with when-to-use guidance, and describes multi-agent loops with planning, executor, and reviewer roles. Its failure modes are the simplest list: no exit condition, repeated failures without strategy change, context overflow, vague goals, and missing tool access.
AI Builder Club: “Loop Engineering Guide (2026)”
This guide’s central thesis is sharper than the others: the verifier is the bottleneck, not the generator or the model. Models are now extremely good at generating, and, in a loop, the generator runs over and over for nearly free; the verifier determines whether the motion produces value, encoding domain knowledge, taste, and the reward function. Writing the verifier is compared to defining the reward function in reinforcement learning: the model is a commodity, the reward function is yours, and the verifier is the new prompt engineering. It introduces the open-versus-closed loop distinction: closed loops pin success criteria in advance and check every step (predictable, budget-friendly), while open loops give a loose goal and let the agent explore a wide space (novel output, but it burns tokens and can degrade into slop). Open loops need an even stronger verifier, because it is the only thing preventing exploration from becoming garbage. It then layers in Andrew Ng’s three nested loops at different cadences: the agentic coding loop (seconds to minutes, run by the agent), the developer feedback loop (tens of minutes to hours, run by you), and the external feedback loop (hours to weeks, run by the world); and notes that as you move outward the verifier becomes more human and automated tests become less sufficient.
AI Builder Club: “The 6 Components of a Production Agent Harness”
The companion guide formalizes the architecture all the others gesture at. Its core equation is Agent = Model + Harness, where the harness is everything that is not the model, and the model sets the ceiling while the harness is entirely yours. The six components are context management (what the model sees), tool system (what it can touch), orchestration (what happens next), state and memory (what persists), evaluation and observability (was it right, and is it debuggable), and constraints and recovery (what if it breaks). The framing is explicitly diagnostic rather than a maturity ladder: these are load-bearing walls, and weak behavior points to the weak wall. Its symptom-to-gap table is genuinely useful: quality varying run to run points to context, hallucinated actions point to the tool system, great-but-incoherent fragments point to orchestration, asking things it knew yesterday points to state, failures discovered only by users point to evaluation, and one flaky API call killing a long run points to recovery. It flags two specific traps: the 46-tool collapse (too many tools degrade selection accuracy) and models grading their own homework too generously. Its production principle (production and acceptance must be different parties) is the maker/checker split stated as an org rule.
Towards AI: “Loop Engineering vs. Harness Engineering”
Towards AI is the one guide that argues the boundary itself is the problem. Its core example: a coding agent loops forever (makes an edit, breaks a test, fixes that test, breaks a different one), and the team’s response is to bolt on another retry layer, which makes things worse. The root cause was never the loop; it was that nothing checked whether an edit was safe before the agent tried it, which is a harness problem. Its lesson is that loop engineering and harness engineering solve different problems, and confusing them costs weeks or months: a failure to land is often a missing harness, not a missing retry. The practical framework is a triage question: is the problem that the agent repeats unsafe actions (needs a harness) or that it never gets going (needs a loop)? Do not assume retries solve a problem that is actually about pre-action safety.
Oracle: “The Agent Loop Decoded” (Richmond Alake)
Oracle’s contribution, published June 11, 2026, organizes the agent loop into three levels, but the levels are about memory and context maturity, not about inner-loop/verification/multi-agent stacking. It defines the agent loop as the repeating cycle a harness runs within a single agent turn: assemble context, invoke the model to reason, act, and repeat until a stop condition ends the run. It exists because long-horizon tasks cannot be completed in a single forward pass. The three levels are:
Level 1: LLM + Tools + Response. The minimal loop: an LLM that can call tools and return a response, with no persistent memory and no external state. Every run starts cold, and the context window is the only memory. This is ReAct in production. It works for self-contained tasks but fails on larger ones, repeating work already done and contradicting earlier decisions.
Level 2: Lifecycle inside the loop. Memory operations move inside the loop, read before the model is called and written after the agent acts. The loop becomes a reasoning engine with state. The crucial distinction here is between a memory-augmented agent (which passively retrieves and injects information) and a memory-aware agent (which actively encodes, stores, retrieves, injects, and forgets). More memory improves grounding but increases cost, latency, and the risk of injecting stale content.
Level 3: Operations inside and outside the loop. The harness becomes a system in its own right, with a deliberate boundary between programmatic operations (automatic, such as loading history) and agent-triggered operations (such as deciding to search the web). This is where context engineering and memory engineering become distinct disciplines, with techniques like context-window monitoring, conversation compaction, tool-output offloading, semantic tool discovery, idempotency, and prefix-based prompt caching.
Oracle’s debugging payoff is that most production failures (agents that repeat themselves, lose context, or produce inconsistent results across sessions) trace to a mismatch between task complexity and agent level. It also distinguishes the agent loop (online, real-time) from the training loop (offline, on curated data), and argues the two are converging at the memory layer.
The academic harness surveys
Two academic treatments formalize what the vendor blogs describe in product terms. Meng, Wang et al., in the survey Agent Harness for Large Language Model Agents (cited as arXiv:202604.0428), define the harness as a six-tuple H = (E, T, C, S, L, V): an execution loop, a tool registry, a context manager, a state store, lifecycle hooks, and an evaluation interface, and map each component to a corresponding production failure mode (execution runaway, tool misuse, context blowout, state loss, unmonitored side effects, unobservable behavior). A closely related survey by Guo, Hao et al., From Question Answering to Task Completion: A Survey on Agent System and Harness Design (arXiv:2606.20683), decomposes the execution harness into six coupled runtime responsibilities (observation, context, control, action, state, and verification) and traces the same prompt → context → harness evolution through a model-harness lens. A third paper, on necessary and sufficient conditions for an agent harness, reduces the harness to a four-element core (loop, tools, context, control) and tests the definition against six real harnesses including Claude Code, Codex CLI, Aider, Cline, OpenHands, and SWE-agent. Different cuts, same load-bearing walls.
Where They Agree, and Where They Don’t
The convergence is real, but it is not uniform. The agreements are broad; the disagreements are about which wall is load-bearing.
What every source agrees on:
The core reframe is unanimous: stop hand-prompting, design the system that prompts the agent. Every source defines a loop the same way: act, observe, decide or verify, repeat until a stop condition fires. ReAct (2022) is the acknowledged ancestor in every guide that traces lineage. Stop conditions and guardrails are treated as non-optional everywhere: a hard iteration cap, a token or cost budget, and no-progress detection appear in Data Science Dojo, Tosea, Requesty, MindStudio, and AI Builder Club alike. Verification is the crux in every treatment: deterministic checks (tests, linters, compilers) are preferred, the maker and checker must be separated, and the model cannot grade its own homework. Context management is a first-class problem in all of them, with context rot as the shared enemy and compaction, pruning, and sub-agent isolation as the shared countermeasures. State must live outside the conversation (on disk, in a file, in a database) because the model forgets between runs. And every honest guide concedes that loop engineering is not always the right tool: for one-off tasks, interactive prompting is still faster.
Where they genuinely differ:
The sharpest disagreement is structural: where does the loop sit relative to the harness? Osmani places the loop one floor above the harness because he defines the harness narrowly as the environment within which a single agent runs. Towards AI, and a line of practitioner critiques, argue the opposite: that the loop lives inside the harness, and that harness is “the machine outside the model,” including the loop, tool feedback, error retries, and observability. Same components, opposite nesting. This is not a quibble; it determines whether you reach for another loop or another harness when something breaks.
The loop taxonomies slice different axes and do not map cleanly onto each other. Requesty’s four loop types (heartbeat, cron, hook, goal) are organized by trigger. MindStudio’s four patterns (retry, plan-execute-verify, explore-narrow, human-in-the-loop) are organized by control flow. Data Science Dojo’s lineage (ReAct → Reflexion → … → Ralph Loop → /goal) is organized by history. These are not contradictory; they are three different lenses on the same object, but you cannot flatten them into one list without losing the distinctions.
Each source foregrounds a different load-bearing wall as the bottleneck. AI Builder Club says it is the verifier. Tosea and Oracle say it is context and memory management. Requesty says it is cost and routing. MindStudio says it is error handling. Oracle says it is matching the memory level to the task. They are not arguing with each other; each is reporting which wall fails most often in its own experience. The practical implication is that you should read them as complementary diagnostics, not competing theories.
The stacked-loop models are also different shapes. Oracle’s three levels describe memory and context maturity (cold loop → stateful loop → full harness system). AI Builder Club’s three loops, via Andrew Ng, describe nesting at different cadences (agent → developer → world). These are orthogonal: Oracle’s levels run inside Ng’s inner loop. Conflating them, as some summaries do, is the most common misreading of this literature.
Finally, there is a register difference that matters for how you use these sources. The academic surveys (Meng et al., Guo et al.) formalize the harness as a six-tuple with precise failure-mode mappings and test the definition against real systems. The vendor blogs frame the same components as product features with shipping names. Same walls, different blueprints; read the surveys for rigor and the blogs for what to type into your tool today.
The Six-Component Harness Model
What did all those guides agree on? Architecture.
Multiple sources now decompose the agent harness into six components. AI Builder Club states it cleanly. Meng et al.’s harness survey formalizes a closely related six-tuple in academic language. Different labels, same load-bearing walls.
ComponentQuestion it answersWhen it is missingContextWhat does the model see this iteration?Quality varies run to run; constraints get forgottenToolsWhat can the agent touch?Hallucinated actions; wrong tool selectionOrchestrationWhat happens next?Brilliant fragments, no coherent wholeStateWhat persists?Every session starts from zeroEvaluationWas it right?Confident garbage; undebuggable runsRecoveryWhat if it breaks?One bad step kills the run
Read that table as a diagnostic, not a shopping list. Most teams I talk to are strong on tools, passable on context, and near-zero on evaluation and recovery. That is exactly why agent demos look great and production deployments fail quietly.
Loop engineering lives inside this harness. The harness is the environment. The loop is the cycle that drives work toward a goal. You need both. A loop without a harness is a script that calls an API in a while block. A harness without a loop is a well-instrumented chat session.
Osmani’s Six Primitives: The Product Map
Addy Osmani’s June essay maps the same ideas to shipping tools rather than abstract components. The names differ because the audience differs. Architects think in context and evaluation. Builders think in cron jobs and worktrees.
Osmani primitiveHarness component it implementsAutomationsOrchestration (scheduled discovery and triage)WorktreesRecovery + orchestration (parallel isolation)SkillsContext (project knowledge injected each run)Plugins / connectorsTools (MCP, external systems)Sub-agentsOrchestration + evaluation (maker/checker split)External stateState (memory outside the conversation)
The mapping is not one-to-one. Worktrees also serve recovery. Sub-agents also manage context firewalls. But the point holds: the products that matter in 2026 ship the same primitives because the underlying problem is the same.
Claude Code and OpenAI Codex both expose /goal, cron scheduling, skills, MCP connectors, sub-agents, and file-based state. The argument is no longer which tool wins. It is whether you designed a loop that still works when you swap the runtime.
Oracle’s Three Levels: Stop Debugging One Loop
Oracle published The Agent Loop Decoded by Richmond Alake on June 11, 2026, framing agent systems as three stacked levels of memory and context maturity rather than a single observe-think-act diagram. Its central claim is that most production failures (agents that repeat themselves, lose context, or produce inconsistent results across sessions) trace to a mismatch between task complexity and agent level.
The three levels, as Oracle describes them:
Level 1: LLM + Tools + Response. The minimal loop: an LLM that can call tools and return a response, with no persistent memory and no external state. Every run starts cold and the context window is the only memory. This is ReAct in production. It works for self-contained tasks and fails on larger ones by repeating work already done and contradicting earlier decisions.
Level 2: Lifecycle inside the loop. Memory operations move inside the loop, read before the model is called and written after the agent acts. The loop becomes a reasoning engine with state. The crucial distinction here is between a memory-augmented agent (passively retrieves and injects information) and a memory-aware agent (actively encodes, stores, retrieves, injects, and forgets). More memory improves grounding but increases cost, latency, and the risk of injecting stale content.
Level 3: Operations inside and outside the loop. The harness becomes a system in its own right, with a deliberate boundary between programmatic operations (automatic, like loading history) and agent-triggered operations (like deciding to search the web). This is where context engineering and memory engineering become distinct disciplines, with techniques like context-window monitoring, conversation compaction, tool-output offloading, semantic tool discovery, idempotency, and prefix-based prompt caching.
The debugging payoff is immediate. When an agent fails, do not ask “is the model hallucinating?” Ask which level broke. Fix Level 1 with better tool schemas and smaller tool menus (Oracle’s “46-tool collapse” warning). Fix Level 2 with deliberate memory operations and relevance thresholds against noisy retrieval. Fix Level 3 with compaction, offloading, and a clean boundary between what is automatic and what the agent decides. Oracle’s contribution is naming what experienced builders already learned the hard way: you cannot debug a three-level system if you draw it as one circle.
How the Taxonomies Fit Together
Three frameworks, one system:
The harness components are horizontal infrastructure. Oracle’s stacked levels describe how much memory and context management the loop has. Osmani’s primitives are the product features that implement both. Andrew Ng’s three nested loops describe cadence; they run at different speeds, with Oracle’s levels living inside Ng’s innermost loop.
None of these taxonomies compete. They are different zoom levels on the same machine.
What to Build First
The curriculum agrees on a boring starting point. That is a good sign.
Pick one recurring task you already do manually (triage unlabeled issues, review stale PRs, sweep red CI).
Write a testable done condition before you write loop logic. “All tests pass” is a loop goal. “Make it better” is a token bonfire.
Wire the six harness components minimally. Context via a skill file. Tools via one MCP server. State via a JSON file in the repo. Evaluation via a deterministic check. Recovery via a hard iteration cap and escalation to you.
Separate maker from checker. The agent that writes must not be the agent that grades. Claude Code’s
/goalimplements this by running a separate evaluator model on each turn. You can replicate the pattern with a sub-agent or a pytest gate.Log at the right level. Level 1 logs tool arguments and schema results. Level 2 logs plan state and stop reasons. Level 3 logs delegation edges and permission scope.
Skip the elaborate multi-agent fleet until a single loop with a real verifier works unattended once. The guides that age well all say the same thing: prefer the simplest loop that could work.
The Honest Caveats
Loop engineering is real and overhyped at the same time.
The skeptics are right that a while loop with an LLM call is not new. Kubernetes controllers and CI pipelines have been doing observe-act-verify cycles for years. The new part is that the act step is a stochastic model and the verify step must be designed for ambiguity.
The economics are real too. Long-running loops burn tokens. Unattended loops with weak verifiers do not fail loudly; they fail expensively. Interactive prompting is still faster for one-off tasks. Loop engineering pays off when the work is repetitive, the goal is checkable, and the loop can run while you do something else.
And the human does not leave the system. You still own the goal, the definition of done, and the judgment call when the verifier and the task disagree. Loop engineering moves the leverage point. It does not remove responsibility.
What the Convergence Means
When seven independent platforms ship compatible curricula within weeks, three things are true.
First, the bottleneck has shifted. The model can generate. The scarce skill is designing the verifier, the stop condition, and the state that makes generation converge on something shippable.
Second, harness engineering and loop engineering are now paired vocabulary. Context, tools, orchestration, state, evaluation, recovery describe the environment. The stacked loops describe the motion inside it. You need both lenses.
Third, the practitioners at the center of the tools are already living this way. Osmani, Steinberger, and Cherny are not selling a course. They are reporting how they work. The bootcamps and vendor guides are catching up to a practice that was already happening in production.
Loop engineering is teaching material now. That does not mean you need a certificate. It means the pattern has enough shared structure that you can stop inventing vocabulary from scratch and start stealing the parts that survived contact with real agents.
Build one loop this week. Give it a verifier you trust. Write the state to disk. Cap the iterations. Then decide whether you need level two or level three, not before.
The curriculum is telling you where the field thinks the leverage is. The field is not wrong about that part.
References
Addy Osmani, “Loop Engineering.” https://addyosmani.com/blog/loop-engineering/
Peter Steinberger, June 7, 2026 post on designing loops (cited across Data Science Dojo, Tosea.ai, AI Builder Club guides).
The New Stack, “The Anthropic leader who built Claude Code says he ditched prompting.” https://thenewstack.io/loop-engineering/
Data Science Dojo, “Agentic Loops Explained: From ReAct to Loop Engineering.” https://datasciencedojo.com/blog/agentic-loops-explained-from-react-to-loop-engineering-2026-guide/
Tosea.ai, “What Is Loop Engineering? A Complete Guide.” https://tosea.ai/blog/loop-engineering-ai-agents-complete-guide-2026
Requesty, “Loop Engineering: How to Build AI Agent Loops That Run Themselves.” https://www.requesty.ai/blog/loop-engineering-how-to-build-ai-agent-loops-that-run-themselves
MindStudio, “What Is Loop Engineering? The New Meta for AI Coding Agents.” https://www.mindstudio.ai/blog/what-is-loop-engineering-ai-coding-agents
AI Builder Club, “Loop Engineering Guide (2026).” https://www.aibuilderclub.com/blog/loop-engineering-guide-2026
AI Builder Club, “The 6 Components of a Production Agent Harness.” https://www.aibuilderclub.com/blog/harness-six-components
Towards AI, “Loop Engineering vs Harness Engineering.” https://pub.towardsai.net/loop-engineering-vs-harness-engineering-when-to-use-each-and-why-most-teams-confuse-them-df1e0c3d21da
Oracle Developers, “The Agent Loop Decoded: Three Levels Every Agent Engineer Must Know” (Richmond Alake, June 11, 2026). https://blogs.oracle.com/developers/the-agent-loop-decoded-three-levels-every-agent-engineer-must-know
Andrew Ng, late June 2026 Batch letter on three nested loops (cited in AI Builder Club loop engineering guide).
Meng, Wang et al., “Agent Harness for Large Language Model Agents” (cited as arXiv:202604.0428). Six-tuple harness formalism H = (E, T, C, S, L, V).
Guo, Hao et al., “From Question Answering to Task Completion: A Survey on Agent System and Harness Design.” https://arxiv.org/abs/2606.20683
“Necessary and Sufficient Conditions for an Agent Harness.” https://arxiv.org/html/2606.10106v1
If you are a paid subscriber, thank you. Your support makes this work possible.
If you are a free subscriber and find these articles useful, please consider upgrading. A paid subscription is $80 per year or $8 per month.
Free subscribers typically receive access to the full versions of paid articles after one to two months.
If this helped you, please consider subscribing to my Substack newsletter.
Likes, comments, and shares really do make a difference. They help grow the channel, support the work, and get these ideas in front of more builders who are trying to understand AI agents, harness engineering, and production AI systems.
Thank you for reading and for helping the work reach more people.
About the Author — Claude Certified Architect
Rick Hightower is a former Senior Distinguished Engineer at a Fortune 100 company, focusing on delivering ML / AI insights to front-line applications, and a practitioner building multi-agent production systems. Follow him on SubStack and Medium for more hands-on agent engineering content. You can also book him to speak and train your team: Check out Rick Hightower’s SpeakerHub.
Rick Hightower helps companies become AI-first through practical mentoring, executive and team training, and custom AI solution development. He is a former Senior Distinguished Engineer at a Fortune 100 company, where he focused on bringing ML and AI insights into real front-line business applications.
Subscribe to Rick’s newsletter to see videos and guides.
Rick is a Claude Certified Architect, AI systems practitioner, and builder of production multi-agent systems. He is currently working on authoring a book on Harness Engineering with Manning Publishing. He created Skilz, a universal agent skill installer supporting 30+ coding agents, including Claude Code, Gemini, Copilot, and Cursor, and co-founded one of the largest agentic skill marketplaces.
Today, Rick and the Spillwave team work with leaders and teams who want to move beyond AI experiments and build real AI capability inside their companies. He helps organizations adopt AI safely, train their people, redesign workflows, and build practical AI systems that create measurable business value.
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.