Why architecture matters here
Planning matters because complex tasks have structure that one-step-at-a-time reasoning can't hold. Consider 'migrate this service's database and update all callers': it has dependencies (schema before data before cutover), parallelizable parts (update callers concurrently), verification points (test after each phase), and failure branches (rollback if migration fails). A reactive agent facing this makes locally-plausible next-steps that don't compose into a coherent strategy — it might update callers before the schema exists, or forget verification, or lose track of which callers it's done. Planning makes the structure explicit: the decomposition captures dependencies and phases, progress tracking prevents redoing or skipping steps, and the agent reasons about the task as a whole rather than as a sequence of disconnected reactions.
The counterintuitive architectural point is that more planning isn't always better — and often the best planning is no LLM planning at all. When the steps are known and fixed (ingest, then transform, then report; or retrieve, then generate, then verify), encoding them as a workflow agent (Sequential/Loop) is superior to having the LLM re-plan them every time: deterministic, free of planning tokens, debuggable, and immune to the model deciding to skip a step. LLM planning earns its cost only where the decomposition genuinely depends on the specific task and can't be known in advance. The mature pattern is hybrid: workflow-agent structure for the known skeleton, LLM planning for the parts that vary — spending deliberation tokens only where deliberation is actually required.
And planning without replanning and termination is a trap. A plan generated upfront meets a reality that diverges — a tool fails, an assumption is wrong, new information appears — and an agent that rigidly executes a stale plan produces confident nonsense. Replanning (revising the plan when observations invalidate it) is what makes planning robust, but it reintroduces the risk of loops (replan, execute, replan, execute, forever), which is why budgets and iteration limits are not optional. The agents that work in production plan enough to be coherent, replan enough to be robust, and are bounded enough to always terminate — three properties in tension that the architecture must balance.
The architecture: every piece explained
Top row: the planning approaches. From a goal, plan generation decomposes into steps — either implicitly (ReAct's reasoning traces make each step deliberate) or explicitly (a generated step list). The ReAct loop interleaves reasoning and action: the model thinks ('I need to check X first'), acts (calls a tool), observes the result, and thinks again — deliberation embedded in each step, adaptive by construction, but with no global plan to lose track of. Plan-then-execute generates the full plan upfront, then executes steps in order — coherent and inspectable (you can review the plan before it runs), but requiring replanning to handle divergence. The two aren't exclusive: many agents plan upfront and use ReAct-style reasoning within each step.
Middle row: adaptation and structure. Replanning revises the plan when execution reveals new information — a step failed, an assumption was wrong, the situation changed — regenerating the remaining plan from the current state; the mechanism that keeps upfront planning from being brittle. Workflow agents (Sequential, Parallel, Loop) are the deterministic alternative: where the plan's structure is known, encode it as agent composition rather than LLM reasoning — the Sequential agent is the plan for a fixed procedure, executed reliably and freely. Reflection adds a critique loop: after producing work (a draft, a solution), a reflection step evaluates it against criteria and triggers revision — the agent improving its own output, often as a LoopAgent with a critic and a reviser. Planner types in ADK range from built-in planners (that add planning instructions and structure) through ReAct-style configurations to custom planners implementing task-specific strategies.
Bottom rows: durability and bounds. State-tracked progress is essential for non-trivial plans: steps and their status live in session state (not just in the conversation), so a plan survives context compaction, agent restart, and long-running execution — the agent always knows what's done and what's next by reading state, not by re-reading a possibly-summarized conversation. Termination and budgets prevent the failure that makes planning worse than reacting: max iterations on loops, token and cost budgets that halt runaway planning, and explicit completion criteria (the plan is done when these conditions hold) so the agent stops rather than replanning forever. The ops strip: plan-quality evaluation (are the generated plans actually good — coherent, complete, correctly ordered — measured on eval sets), step observability (each plan step traced and logged, so a failed plan is debuggable step-by-step), and cost control (planning multiplies model calls — budget and monitor it).
End-to-end flow
Trace a planning agent through a real task: 'analyze our Q3 support tickets and produce a themes report with recommendations'. A pure reactive agent would flail — query some tickets, summarize randomly, lose coherence. The planning agent instead generates a plan: (1) retrieve and sample Q3 tickets, (2) cluster into themes, (3) quantify each theme's volume and trend, (4) draft findings per theme, (5) synthesize recommendations, (6) review for completeness. The plan is stored in state as steps with status; the agent executes them in order, and because progress is state-tracked, a mid-task context compaction (this is a long task) doesn't lose the plan — the agent reads 'steps 1-3 done, on step 4' from state.
Replanning shows its value when reality diverges. At step 2 (clustering), the agent discovers the tickets aren't categorized as assumed — the clustering approach in the plan won't work on this data. Rather than rigidly executing a doomed step, the agent replans the remaining steps: insert a categorization step, adjust the clustering approach, continue. The plan adapted to information execution revealed — the robustness planning-plus-replanning buys over both rigid plans and aimless reaction. At step 6 (review), reflection kicks in: a critic evaluates the draft against the goal ('does every major theme have a recommendation? are the volume claims supported?'), finds a theme lacking a recommendation, and triggers a revision — the agent improving its own output before delivering.
The structure-vs-LLM-planning distinction shows in the design choice the team made. The overall flow (retrieve → analyze → draft → review) is fixed for every report, so they encoded it as a SequentialAgent skeleton — no tokens spent re-planning the known structure — with LLM planning only within the analyze step, where the specific decomposition (which themes, how to quantify) genuinely depends on the data. Hybrid: deterministic where the plan is known, deliberative where it varies. And the whole thing is bounded — the review loop caps at 3 reflection iterations (a critic that always finds something can't loop forever), the task has a token budget that halts runaway replanning, and completion criteria (all themes covered, all recommendations present) tell the agent when it's actually done. The operational payoff: because steps are state-tracked and traced, when a report comes out wrong the team replays the plan step-by-step and finds exactly which step failed — planning made the agent not just more capable but more debuggable, because a plan is a structure you can inspect where a reactive trace is just a pile of tool calls.