Skip to content

Loop Patterns and Control Strategies

There is no single “correct agent loop”

An agentic loop is a control-flow abstraction. The right pattern depends on:

  • how much of the process is known in advance,
  • how dynamic the environment is,
  • how risky the available actions are,
  • whether explicit planning is useful,
  • how important verification is,
  • whether work can run in parallel,
  • whether specialist capabilities are needed.

The better question is not:

Which agent-framework pattern should I use?

but:

Where should control flow remain deterministic, and where does model-driven decision-making create real value?

1. Simple observe → act loop

The simplest pattern is:

Goal
 ↓
Observe
 ↓
Choose next action
 ↓
Execute
 ↓
Observe result
 ↓
repeat / stop

Good fit when:

  • the task is short,
  • the next step depends on the environment,
  • only a few tools are available,
  • no long explicit plan is needed.

Example:

Investigate why this deployment is unhealthy.

The model may choose:

query deployment
→ inspect event
→ query relevant metric
→ explain

ReAct-style mental model

The literature often describes interleaved reasoning and action as ReAct.

From an engineering perspective, the important structure is:

observation
 ↓
next-action decision
 ↓
tool action
 ↓
new observation

A production runtime does not need to persist a long hidden reasoning transcript. An explicit decision can be enough:

{
  "action": "QUERY_METRIC",
  "reason_summary": "Error rate rose after config reload",
  "arguments": {}
}

2. Plan → Execute

Create a plan first, then execute it:

Goal
 ↓
Plan
 ↓
Execute steps
 ↓
Verify

Useful for:

  • multi-step research,
  • coding tasks,
  • migration/release preparation,
  • workflows where users or approval systems need visibility into the intended plan.

The danger is plan fixation, so the runtime must support evidence-driven replanning.

3. Planner / Executor separation

Separate responsibilities:

Planner
  ↓ plan/subgoal
Executor
  ↓ actions
Environment
  ↓ observations
Planner / Controller

Planner and executor may be:

  • separate invocations of the same model,
  • separate skills,
  • different models,
  • partially deterministic components.

This is useful when planning and execution need different context or capabilities.

For example:

Planner:
repository structure + issue + architecture constraints

Executor:
one concrete file + edit tool + tests

It is overengineering for a simple request such as reading an invoice and explaining one rejection.

4. Generate → Verify → Repair

A strong pattern for verifiable artifacts:

Generate
 ↓
Verify
 ├── pass → done
 └── fail
       ↓
     Repair
       ↓
     Verify

Examples:

  • code + tests,
  • SQL + validator/sandbox,
  • structured data + schema/business checks,
  • config + syntax checker,
  • documents + rubric review.

This is often more reliable than a general-purpose open-ended agent.

5. Deterministic workflow with agentic islands

One of the most important production patterns is to keep the overall process deterministic while allowing semantic autonomy only in bounded places.

Deterministic workflow
│
├── validate input
├── fetch required data
├── [agentic analysis island]
├── policy check
├── approval
├── execute deterministic action
└── verify outcome

Release example:

build ───────── deterministic
tests ───────── deterministic
risk analysis ─ agentic
approval ────── deterministic gate
deploy ──────── deterministic
health check ── deterministic + optional semantic summary

This is often simpler, cheaper, and more reliable than making the whole process autonomous.

6. Supervisor / worker pattern

A supervisor delegates bounded tasks to specialist workers.

Supervisor
   ├── Code Review Worker
   ├── Security Worker
   └── Test Analysis Worker
          ↓
      aggregate results

A worker can be a skill or deterministic service; it does not have to be a separate LLM agent.

Supervisor/worker is an orchestration pattern, not necessarily a multi-agent LLM pattern.

7. Parallel fan-out / fan-in

Independent work can run in parallel:

             ┌→ analyze logs ─────┐
Goal → split ├→ analyze metrics ──┼→ aggregate
             └→ analyze deploys ──┘

Benefits:

  • lower wall-clock latency.

Costs:

  • higher parallel spend,
  • duplicate work,
  • conflict resolution,
  • shared-budget complexity.

The runtime needs explicit dependencies and aggregation semantics.

8. Event-driven loop

A loop does not have to be a long-lived while process.

Run requests approval
 ↓
state = WAITING_FOR_HUMAN
 ↓
process ends
...
approval event arrives
 ↓
queue / event handler
 ↓
load state
 ↓
resume run

The same applies to long-running builds and external jobs. Event-driven execution is often the right production model for waiting states.

9. Polling loop

When no event/webhook is available:

check job status
 ↓ not done
WAIT
 ↓
check again

Polling needs deterministic policy:

  • interval,
  • maximum wait,
  • backoff,
  • jitter,
  • deadline.

Do not spend an LLM call every second deciding whether to poll again.

10. Hierarchical planning

For project-like tasks:

Goal
 ↓
High-level subgoals
 ↓
local short-horizon plans
 ↓
actions

Example migration:

1. inventory
2. compatibility analysis
3. migration implementation
4. verification

Each high-level subgoal may contain its own local agentic loop. This is powerful but operationally more complex.

11. Multi-agent conversation pattern

For example:

Architect agent
 ↔ Security agent
 ↔ Implementer agent

This can be overused. Before introducing it, ask whether the participants truly need separate:

  • state,
  • permissions,
  • tool sets,
  • models/context specialization,
  • independently parallel work.

If not, one runtime with multiple skills/evaluators may be simpler.

Pattern selection matrix

Task property Prefer
fixed known sequence deterministic workflow
short uncertain investigation observe/act loop
multi-step but changing path short-horizon plan + replan
verifiable artifact generation generate/verify/repair
long-running external waits event-driven run
independent specialist analyses fan-out/fan-in or workers
high-risk known process with semantic step workflow + agentic island
genuinely separable specialist autonomy supervisor/workers, possibly multi-agent

Hybrid control strategies

A coding agent can combine patterns:

Deterministic outer workflow
        ↓
1. checkout repo
2. create sandbox
3. agentic investigation/edit loop
4. deterministic tests
5. agentic repair if tests fail
6. deterministic diff checks
7. human approval

It is not “workflow OR agent”. Good architecture is often:

workflow AND bounded agentic loops

Model routing inside a pattern

A runtime may use different models:

cheap model → routing/simple extraction
strong model → planning/complex decision
specialized model → code

Model routing should not change the canonical state contract.

Keep deterministic transitions deterministic

Examples:

if tool result == NOT_AUTHORIZED:
    state = BLOCKED

and:

if tests_passed and all_success_conditions_met:
    COMPLETE

Do not pay for a model decision where the next transition is already known.

Nested loops

A parent planning loop may launch a coding sub-loop, which itself contains a verification/repair loop.

Nested loops need:

  • shared hierarchical budgets,
  • parent/child state references,
  • cancellation propagation,
  • error propagation,
  • trace correlation.

Without this, agent explosion is easy.

Anti-patterns

Avoid “agent everywhere”, role-play multi-agent structures with no real responsibility boundaries, open-ended autonomy for known workflows, and nested loops without shared budgets or control.

Takeaways

  • There is no universal agent loop; control strategy depends on task and risk.
  • A simple observe/act loop may be enough for short uncertain tasks.
  • Short-horizon planning with replanning is often better for changing multi-step work.
  • generate → verify → repair is strong for verifiable artifacts.
  • Deterministic workflow + agentic islands is especially valuable in production.
  • Supervisor/worker does not imply multiple LLM agents.
  • Event-driven execution matters for approval and external-job waits.
  • Use multi-agent only when real responsibility/context/permission boundaries justify it.
  • Do not delegate deterministic transitions unnecessarily to a model.
  • Nested loops require hierarchical budget, cancellation, and tracing.