Author(s): Mike Oller

Originally published on Towards AI.

By Mike Oller | AI Tool insider

I’ve spent the last year building AI agents that do real work — not just answer questions, but write code, generate reports, schedule tasks, and interact with production systems. And I’ve learned an uncomfortable lesson:

The smarter the model gets, the more damage it can do before you realize something went wrong.

A GPT-generated poem with a hallucinated fact is harmless. A GPT-generated API call that deletes a production database is not. And the difference isn’t the model — it’s the architecture around it.

This is the problem Loop Engineering sets out to solve.

The Problem with Today’s Agent Architectures

Most AI agent systems today follow one of two patterns:

Pattern 1: The One-Shot Wonder. Feed the model a prompt, get an output. Fast, cheap, and surprisingly capable — until the task needs more than one step. Then it drifts, forgets context, and produces outputs that look right but aren’t.

Pattern 2: The ReAct Loop. Reason, act, observe, repeat. This is the foundation of most modern agent frameworks (LangGraph, AutoGen, the Microsoft Agent Framework). It’s more powerful, but it’s also ungoverned — there’s no explicit mechanism for deciding when to stop, when to change course, or when to escalate to a human.

Both patterns share a fundamental blind spot: they treat reliability as a property of the model, not of the system.

What Loop Engineering Proposes

Loop engineering re-frames the problem. Instead of asking “how do we make the model smarter?” it asks “how do we build a governance architecture that wraps around the model?”

Drawing on control theory (Wiener’s cybernetics), state machines, workflow orchestration, and reinforcement learning, the paper synthesizes six components that every reliable agent needs:

1. Goal Representation

Not just “write a blog post” but a structured definition: the task, the constraints (budget, time, safety rules), the success criteria, and the stop conditions. Without this, the agent has no fixed reference point. It’s a ship without a destination.

2. State Model

Five differentiated layers of state:

• Static state: The goal, constraints, and configuration
• Dynamic state: Current outputs, intermediate results
• Tool state: Which tools are available, their status
• Reflective state: Lessons learned from previous iterations
• Governance state: Risk budget, cost budget, remaining iterations

Most agent systems collapse all of this into a single context window. Loop engineering explicitly separates them so the agent can distinguish between “what I’m trying to do,” “what I’ve done,” and “what I’ve learned.”

3. Action Executor

A controlled boundary around tool use. Every action passes through a risk check before execution. This is the difference between an agent that can call any API it wants and one that must ask permission before spending money or modifying files.

4. Observation Collector

The observation collector captures what actually happened — not what the agent intended to happen. This distinction matters because LLMs are famously bad at self-assessment. An agent might believe it successfully saved a file when the file system returned a permissions error.

5. Evaluator

Assesses four dimensions on every iteration:

• Confidence: How sure is the agent about its next step?
• Progress: Is it getting closer to the goal or spinning its wheels?
• Drift: Has the agent wandered away from the original task?
• Risk: Could the next action cause harm or exceed budget?

6. Controller

The controller is the decision-maker. Given the evaluator’s assessment, it decides one of:

• Continue — execute the next action
• Revise — change the plan
• Rollback — undo the last action
• Escalate — ask a human
• Stop — terminate execution

This is the component most agent systems lack entirely. They have a model that decides what to do, but no mechanism for deciding whether to keep going.

Five Loop Types

Not every task needs the same loop structure. The paper identifies five:

These loops compose. A single task might cycle through planning, execution, and verification loops, all wrapped in a governance loop that keeps risk in check.

Where Current Architectures Fall Short

The paper offers a comparative analysis that’s worth laying out in full:

One-shot agents are fast and cheap but have no recovery mechanism. If the first output is wrong, you start over.

Unguided ReAct loops (the default in most frameworks) are flexible but have no formal termination condition. They keep spending tokens until the context window fills up or a human intervenes.

Workflow-orchestrated agents (e.g., Prefect, Airflow, AWS Step Functions) provide excellent traceability and governance — for the failure modes the author anticipated. The moment the task departs from the predefined graph, the system is brittle.

Loop-engineered agents are designed for the case where the plan emerges at runtime. The governance isn’t baked into a static graph; it’s baked into a dynamic policy set that applies on every iteration.

The Counterargument That Matters

The paper is unusually honest about its strongest objection:

“Mature workflow orchestration tools already provide state tracking, retries, human-approval gates, and audit logs. Isn’t loop engineering just relabeling existing capability?”

The response is worth quoting directly:

“Governance checks must run every iteration rather than only at exception points, because there is no design-time map of which iterations might fail.”

In a workflow-orchestrated system, you define the entire graph upfront. You know where the risky steps are because you placed them there. In a loop-engineered system, the plan is generated by the model at runtime. You don’t know which step 27 might be the one that tries to call an expensive API or delete a critical file. So you check at every step.

This is the core insight: when you can’t predict where the failure will happen, you need a governance layer that’s present everywhere.

When NOT to Use Loop Engineering

Refreshingly, the paper doesn’t claim universality. It explicitly identifies three cases where loop engineering is the wrong tool:

1. Event-driven and reactive systems (responding to support tickets, infrastructure alerts) — the overhead of a continuous evaluation loop adds cost without adding value
2. Deterministic ETL pipelines — if the task graph is fully known, workflow orchestration is the simpler and better choice
3. One-shot tasks — if a single model call reliably produces acceptable output, building loop infrastructure isn’t justified

This matters because it’s rare to see a framework paper draw its own boundaries so clearly. It makes the stronger claim more credible: loop engineering isn’t everything, but for the class of problems it addresses, it’s the right tool.

The Governance Theater Risk

The paper also flags a trap I’ve seen firsthand:

“A controller that logs a risk classification on every action but never withholds approval is not governing; it is narrating.”

It’s possible to implement loop engineering superficially — to produce loop traces that look rigorous while the underlying thresholds are never calibrated to actually block unsafe actions. The paper’s evaluation rubric is partly a response to this: by scoring governance independently of task outcome, it makes superficial implementation visible to an external reviewer.

But the rubric can’t fully prevent a system designed to score well rather than behave well. That’s a problem for the community, not just the paper.

The Operationalized Evaluation Framework

One of the paper’s most practical contributions is its evaluation rubric. Rather than leaving assessment as a list of hand-wavy questions, it operationalizes each dimension with:

• Strong-evidence anchors (what good looks like)
• Weak-evidence anchors (what’s clearly insufficient)
• Recommended data sources (the loop trace, final artifact)
• Scoring procedure (strong / adequate / weak / absent)

Eight dimensions are scored: goal fidelity, state continuity, recovery, termination, governance, traceability, cost awareness, and human escalation.

Two scoring rules are particularly notable:

1. Governance and human escalation should be scored independently of task outcome. An agent that completes a task by skipping an approval step should score weak on governance, even if the final output was correct.
2. Termination should be scored using defined entropy and progress policies as the reference standard. This lets different implementations be compared on the same terms.

What This Means for Practitioners

If you’re building AI agents in production today, here’s what I’d take away from this paper:

First, audit your agent’s termination logic. Does it have explicit criteria for when to stop? Or does it rely on the model’s own judgment? If it’s the latter, you have a cost exposure you haven’t measured yet.

Second, separate your state layers. Don’t cram everything into one context. Keep your goal, your current progress, your lessons learned, and your budget in explicitly separate structures.

Third, implement risk-checked action boundaries. Every tool call should pass through a gate that asks: does this action exceed our risk budget? Our cost budget? Does it require human approval?

Fourth, log loop traces. Not for the logs’ sake — because if you can’t reconstruct why an agent took a particular action, you can’t debug it, audit it, or trust it.

The Bottom Line

Loop engineering is not a universal theory of AI agents. It is a useful framework for the class of agents that must execute complex, open-ended tasks under uncertainty, where the authority to halt, revise, or escalate is treated as a first-class design object rather than an implementation detail left to the model’s own judgment.

As AI agents move from chatbots to autonomous workers — from “could you help me draft this email” to “go manage my cloud infrastructure for the next hour” — the question shifts from can they think to can they be trusted.

Loop engineering is one serious answer to that question.

Mike Oller is the founder of AI Tool Insider, where he researches and builds AI agent systems. The full Loop Engineering paper, including the evaluation rubric, comparative analysis, and controller pseudocode, is available upon request.

*If you found this valuable:

• Share it with someone building AI agents
• Follow me for more on agent architecture, reliability, and production AI
• Read the paper if you want the full framework with appendices and references*

Published via Towards AI