# Loop Engineering: designing the loops that guide AI agents

The bottleneck in AI agents has shifted from the prompt sentence to the loop design: trigger, topology, verifier, and stop rules. This guide teaches loop engineering fundamentals — from the base ReAct loop to a pattern catalogue — with real examples from my own system and a step-by-step guide for engineering any loop safely.

- URL: https://fernando.moretes.com/studies/loop-engineering-agentes-de-ia

- Markdown: https://fernando.moretes.com/studies/loop-engineering-agentes-de-ia/study.md?lang=en

- Type: Guide / Deep Dive

- Domain: IA / Agentes

- Date: 2026-06-29

- Tags: loop-engineering, ai-agents, ReAct, agentic-systems, LLM, orchestration, bedrock, stop-rules

- Reading time: 8 min

---

In June 2026, Addy Osmani published an essay that named something many engineers already felt but couldn't articulate: building AI agents is no longer about writing better prompts — it's about designing the loops that make the prompt work. Boris Cherny, creator of Claude Code, literally said his job now is 'writing the loops that drive Claude'. Peter Steinberger summarised it: 'stop prompting your agents and start designing the loops that prompt them'. If you come from software and have never built an AI agent, this guide starts from zero: what an agentic loop is, why it breaks, and how to engineer it with the same discipline you apply to any distributed system.

## What you will learn

- The conceptual shift: why prompt engineering gave way to loop engineering
- The 4 components of every loop: trigger, topology, verifier, stop rules
- The base ReAct loop (perceive → reason → act → observe) step by step
- Catalogue of 5 patterns with trade-offs: retry, plan-execute-verify, reflection, while-not-done, human-in-the-loop
- The control plane: verifiable stop rules, budgets, circuit breakers, observability, idempotency
- Real examples from my own system (article generation, e-book, audio, keepalive)

## Quick glossary — loop engineering terms

- **Loop Engineering:** The discipline of designing the control cycle that governs an AI agent: what fires it, how it iterates, when it stops, and who verifies the result.
- **Trigger:** The event that starts the loop: a user message, a cron job (schedule), a queue event, or another agent.
- **Topology:** The shape of the loop: single-agent (one agent iterates alone), sub-loops (parallel or sequential child agents), or an agent graph.
- **Verifier:** The component that decides whether the result is acceptable. MUST be an automatic, verifiable check — not the agent's self-evaluation (which is biased).
- **Stop Rule:** Verifiable criterion that ends the loop: goal met, iteration ceiling, token/cost budget exhausted, or no-progress detection.
- **Budget:** Explicit resource limit (tokens, cost in USD, time in seconds) allocated to the loop. When exhausted, the loop stops — regardless of the result.
- **No-Progress:** State where the agent iterates but the output does not change (stable external state). Detected by hashing or diffing consecutive iterations.
- **Circuit Breaker:** Resilience pattern (same as in microservices): after N consecutive failures, the loop opens the circuit and stops retrying, avoiding budget waste.
- **ReAct:** Base loop pattern (Yao et al., 2022): Reason + Act. The agent reasons about state, acts (calls a tool), observes the result, and repeats.
- **Reflection / Reflexion:** Pattern (Shinn et al., 2023) where the agent generates a critique of its own error, stores it in memory, and injects it into the next attempt. Each cycle roughly doubles token cost (estimate).

## The shift: from prompt engineering to loop engineering

For years, the conventional wisdom was: if the model gets it wrong, improve the prompt. That worked when an agent was essentially a single call — you send a question, get a response, done. Think of it as a pure function: `f(prompt) → response`. The problem is that real tasks rarely fit in one call. Writing code, researching a topic, generating a long report — all require multiple steps, external tool use, and correction of intermediate errors.

When you chain those steps into a loop — the agent acts, observes the result, reasons about what to do next, and acts again — the individual prompt ceases to be the bottleneck. The bottleneck becomes the **loop design**: what fires the cycle, how the agent decides the next step, who verifies the result, and — critically — **when the loop stops**. A loop without a clear stop rule is a while(true) with a credit card: it iterates until the budget runs out or you kill the process. Loop engineering is the discipline of designing that control cycle with the same seriousness you apply to a data pipeline or a messaging system.

## The base loop: ReAct step by step

ReAct (Yao et al., 2022) is the alphabet of loop engineering. The name comes from **Re**asoning + **Act**ing. The sequence is:

1. **Observe:** the agent receives the current state — the original task, the history of prior iterations, and the result of the last action.
2. **Reason:** the agent produces a 'thought' — an internal reasoning chain that decides the next step. This is what the model writes before calling a tool.
3. **Act:** the agent executes an action — call an API, search the web, write to a file, invoke a sub-agent.
4. **Observe:** the result of the action is captured and added to context. That result feeds the next reasoning cycle.

The engineering analogy is a **control loop** from control systems: sensor → controller → actuator → sensor. Each observation is the feedback that closes the loop. What makes ReAct powerful is not any individual step — it's that **each observation changes the context of the next reasoning step**. The agent learns from what it just did, within the same session, without retraining.

## Anatomy of an engineered loop

Didactic diagram: trigger → agent loop (ReAct: reason → act → observe, with tools and memory) → verifier → stop-rule check → done or iterate. Budget and observability wrap everything. Optional human-in-the-loop gate before the verifier.

### ⚡ Trigger Zone

- User message (user)
- Cron / Event EventBridge (messaging)
- Queue SQS / SNS (messaging)

### 🧠 Agent Loop (ReAct)

- Reason chain-of-thought (ai)
- Act call tool / sub-agent (compute)
- Observe capture result (compute)
- Memory context / history (storage)
- Tools APIs / search / code (external)

### ✅ Verification Zone

- Human-in-the-Loop approval gate (user)
- Verifier auto check (not self-eval) (security)

### 🛑 Stop Rule Zone

- Stop Rule goal | iter | budget | no-progress (compute)
- DONE result emitted (edge)
- ITERATE back to reason (compute)

### 📊 Control Plane (wraps all)

- Budget tokens / cost / time (security)
- Observability trace per iteration (data)
- Checkpoint idempotent state (S3/DB) (storage)

### Flows

- user -> reason: fires
- cron -> reason: schedules
- queue -> reason: event
- reason -> act: next step
- act -> tools: calls
- tools -> observe: returns
- act -> observe: result
- observe -> memory: persists
- memory -> reason: context
- observe -> hitl: if high risk
- observe -> verifier: submits
- hitl -> verifier: approves
- verifier -> stoprule: pass/fail
- stoprule -> done: goal met
- stoprule -> iterate: not yet
- iterate -> reason: next iteration
- budget -> stoprule: forces stop
- obs -> checkpoint: trace per iter
- checkpoint -> reason: resume after failure

## The 4 components of every loop — and why each matters

Every agentic loop, regardless of pattern, has exactly four components you need to design explicitly:

**1. Trigger:** What starts the cycle. Can be synchronous (user message, HTTP call) or asynchronous (cron job via EventBridge, SQS queue event, another agent). The trigger choice determines the loop's cadence and latency contract.

**2. Topology:** The shape of the loop. Single-agent iterates alone — simple, easy to trace, but limited in parallelism. Sub-loops with sub-agents allow splitting complex tasks (e.g., each chapter of an e-book processed by an independent sub-agent), but add orchestration complexity and coordination cost.

**3. Verifier:** Who decides whether the result is acceptable. This is the most underestimated component. The classic trap is using the agent itself for self-evaluation — the model is biased toward its own output. A real verifier is external: an automated test, a database query, a schema validation, a call to another model specialised in critique.

**4. Stop Rules:** The stopping criterion. Without a verifiable stop rule, you have an infinite loop. The four fundamental stop rules are: (a) goal met by automatic check, (b) iteration ceiling, (c) token or cost budget exhausted, (d) no-progress detection. A vague criterion — 'when it looks good' — is the number-one cause of infinite loops in production.

## Loop pattern catalogue — trade-offs side by side
| Criterion | Pattern | Best for | Cost per iteration | Non-termination risk | How it terminates |
| --- | --- | --- | --- | --- | --- |
| Retry / Circuit-Breaker | Transient tool or API failures | Low (repeats same call) | Low if N is fixed | After N attempts or timeout | Generators with 2 attempts + timeout abort |
| Plan-Execute-Verify | Structured tasks with clear success criterion | Medium (3 phases per cycle) | Low-medium | Verifier passes or budget exhausts | Article generation: plan sections → write → validate schema |
| Reflection / Self-critique | High quality needed; subtle reasoning errors | High (~doubles each cycle — estimate) | Medium (can cycle on critiques without converging) | Empty critique or iteration budget | E-book chapter revision with critique stored in memory |
| While-Not-Done + Sub-agents | Long parallelisable tasks (coding agents, e-books) | High (N sub-agents × cost per chapter) | High if orchestrator lacks strong stop rule | All sub-loops complete or orchestrator aborts | Chapter-by-chapter e-book with per-chapter cache |
| Human-in-the-Loop | Irreversible or high-risk actions (publish, pay, delete) | Variable (depends on human latency) | Very low (human is the verifier) | Human approval or checkpoint timeout | Approval gate before publishing generated article |

## Real examples from my system — what I learned in practice

I build and operate several agentic loops on this site. Here are the ones that taught me the most:

**Daily article generation (EventBridge → Lambda → Bedrock):** The trigger is a cron job at 06:00. The loop uses Bedrock AgentCore Web Search to ground the content. The verifier checks whether the article has the required sections via schema. The fail-safe is critical: if the search fails, the loop does not abort — it falls back to grounding from the source text only. This is a tool-level circuit breaker, not a full-loop abort.

**Chapter-by-chapter e-book:** Instead of passing the entire book in context (which would blow the window and the cost), the loop iterates chapter by chapter. Each chapter is an independent sub-loop with its own cache. If one chapter fails, only that sub-loop reprocesses — the book's state (which chapters are done) lives in S3, not in the agent's memory.

**02:00 audio cron (idempotent):** The pointer in S3 ('which audio file has already been generated') is the source of truth. If the Lambda re-executes for any reason, it reads the pointer, detects the file already exists, and skips. This is idempotency by design — external state governs, not in-memory state.

**Keepalive loop (designed live):** To keep a long render alive within a short window, I designed a heartbeat that sends a signal every N seconds. The stop rule is simple: if the render is done (check in S3), the heartbeat stops. A meta-example of how a verifiable stop rule eliminates the non-termination problem.

## When to use each approach: one-shot × workflow × loop

### One-Shot (single call)

**Pros**
- Minimal latency, predictable cost, no non-termination risk
- Easy to test and debug

**Cons**
- Cannot correct intermediate errors, no dynamic tool use
- Limited by context window

**Verdict:** Use for simple, well-defined tasks with predictable output size.

### Workflow / Fixed DAG

**Pros**
- Deterministic, auditable, easy to monitor
- Predictable cost per execution

**Cons**
- Does not adapt to unexpected errors, requires redesign for new flows

**Verdict:** Most real production cases. Use when the flow is known and stable. Workflow + RAG solves ~80% of cases (estimate).

### Single-Agent Loop

**Pros**
- Adapts to errors, uses tools dynamically, corrects course
- Simple topology to trace

**Cons**
- Cost grows with iterations, infinite loop risk without strong stop rule
- High latency for long tasks

**Verdict:** Use for open-ended, verifiable tasks with acceptable iteration cost and explicit stop rules.

### Multi-Agent Loop / Sub-loops

**Pros**
- Real parallelism, splits very long tasks, per-subtask cache
- Failure isolated per sub-loop

**Cons**
- High orchestration complexity, coordination cost, hard to debug
- Non-termination risk if orchestrator lacks strong stop rule

**Verdict:** 2026 trend in coding agents. Use only when the task is parallelisable and coordination cost is justified.

## The control plane: where loops actually break

The hardest part of loop engineering is not the loop itself — it's the **control plane**: the set of mechanisms that ensures the loop terminates, is observable, and can be resumed after failure.

**Verifiable stop rules:** The golden rule is that every stop rule must be verifiable by an automatic check, not by the agent's judgement. 'When the article looks good' is vague. 'When the validation schema passes AND the article has more than 800 words' is verifiable. Vague criteria are the number-one cause of infinite loops.

**Explicit budgets:** Every loop must have a ceiling for tokens, cost in USD, and/or time in seconds. When the budget exhausts, the loop stops — regardless of the result. This is analogous to the `timeout` you already use on any network call. Cost grows with each iteration (especially in reflection, where it roughly doubles — estimate), so the budget is the last line of defence.

**Per-iteration observability:** Each iteration must emit a trace: what the agent thought, what action it executed, what the result was, and what the budget state is. Without this, debugging a loop in production is like debugging a distributed system without logs.

**Idempotency and resumability:** The loop's state must live in external storage (S3, database), not in process memory. If the process dies and re-executes, it reads the external state and continues from where it left off — exactly like a well-designed batch processing job.

## Step-by-step guide: how to engineer a loop

- 1. DEFINE THE GOAL and a verifiable success CHECK (not 'when it looks good' — an automated test, schema, query).
- 2. CHOOSE THE TRIGGER: synchronous (user/HTTP) or asynchronous (cron/queue/event). Define the latency contract.
- 3. CHOOSE THE TOPOLOGY/PATTERN: single-agent, plan-execute-verify, reflection, while-not-done+sub-agents, or combination. Prefer the simplest that solves the problem.
- 4. DEFINE THE VERIFIER: external, automatic, non-self-referential. What concrete check says the result is acceptable?
- 5. DEFINE STOP RULES + BUDGETS: iteration ceiling, token/cost/time budget, no-progress detection (hash/diff between iterations).
- 6. ADD OBSERVABILITY + CHECKPOINTS: per-iteration trace, state persisted externally (S3/DB) for resumability.

> **My senior read — Fernando Azevedo:** What strikes me about loop engineering is not the novelty of the concept — control loops have existed since the 1950s in control engineering. What is new is that the 'controller' is now an LLM with emergent reasoning and a per-token cost. That changes the trade-off fundamentally: each iteration costs real money and can produce non-deterministic output. The practical consequence is that stop rules and budgets stop being 'best practices' and become **business requirements**. In my experience operating these systems: (1) the most common mistake is having no external verifier — the agent self-evaluates and always thinks it's done well; (2) the second most common mistake is a vague stop rule — 'when the task is complete' without defining what 'complete' means in verifiable terms; (3) most real-world cases do not need an autonomous loop — workflow + RAG solves with far less risk. An agentic loop is for genuinely open-ended tasks where the path is not known in advance. If you know the path, use a DAG. Reserve the loop for when you don't.

> **Next up: multi-agent orchestration:** When one loop becomes many: multi-agent orchestration, inter-agent communication patterns, and how to design the control plane of a system where multiple loops run in parallel — including how to handle partial failures without aborting the entire job.

## Verdict

Loop engineering is the correct answer to the wrong question the industry asked for years: 'how do I make the model get it right with a better prompt?'. The right question is: 'how do I design the control cycle that guides the model to the correct result, verifiably, within a budget, and that stops when it should?'. The four components — trigger, topology, verifier, stop rules — are the non-negotiable minimum. The control plane (budgets, observability, idempotency) is what separates a loop that works in a demo from one that works in production. Most real systems do not need an autonomous loop — workflow + RAG solves with less risk, lower cost, and higher predictability. Use the agentic loop when the task is genuinely open-ended, verifiable, and the iteration cost is acceptable. When you do use it, engineer the loop with the same discipline you would apply to any critical distributed system.

## References

- [Agentic Loops: From ReAct to Loop Engineering (2026 Guide) — Data Science Dojo](https://datasciencedojo.com/blog/agentic-loops-explained-from-react-to-loop-engineering-2026-guide/)
- [The Agentic Loop — A Practical Field Guide — dev.to / truongpx396](https://dev.to/truongpx396/the-agentic-loop-a-practical-field-guide-mnc)
- [Anthropic — Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)
- [Yao et al. — ReAct: Synergizing Reasoning and Acting in Language Models (arXiv 2210.03629)](https://arxiv.org/abs/2210.03629)
- [Shinn et al. — Reflexion: Language Agents with Verbal Reinforcement Learning (arXiv 2303.11366)](https://arxiv.org/abs/2303.11366)
- [AWS — Amazon Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/)

## Case sources

- [Agentic Loops: From ReAct to Loop Engineering (2026 Guide)](https://datasciencedojo.com/blog/agentic-loops-explained-from-react-to-loop-engineering-2026-guide/)
- [The Agentic Loop — A Practical Field Guide](https://dev.to/truongpx396/the-agentic-loop-a-practical-field-guide-mnc)
- [Anthropic — Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)
- [Yao et al. — ReAct: Synergizing Reasoning and Acting in LLMs](https://arxiv.org/abs/2210.03629)
- [Shinn et al. — Reflexion](https://arxiv.org/abs/2303.11366)
- [AWS — Amazon Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/)