AI Agent Planning: How Intelligent Systems Decide What to Do Next

Why This Matters for Enterprise AI

Give an agent a real goal, something like "reconcile last month's invoices and flag the disputes," and the hard part is not any single action. It is figuring out the right actions, in the right order, before a single one runs. That is planning, and it is the difference between an agent that completes a multi-step job and one that wanders, repeats itself, or quits halfway.

Most demos hide this difficulty by showing an agent calling one tool and returning one answer, which needs no plan at all. Production work asks for more, because a goal that takes twelve steps, branches on what it finds, and has to recover when step seven fails is a planning problem first and a tool problem second. If you have read the foundations of agentic design, planning is the "think it through" step from that loop, turned into something an agent can actually execute.

What Is AI Agent Planning?

AI agent planning is the process of turning a high-level goal into an ordered sequence of steps the agent can execute. The agent takes an ambiguous objective, decomposes it into concrete sub-tasks, decides what order they run in, and tracks progress as it works through them. Antonio Gulli, in Agentic Design Patterns, treats planning as the pattern that lets an agent handle goals too complex for a single reasoning pass.

The mental model is a project manager handed a one-line brief. "Launch the newsletter" is not a task you can do. It is a stack of tasks (draft the copy, build the list, set up the send, schedule it) that someone has to break out and sequence before any work happens. The agent's planner does that breakout.

Anthropic's Building Effective Agents describes the same capability as the thing that separates a true agent from a fixed workflow: the agent decides its own steps instead of following ones a developer hardcoded.

Planning is what lets an agent author its own version of prompt chaining at runtime. A chain is a sequence of steps a developer wrote in advance. A plan is a sequence of steps the agent writes for itself, shaped by the specific goal in front of it. Same pipeline shape, except the agent now decides what goes in it.

How Agent Planning Works

Planning runs in two moves: build the plan, then execute it, often looping between them. The cycle breaks down into four parts.

1. Decompose the goal. Break the objective into discrete sub-tasks. "Plan a three-day Lisbon trip under budget" becomes "find flights," "find lodging near the center," "build a daily itinerary," "total the cost against the budget." This step is where a vague goal becomes a checklist.
2. Order the steps. Arrange the sub-tasks by dependency. You cannot total the cost before you have prices, and you cannot build an itinerary before you know which days are free. The planner sorts what must come before what.
3. Execute and track. Work through the steps in order, calling tools or other agents as each one needs, and keep state on what is done and what remains. The plan is only useful if the agent knows where it is in it.
4. Replan when reality breaks the plan. A step fails, a tool returns nothing, or the environment shifts. The agent revises the remaining plan instead of charging ahead with a sequence that no longer fits.

The first two moves are the plan. The last two are execution. How well the decomposition holds up depends on how well the model reasons about the goal in the first place, which is why strong planning leans on the reasoning techniques covered next in this series. And how tightly you interleave planning with execution is the central design choice in agent planning, one that splits into two patterns.

Plan-and-Execute vs ReAct

Plan-and-execute generates the full plan up front, then runs the steps. The agent reasons once about the whole goal, commits to an ordered sequence, and executes it start to finish. The plan is explicit and visible before any action runs, which makes it cheap to review and cheap to audit. The catch is brittleness: a plan written before the agent has seen any results assumes the world will cooperate, and when step three returns something unexpected, the rest of the plan can be built on a wrong assumption.

ReAct interleaves reasoning and action instead. The pattern, introduced in the ReAct paper from Google Research and Princeton, runs a tight loop: the agent reasons about the next step, takes one action, observes the result, then reasons again with that result in hand. There is no upfront plan. The plan emerges one step at a time, each step informed by what the last one returned.

That makes ReAct adaptive, since it never commits to more than the next move and so can never commit to a broken plan. It pays for that adaptivity in latency and tokens, because every single step costs a fresh reasoning call.

The contrast is a real trade-off, not a winner.

| | Plan-first (plan-and-execute) | Interleaved (ReAct) | |---|---|---| | When the plan is made | All at once, up front | One step at a time | | Cost and latency | Lower (reason once, then execute) | Higher (reason before every action) | | Adaptivity | Brittle, committed to the initial plan | Adaptive, adjusts on every observation | | Inspectability | High, full plan visible before running | Lower, plan only exists in hindsight | | Best fit | Stable, well-understood goals | Open-ended goals in changing environments |

Enterprise reality: A nightly data-pipeline agent with a stable, well-understood job should plan first. The steps rarely change, the upfront plan is cheap, and your ops team can read the whole plan before it runs and sign off on it. A research agent answering an open-ended question, where each result reshapes what to look for next, should interleave, because any plan it wrote before seeing the first result would be obsolete by the second step. Matching the pattern to the goal is the decision that moves reliability and cost the most.

Code Example (Abbreviated)

Here is the planner half of plan-and-execute: one call that decomposes a goal into an ordered, structured list of steps. An executor would then run each step in turn. This is the "decompose the goal" move made concrete.

# Abbreviated: illustrative planner, not production code
from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
from pydantic import BaseModel, Field
class Plan(BaseModel):
    steps: list[str] = Field(description="Ordered steps to reach the goal")
planner_prompt = ChatPromptTemplate.from_template(
    "Break this goal into an ordered list of concrete, executable steps.\n"
    "Each step must depend only on earlier steps.\n\n"
    "Goal: {goal}"
)
# Constrain the output to the Plan schema so steps come back structured
planner = planner_prompt | ChatOpenAI(model="gpt-4o").with_structured_output(Plan)
plan = planner.invoke({"goal": "Plan a 3-day Lisbon trip under $1500"})
for i, step in enumerate(plan.steps, 1):
    print(f"{i}. {step}")
# An executor loop would now run each step, observe results, and replan on failure.

The same shape holds in Google ADK, where a planner can emit a structured sequence that a SequentialAgent then runs in order. The framework changes; the move of goal in, ordered steps out, does not.

Replanning: Revising the Plan as Reality Shifts

Planning is not a one-shot act. The most useful agents treat the plan as a draft they revise as they learn. Three triggers force a replan.

A step fails. The flight-search tool times out, or the booking API rejects the request. The agent cannot pretend the step succeeded. It either retries, routes around the failure, or revises the downstream steps that depended on the missing result.

The environment changes. The lodging the plan assumed is now sold out; the budget the plan was built against just got cut. A plan written against the old state is wrong, and executing it faithfully produces a wrong outcome.

New information reshapes the goal. A step returns something that changes what the rest of the plan should be, such as a research result that opens a better line of inquiry, or a finding that makes three planned steps unnecessary. The agent folds the new information back into the plan.

This is the loop closing. Replanning connects planning to reflection and adaptation, where the agent evaluates its own progress and corrects course rather than executing blindly. Plan-and-execute systems usually add an explicit replan step after each action: run the step, check whether the plan still holds, revise if it does not. That single addition gives an upfront plan much of the adaptivity of ReAct while keeping the plan inspectable. It is the common middle ground production systems settle on.

Failure Modes to Plan For

Planning buys an agent the ability to handle complex goals, but it introduces its own ways to fail, and three of them matter most.

Over-decomposition. A planner that splits a four-step job into twenty micro-steps adds latency, token cost, and surface area for mistakes without buying any reliability. More steps is not a better plan. The right granularity is the coarsest decomposition where each step is still a clean, executable unit.

Compounding drift. In a long plan, each step inherits small errors from the steps before it, and by step ten the agent can be confidently executing against a goal that quietly stopped matching the user's intent. The defense is the replan check: re-grounding against the original goal at intervals, not just trusting the chain of steps.

Planning when none is needed. Not every goal deserves a planner. A single-tool lookup or a one-shot answer needs no decomposition, and wrapping it in a plan-generate-execute loop adds cost and latency for nothing. The skill is recognizing which goals are truly multi-step and which only look it.

When to Use Agent Planning (and When Not To)

Planning earns its cost when the goal is genuinely a sequence, not a single move.

• Reach for it when a goal decomposes into multiple dependent sub-tasks that have to run in order: book the trip, run the report, reconcile the accounts.
• Use plan-first when the goal is stable and well understood and you want the plan visible and auditable before it runs.
• Use interleaved ReAct-style planning when the environment is unpredictable and each result should shape the next step.
• Add an explicit replan step whenever steps can fail or the environment can shift under the agent mid-task, which in production is most of the time.

Some goals do not need a planner at all.

• Skip it for single-step tasks. A definition, a lookup, a one-tool call needs no plan.
• Skip the heavy upfront plan when the goal is so open-ended that any plan would be obsolete by the second step, and interleave step-by-step instead.
• Skip planning entirely when a fixed prompt chain already handles the task reliably. If the steps never change, hardcode them; you do not need the agent to rediscover the same sequence every run.

Planning also scales past a single agent. When the sub-tasks call for different skills entirely, a planner can hand each step to a specialist instead of doing it inline, which is the bridge from planning to multi-agent systems. The honest test is whether the goal is a sequence. If it is, plan it. If it is one move, just take the move.

Key Takeaways

• AI agent planning turns a high-level goal into an ordered sequence of executable steps, through decomposition, ordering, execution, and replanning.
• Plan-and-execute writes the full plan up front: cheaper and inspectable, but brittle when results defy the plan. ReAct interleaves reasoning and action: adaptive on every step, but costlier in latency and tokens.
• Replanning is what keeps a plan alive: revise when a step fails, the environment changes, or new information reshapes the goal.
• The common production middle ground is an upfront plan plus an explicit replan check after each step, which trades a little cost for inspectability without losing adaptivity.
• Plan only what is truly a sequence. Single-step goals need no plan, and a reliable fixed chain beats a planner that rediscovers the same steps every run.