Loop Engineering vs Plan-and-Execute
Sequential planning patterns vs iterative loop systems — how modern loop engineering absorbs and extends the plan-execute paradigm.
The Plan-and-Execute pattern is one of the most influential agent architectures in modern AI systems. It introduced the idea that an agent should create a structured plan before acting — then execute that plan step by step. It was a breakthrough over earlier approaches like simple ReAct, and it remains widely used in tools from LangChain to Windsurf. But it has a fundamental limitation: plans go stale.
Loop engineering — coined by Addy Osmani (Google Cloud AI Director) and Peter Steinberger in June 2026 — solves this by embedding plan-and-execute inside a continuous feedback loop. The result is a system that plans, executes, observes the results, and replans when reality diverges from expectations.
This article defines both patterns precisely, explains why naive plan-and-execute fails in production, and shows how loop engineering absorbs and extends the paradigm into something more robust.
What Is Plan-and-Execute?
The Plan-and-Execute pattern is an agent architecture where the system first generates a complete, multi-step plan — then executes that plan one step at a time. The plan is created upfront, before any actions are taken. Once created, execution follows the plan's sequence until completion.
┌───────────────────────────────────────────────────────────┐
│ Plan-and-Execute Pattern │
│ │
│ ┌─────────────────┐ │
│ │ PLANNING │ Generate a complete, │
│ │ PHASE │ ordered list of steps │
│ │ (single pass) │ │
│ └────────┬────────┘ │
│ │ │
│ v │
│ ┌─────────────────┐ │
│ │ Step 1 │ │
│ │ Step 2 │ Execute steps in order │
│ │ Step 3 │ No feedback to the plan │
│ │ Step 4 │ │
│ │ ... │ │
│ └────────┬────────┘ │
│ │ │
│ v │
│ ┌─────────────────┐ │
│ │ DONE │ │
│ └─────────────────┘ │
└───────────────────────────────────────────────────────────┘
The key architectural property is separation of planning from execution. The agent uses its full context and reasoning capacity to create the plan, then switches to execution mode where it follows the plan without re-evaluating the overall strategy. This is in contrast to ReAct, where planning and execution are interleaved at every step — the agent reasons, acts, observes, and re-plans continuously.
The LLM Research Origins (2023-2024)
Plan-and-Execute emerged from LLM research as a response to the limitations of the ReAct pattern. In the ReAct cycle, the agent interleaves reasoning and action at every step — think, act, observe, think, act, observe. This is flexible but can be inefficient: the agent may "discover" the same information multiple times, lose track of the big picture, or waste reasoning capacity on decisions that should have been made upfront.
The Plan-and-Execute pattern was popularized by several influential works:
-
LangChain's Plan-and-Execute agent (2023), which formalized the pattern as a distinct agent type. LangChain provided a
PlanAndExecuteclass that separated the planning LLM call from the execution step loop, with a replanner that could regenerate the plan after each step. This became one of the most used agent patterns in the LangChain ecosystem. -
LATS: Language Agent Tree Search (Zhou et al., 2023), which combined tree search with plan evaluation. The agent generated multiple candidate plans, evaluated them, and executed the best one — adding a selection step before execution.
-
Voyager (2023), the Minecraft-playing agent from NVIDIA, which used a skill library combined with automatic planning. Voyager would plan a sequence of actions to achieve a goal, execute them, and store successful patterns as reusable skills — a form of plan reuse across episodes.
-
ProAgent and related systems (2023-2024) that demonstrated plan-and-execute in software engineering contexts, where agents created a fix plan before modifying code.
The appeal was clear: planning upfront produced more coherent, globally-optimal strategies. An agent that plans first can see the entire task before committing to any action, avoiding the myopia that plagues purely reactive systems.
The Problem: Plans Go Stale
For all its advantages, the Plan-and-Execute pattern has a critical weakness: the plan is created based on assumptions about the world, and the world changes as soon as you start executing.
This is not a hypothetical problem. It manifests in several well-documented failure modes:
Stale Plans from Environment Changes
In a software engineering context, the agent creates a plan to refactor a module. The plan says: "Step 1: Extract the validation logic into a utility function. Step 2: Update the three callers to use the utility. Step 3: Run the tests." During Step 2, the agent discovers that one of the three callers has a different validation pattern than expected — it uses a custom validator class instead of inline logic. The plan assumed uniform callers. Now the plan is wrong, but the agent is already committed to executing it.
Without a feedback mechanism, the agent either blindly follows the stale plan (producing incorrect code) or deviates from the plan without understanding the full implications of the deviation.
Cascading Failures from Incorrect Assumptions
A plan is only as good as its assumptions. In code modification tasks, assumptions include: "This function is only called from these three locations," "This module has no runtime dependencies on that module," "Changing this parameter name will not break the API." Each assumption is a potential failure point.
When Step 1 fails because an assumption was wrong, Steps 2 through N may all be invalid as well. In a pure plan-and-execute system, the agent has no mechanism to detect this — it continues executing steps that were designed for a world that no longer exists.
No Error Recovery Architecture
When a step fails — the command returns an error, the test fails, the file does not exist — the plan does not say what to do. The original plan was designed for success. There is no "Plan B" baked into the execution sequence.
The agent is forced to improvise error recovery in real time, using the same reasoning capacity that created the plan in the first place. But now the reasoning context includes the failed step, the error message, and the remaining plan — all competing for attention. This is exactly the situation where structured recovery mechanisms, rather than ad-hoc reasoning, are most needed.
The Replanner Is Not the Same as a Loop
Some implementations of Plan-and-Execute include a "replanner" — a component that regenerates the plan after a step fails. This is an improvement over pure plan-and-execute, but it is still fundamentally different from a loop engineering approach:
Plan-and-Execute with Replanner:
Plan → Execute Step 1 → Fail → Replan → Execute Step 1' → ...
Loop Engineering:
Plan → Execute Step 1 → Observe Result → Verify →
(Pass → Next Step) / (Fail → Diagnose → Replan → Re-execute)
The replanner regenerates the entire plan from scratch. It does not systematically diagnose what went wrong, it does not verify partial progress, and it does not maintain a structured understanding of what has already succeeded. It is a blunt instrument where a surgical one is needed.
Loop Engineering: Plan-and-Execute with a Feedback Loop
Loop engineering solves the stale-plan problem by wrapping plan-and-execute inside a continuous feedback loop. The fundamental insight is simple: planning without observation is guessing. Planning with observation is engineering.
The loop engineering version of plan-and-execute looks like this:
┌─────────────────────────────────────────────────────────────────┐
│ Loop Engineering: Plan-Execute with Feedback │
│ │
│ ┌───────────┐ ┌──────────┐ ┌──────────┐ ┌────────┐ │
│ │ │ │ │ │ │ │ │ │
│ │ PLAN │───>│ EXECUTE │───>│ OBSERVE │───>│VERIFY │ │
│ │ │ │ step │ │ results │ │against │ │
│ │ (generate │ │ │ │ │ │ goals │ │
│ │ or re- │ │ │ │ │ │ │ │
│ │ plan) │ │ │ │ │ │ │ │
│ └────▲──────┘ └──────────┘ └──────────┘ └───┬────┘ │
│ │ │ │
│ │ ┌──────────┐ │ │
│ └─────────│ REPLAN │<────────── FAIL ───────────┘ │
│ │ (diagnose│ │
│ │ failure, │ ┌──────────┐ │
│ │ adjust │ │ COMPLETE │<──── PASS ────┤
│ │ strategy)│ │ │ │
│ └──────────┘ └──────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
The critical difference: every execution step produces an observation, every observation is verified against the goal, and every failure triggers a structured replan. The plan is not a fixed document — it is a living artifact that is continuously updated based on reality.
The Core Loop: Plan, Execute, Verify, Replan
The advanced pattern that loop engineering adds to plan-and-execute is a four-phase cycle that repeats until convergence:
-
Plan: Analyze the current state and the goal. Generate or update a plan that bridges the gap. The plan accounts for what has already been accomplished and what is known about the current state of the environment.
-
Execute: Take the next action from the plan. This is the same as plan-and-execute's execution phase — but it is always a single step, not the entire remaining plan.
-
Verify: Check the result against expectations. Did the action produce the intended outcome? Run tests, check file contents, validate outputs. This is the phase that plan-and-execute lacks entirely.
-
Replan: If verification failed, diagnose the failure, understand why reality differs from the plan, and generate an updated plan. If verification passed, move to the next step. If all steps are complete and verified, terminate.
This cycle — Plan → Execute → Verify → Replan — is the loop engineering evolution of plan-and-execute. It preserves the global coherence of upfront planning while adding the adaptability of continuous feedback. The plan is a starting point, not a contract.
Why This Works: Control Theory for Agents
The relationship between plan-and-execute and loop engineering mirrors a fundamental principle from control theory. Open-loop control (no feedback) works when the system model is perfect and the environment is predictable. Closed-loop control (with feedback) works even when the model is approximate and the environment is noisy.
Plan-and-execute is open-loop control. The plan is a model of how the task should proceed. If the model is perfect — if every assumption is correct and the environment never changes — the plan executes flawlessly. But in real software engineering tasks, the model is always approximate, and the environment always changes.
Loop engineering is closed-loop control. The verification step is the sensor that measures the actual state of the system. The replan step is the controller that adjusts the strategy based on the measured state. The result is a system that converges on the goal even when individual steps fail, because each failure is detected and corrected.
Detailed Comparison
The structural differences between plan-and-execute and loop engineering manifest across every dimension of the system:
| Dimension | Plan-and-Execute | Loop Engineering |
|---|---|---|
| Planning phase | Single upfront pass, generates complete plan | Continuous — initial plan plus replanning after every step |
| Plan flexibility | Static — plan is fixed after creation | Dynamic — plan updates based on execution observations |
| Execution model | Sequential steps from the plan | Steps driven by the current plan state |
| Observation | Per-step, but no structured verification | Per-step, with mandatory verification against goals |
| Error detection | Relies on LLM noticing errors in observation | Explicit verification step catches errors systematically |
| Error recovery | Ad-hoc — LLM improvises when steps fail | Structured — diagnose root cause, replan, re-execute |
| Adaptability | Low — plan was designed for an assumed state | High — plan evolves as understanding of the system deepens |
| Replanning | Regenerates entire plan (if implemented at all) | Surgical — replans only the affected portion, preserving progress |
| Convergence guarantee | None — may diverge or loop indefinitely | Explicit — convergence criteria, max iterations, timeout |
| State management | Implicit — state accumulates in conversation | Explicit — structured state tracked across iterations |
| Termination | When all plan steps are executed | When goals are verified as met (or convergence criteria trigger) |
| Verification | Optional, post-hoc | Mandatory, per-step, built into the cycle |
| Best for | Well-understood tasks with predictable environments | Complex, uncertain tasks where assumptions may be wrong |
Where Plan-and-Execute Alone Still Works
Plan-and-execute is not obsolete. It remains the right choice in specific scenarios:
-
Well-scoped, well-understood tasks. When the agent's model of the environment is accurate and the task has no hidden dependencies. Example: "Create a REST API with five endpoints based on this OpenAPI spec." The spec defines everything. There is little to discover during execution.
-
Environments that do not change during execution. When the codebase is not being modified by other agents or humans while the plan runs. The plan's assumptions remain valid throughout.
-
Simple multi-step tasks where each step is independent. "Run the linter. Then run the type checker. Then run the tests." Each step's success does not depend on the others, and failures do not cascade.
-
Tasks where the cost of replanning outweighs the cost of a failed plan. Very quick tasks where spending time on observation and verification would slow things down more than occasionally retrying from scratch.
Where Loop Engineering Is Necessary
Loop engineering becomes essential when:
-
Tasks involve modifying unfamiliar code. The agent does not know the full dependency graph, the implicit contracts, or the hidden coupling between modules. Every step may reveal something unexpected that invalidates the plan.
-
Multi-file refactoring across large codebases. Changing an interface in one file can break callers across dozens of others. The plan cannot predict all callers, but the verify step catches each breakage as it occurs.
-
Tasks with external dependencies. When the agent interacts with databases, APIs, file systems, or network resources that may behave unexpectedly. The verify step catches mismatches between the plan's assumptions and reality.
-
Long-running autonomous tasks. When no human is available to detect plan staleness and trigger a replan. The loop itself must detect and correct problems.
-
Production-critical correctness requirements. When the cost of an error is high — security vulnerabilities, data corruption, service outages. The verification step is non-negotiable.
Real-World Implementations
The evolution from plan-and-execute to loop engineering is not theoretical — it is visible in the architecture of every major AI coding tool. Each tool implements the pattern at a different point on the spectrum.
Claude Code: Plan-Execute Within a Verification Loop
Claude Code (github.com/anthropics/claude-code), Anthropic's terminal-based coding agent, exemplifies the loop engineering approach. When Claude Code receives a complex task, it does not just execute blindly — it creates an internal plan, executes steps, observes results, and adjusts.
The /goal command makes this explicit. When you define a verifiable goal — "all tests pass and lint is clean" — Claude Code enters a loop: plan the approach, execute code changes, run the verification commands (tests, linter), observe the output, and iterate if verification fails. This is textbook loop engineering applied to plan-and-execute.
Critically, Claude Code uses a separate verification model. The model that writes the code is not the one that evaluates whether the task is done. This maker/checker split means the verifier has no investment in the plan — it can objectively assess whether the plan succeeded. This addresses one of plan-and-execute's deepest failure modes: the executor assuming its own plan was correct.
Claude Code's CLAUDE.md project files define verification commands, constraints, and conventions that the agent follows across every iteration. This is the loop engineering equivalent of a control system's reference signal — a persistent, externally-defined standard that the loop converges toward, independent of the agent's internal planning.
# The loop engineering workflow in Claude Code:
claude
> /goal All tests pass, lint is clean, no TypeScript errors
# Claude Code now runs the Plan → Execute → Verify → Replan cycle
# autonomously until the goal condition is met
Windsurf Cascade: Planning Agent and Execution Agent with Feedback
Windsurf (windsurf.ai), the AI-powered IDE by Codeium, implements a particularly clear separation of planning and execution through its Cascade architecture. Cascade uses two distinct agent roles: a Planning Agent and an Execution Agent.
The Planning Agent analyzes the task, understands the codebase context, and generates a structured plan. The Execution Agent implements the plan by writing and modifying code. The key innovation is the feedback channel between them: when the Execution Agent encounters something the plan did not anticipate — a hidden dependency, an unexpected error, a changed API — it feeds that information back to the Planning Agent, which updates the plan.
┌─────────────────────────────────────────────────────────┐
│ Windsurf Cascade │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ PLANNING AGENT │────────>│ EXECUTION AGENT │ │
│ │ │ plan │ │ │
│ │ - Analyze │ │ - Write code │ │
│ │ - Decompose │ │ - Edit files │ │
│ │ - Generate │ │ - Run commands │ │
│ │ plan │ │ │ │
│ │ │ │ │ │
│ │ - Replan │<────────│ - Feedback │ │
│ │ (update │ error │ (unexpected │ │
│ │ based on │ │ errors, │ │
│ │ feedback) │ │ discoveries) │ │
│ └─────────────────┘ └─────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
This is a two-agent realization of the loop engineering pattern. The Planning Agent holds the global strategy. The Execution Agent holds the local implementation knowledge. The feedback channel ensures that execution discoveries flow back into planning decisions. It is more structured than a single agent that both plans and executes, because the two roles have different contexts and different failure modes.
Windsurf's Cascade architecture demonstrates that the plan-and-execute separation is valuable — but only when the separation includes a feedback path from execution back to planning. Without that path, it is pure plan-and-execute with all its limitations. With the path, it becomes loop engineering.
Cursor: Implicit Planning with Visual Verification
Cursor (cursor.com), the AI-powered code editor, takes a different approach. Cursor does not expose a separate planning phase to the user — the agent plans and executes within a unified flow. But the verification step is provided by the developer: after each agent action, the developer sees the result in the editor and can accept, reject, or modify it.
In loop engineering terms, the human is the verifier. The developer's visual inspection of the diff serves the same function as Claude Code's automated verification model. This works well for interactive use but does not scale to autonomous execution — the human cannot verify when the agent is running unattended.
Cursor's strength is in the speed of the plan-execute cycle. Because planning and execution are interleaved in a tight ReAct loop, the agent can adapt instantly to unexpected findings. The tradeoff is that the agent may lack the global coherence that an explicit upfront plan provides — it may paint itself into a corner by making locally good but globally suboptimal decisions.
OpenHands: Full Loop Implementation
OpenHands (github.com/All-Hands-AI/OpenHands) implements perhaps the most complete loop engineering system in an open-source agent platform. OpenHands provides a sandboxed environment where the agent can install packages, run commands, browse the web, and write code. The system implements explicit verification stages, timeout-based termination, and structured error recovery — all core loop engineering patterns.
OpenHands' execution loop is: plan the approach, implement a step, run relevant tests or checks, observe the output, and decide whether to proceed to the next step or replan. The sandbox provides isolation so that failed experiments do not corrupt the host environment, and the observation mechanism captures structured output that the agent can reason about precisely.
SWE-Agent: Research-Grade Loop Engineering
SWE-Agent (github.com/princeton-nlp/SWE-Agent) applies loop engineering to software engineering tasks with academic rigor. The agent operates in a structured loop: localize the relevant code (search strategy), generate a patch, run tests, observe results, and iterate. Each phase has explicitly designed strategies, and the system logs show clear convergence patterns for research analysis.
SWE-Agent's approach to planning is particularly instructive. It uses a search strategy phase before any code modification — effectively a planning step that identifies the relevant files and functions. But this planning step is followed by continuous observation and adaptation as the agent implements and tests changes. The plan is a starting point for exploration, not a fixed sequence.
The Architectural Spectrum
Plan-and-execute and loop engineering are not binary alternatives — they exist on a spectrum of feedback sophistication:
NO FEEDBACK FULL FEEDBACK
│ │
┌────┴────┐ ┌──────────────┐ ┌───────────────┐ ┌─────┴────┐
│ Pure │ │ Plan-Execute │ │ Loop Engi- │ │ Full Loop│
│ Plan- │ │ with Replanner│ │ neered │ │ with Sub-│
│ Execute │ │ (regenerate │ │ Plan-Execute │ │ loops & │
│ │ │ on failure) │ │ (per-step │ │ maker/ │
│ │ │ │ │ verify + │ │ checker │
│ │ │ │ │ replan) │ │ splits │
└─────────┘ └──────────────┘ └───────────────┘ └──────────┘
At the left end: the plan is created once and executed blindly. At the right end: every step is verified, failures trigger diagnosis and surgical replanning, and complex tasks are decomposed into sub-loops with independent verification.
Most production systems in 2026 operate somewhere in the middle. Claude Code is close to the right end with its /goal command and separate verification model. Cursor is in the middle with its interleaved plan-execute and human verification. Tools that use a simple replanner on failure sit between the left and middle positions.
The direction of travel is clear: the industry is moving rightward. Every iteration of every major tool adds more feedback, more verification, and more structured replanning. The end state is loop engineering — not because it is a new paradigm, but because it is the natural maturity of the plan-and-execute pattern.
When to Use Each Approach
Decision Framework
| Situation | Recommended Approach | Rationale |
|---|---|---|
| Task is well-understood with predictable environment | Plan-and-execute | Planning cost is low, assumptions are accurate, verification overhead is unnecessary |
| Multi-file refactoring in a large codebase | Loop engineering | Hidden dependencies make planning unreliable; verification catches cascading failures |
| Simple file creation from a spec | Plan-and-execute | The spec defines everything; there is little to discover during execution |
| Bug fix in unfamiliar code | Loop engineering | The agent must explore and discover before it can plan effectively |
| CI/CD pipeline automation | Loop engineering | No human verifier available; the loop must detect and correct its own errors |
| Interactive coding with human review | Plan-and-execute (human is the verifier) | Human observation provides the feedback without explicit loop engineering scaffolding |
| Long-running autonomous task (>10 steps) | Loop engineering | Plans degrade over many steps; continuous verification prevents error accumulation |
| Content generation (docs, comments) | Plan-and-execute | No mechanical verification possible; observation adds little value |
| Migration between frameworks | Loop engineering | High complexity, many hidden dependencies, each step may reveal new constraints |
The Practical Heuristic
A simple heuristic: if you can write a test that verifies the task is done, use loop engineering. If you cannot, plan-and-execute is sufficient.
This heuristic works because the verification step — the "V" in Plan-Execute-Verify-Replan — requires a checkable condition. When such a condition exists (tests pass, types check, build succeeds, API responds correctly), the verification step adds enormous value by catching errors early and triggering replanning. When no such condition exists (the documentation reads well, the code style is consistent, the UI looks good), the verification step cannot provide structured feedback, and the full loop engineering machinery is unnecessary.
Key Takeaways
| Takeaway | Explanation |
|---|---|
| Plan-and-Execute creates structure, Loop Engineering adds resilience | Planning upfront produces coherent strategies; the feedback loop ensures those strategies survive contact with reality |
| Plans are models; models are always wrong about something | Every plan makes assumptions. In real tasks, at least one assumption is wrong. The feedback loop catches and corrects for wrong assumptions |
| Verification is the missing ingredient in pure Plan-and-Execute | Without per-step verification, errors accumulate silently. With verification, each step's result is checked before building on it |
| Loop engineering IS plan-and-execute with a feedback loop added | The loop engineering pattern is not a replacement for plan-and-execute — it is plan-and-execute, evolved |
| The best tools implement both patterns at different scales | Claude Code uses explicit loop engineering; Cursor uses implicit plan-and-execute with human verification; Windsurf separates planning and execution agents with feedback |
| Use plan-and-execute for simple, predictable tasks; loop engineering for complex, uncertain ones | The overhead of loop engineering is justified when the cost of plan staleness exceeds the cost of verification and replanning |
| The industry is converging on loop engineering | Every major tool is adding more feedback, more verification, and more structured replanning over time |
The evolution from plan-and-execute to loop engineering is not a revolution — it is an engineering maturation. Plan-and-execute taught the field that agents benefit from structured planning before acting. Loop engineering completes the lesson: agents benefit equally from structured observation after acting. Together, planning and observation form the closed loop that transforms agent systems from brittle, assumption-dependent scripts into robust, reality-adaptive engineering systems.