Gen AI

Planning & Reasoning

An agent either writes a full step-by-step plan before doing anything, or it reasons, acts, and checks the result one step at a time, adjusting as it goes.

A full plan for searching flights, searching hotels, and summing costs is fixed the moment it's written, while a reason-act-observe loop decides its next step only after seeing what the last one returned

Why Does This Exist?

Ask a model to answer something in one shot and it produces one output. Ask it to do something, and one output usually isn't enough, because the task takes more than one action, and those actions depend on each other. Say you tell an agent: find the cheapest flight from Chicago to Tokyo that also has a hotel deal, and tell me the total cost. That's not one lookup — it's a flight search, a hotel search, and arithmetic to combine them, and the hotel search only makes sense once you know which airport the flight lands at.

A model asked to do all of that in a single pass tends to skip a step or invent a number instead of calling a tool for it. Tool use and function calling gives an agent the ability to take one action; planning and reasoning decides which action, in what order, and when to change course.

Think of It Like This

Driving with a printed map versus driving with a GPS

A printed map gives you a route before the trip starts: turn here, merge there, exit at mile 40. Fast to plan, cheap to follow, right up until a road is closed and the map has nothing to say about it.

A GPS does less planning up front. It suggests the next turn, watches what actually happens, and recalculates the moment you miss an exit or hit a closure. It costs more, constantly re-checking itself, but it never drives you into a dead end and leaves you there.

Plan-and-execute is the printed map. Interleaved reasoning-and-acting is the GPS.

How It Actually Works

Decomposition

Before an agent can act, it has to break "find the cheapest flight with a hotel deal and total the cost" into smaller pieces it can execute: search flights, search hotels, compare costs, add them up. Each piece maps to something a tool can do — a single API call — instead of a vague instruction a model has to satisfy all at once.

This matters because a model asked to solve the whole thing in one generation has no natural place to pause and check its work. It tends to answer as if it already knows flight and hotel prices, fabricating numbers instead of calling real tools, or it conflates "search for flights" and "pick the cheapest one" into one vague sentence that never invokes anything. Decomposition forces the task into sub-steps small enough to check individually — did the flight search actually run — before the agent moves on.

Plan-and-execute

One way to use that decomposed list is to commit to it upfront. The agent reasons once, produces a full plan — "search flights from Chicago to Tokyo, search hotels near the arrival airport, sum the two cheapest options" — and executes each step in order. It only stops to replan if a step's result contradicts something the plan assumed, like a tool call failing outright.

The appeal is real: one planning call instead of one per step is cheaper, and a fixed sequence is predictable and easy to log, debug, and show a user before it runs. The risk shows up when the plan was written with incomplete information. A plan written before any search has run can't know, in advance, that the cheapest flight lands at a small regional airport with zero nearby hotel deals. It says "search hotels near the arrival airport" and just executes that, even though which airport it turns out to be is exactly what the plan couldn't anticipate. Nothing in a plan-and-execute loop watches for that unless a step visibly breaks — and a hotel search returning zero results usually isn't visibly broken, it's just quietly unhelpful.

Interleaved reasoning-and-acting

The alternative — the pattern behind ReAct-style agents — never commits further ahead than the next single step. The agent reasons a little ("check flight prices first"), acts once (calls the flight search tool), observes the result, and only then reasons again about what to do next. The plan, at any moment, is exactly one step long.

That costs more: every step is a fresh model call, informed by the freshest tool result, instead of one plan reused five times. But it's what lets the agent notice, mid-task, that the cheapest flight lands somewhere with no hotel deals nearby, and adjust — searching hotels in a nearby city instead, or reconsidering the flight itself once the hotel situation is priced in. That adaptation isn't a recovery mode bolted onto the loop. It's just what the loop already does at every step, since the next action was never decided until the last result came back.

Show Me the Code

1from typing import Callable2
3Step = Callable[[dict], dict]4
5
6def plan_and_execute(steps: list[Step], state: dict) -> dict:7    for step in steps:               # fixed order, decided before any step ran8        state = step(state)9    return state10
11
12def interleave(act: Step, observe: Step, decide_next: Callable[[dict], str | None], state: dict) -> dict:13    action = "search_flights"        # only the first step is chosen in advance14    while action is not None:15        state = act(state)16        state = observe(state)       # next action depends on what just came back17        action = decide_next(state)18    return state

plan_and_execute runs a list that was already final before the loop started. interleave only knows its next move after observe runs — decide_next reads the freshest state, not the original plan.

Watch Out For

Locking in a plan for a task whose steps genuinely depend on unknown results

Writing a full upfront plan for "search flights, then search hotels near the arrival airport" assumes the airport won't be a problem. When it is, a rigid plan-and-execute loop keeps executing as written — searching hotels near an airport with none nearby — because a normal, non-erroring tool call never trips its replanning condition. The plan isn't revisited until something breaks loudly, and a search returning zero good options usually doesn't.

Reasoning after every step when the whole task was predictable upfront

Interleaved reasoning earns its cost when a step's result can change what happens next. A task with no such dependency — three flight searches for three fixed, already-known routes — gives a fresh reasoning call nothing to adapt to between steps. Running the full reason-act-observe loop there just burns extra model calls and latency for a sequence a single upfront plan would have executed identically.

The Quick Version

Decomposition breaks one goal into an ordered list of smaller sub-steps a tool can actually execute.
Plan-and-execute commits to a full plan before acting, then works through it — cheap and predictable, but blind to anything the plan didn't anticipate.
Interleaved reasoning-and-acting decides only the next step, after seeing the last result — costlier per step, but naturally adaptive.
The flight-and-hotel example breaks a fixed plan exactly where the arrival airport turns out to have no hotel deals nearby.
Pick plan-and-execute when steps don't depend on each other's results; pick interleaved reasoning when they do.