Planning loops

ReAct makes one decision at a time: think, act, observe, repeat. Planning loops flip that: think about the whole task first, write out the plan, then execute the plan step by step. The plan adds structure. Execution keeps flexibility. For tasks with 8+ steps or for anything you want to review before running, planning loops are the right shape.

The pattern

1. Plan: prompt the model to produce a structured list of steps. "Research Y by doing these 5 things."
2. Execute: orchestrator walks the list. At each step, it calls the right tool or runs a mini ReAct loop.
3. Synthesize: final LLM call combines the step results into the user-facing answer.

Why plan first

Three concrete wins over pure ReAct:

• You can review it. For high-stakes tasks (spend money, send email, modify prod), a human approves the plan before it runs.
• You can parallelize. If steps 2, 3, 4 are independent, run them at the same time. ReAct forces them sequential.
• You can recover smartly. Step 4 fails? Restart from step 4, not from scratch. The plan is a checkpoint structure.

When planning helps vs doesn't

A worked example: "Research the top 3 competitors for product X"

Plan phase, model writes:

1. Identify top 3 competitors of X (web_search)
2. For each, fetch their pricing page (web_fetch, parallel)
3. For each, fetch their product page (web_fetch, parallel)
4. Extract key features from each (llm call per competitor)
5. Write comparison table (synthesize)

Execute phase: steps 2 and 3 run in parallel for 3 competitors (6 fetches, simultaneously). Total wall time: ~6 seconds instead of ~20 if done sequentially. Plan saved time and gave you a reviewable artifact.

Hybrid: plan + ReAct inside each step

The most robust shape in production. Outer loop is a plan. Inner loop at each step is a small ReAct agent. Plan gives the skeleton; ReAct handles tactics when a step turns out to be trickier than expected ("fetch failed, try a different URL").

Replanning triggers

Plans go stale. Hard-code these replan triggers:

• A step returned an unexpected result (competitor doesn't have a pricing page)
• Cost for a step exceeded its budget
• User intervened with new info mid-execution
• Two consecutive steps failed

When triggered, the agent generates a new plan from the current state (what it knows now, what's already been done).

Plan-prompt craft

A planning prompt is different from a ReAct prompt. Include:

• The goal, one sentence.
• The tools available, names + one-line descriptions.
• Constraints, budget, time, safety rails.
• Output format, a numbered list with tool calls specified.
• A bias, "prefer fewer steps" or "parallelize independent steps."

Bad planning prompts produce 15-step plans for 3-step tasks. Good prompts produce tight, parallelizable plans.

Pitfalls

• Over-planning. Model writes 20 steps when 4 would do. Fix with a "prefer fewer steps" instruction.
• Rigid plan, changing reality. Tool at step 3 returned nothing useful; rest of plan is now garbage. Fix with replan triggers.
• Plan leaks into context forever. At step 18, the original 20-step plan is still in context eating tokens. Drop completed steps or summarize.
• Planning everything. Small tasks don't need a plan phase. The extra LLM call costs more than it saves.

What to do with this

• Start with ReAct. Add planning only when ReAct traces are getting long (>10 steps) or tasks need parallelization.
• Read reflection to add a quality check to your planning output.
• Read orchestrator-worker for the multi-agent cousin of plan-then-execute.