Planning & Reasoning

An agent can write the whole plan before it acts, or it can reason one step at a time and let each tool result pick the next move. The first is cheap and predictable, the second adapts when the world surprises you.

A fixed plan totals 730 dollars from a 420 dollar flight plus a 310 dollar hotel, while a reason-act-observe loop switches flights to total 590 dollars and save 140 dollars

Why Does This Exist?

You ask an agent to find the cheapest one night trip from Chicago to Tokyo and report the full cost. That's not one lookup. It's a flight search, a hotel search near the arrival airport, and addition. The hotel step depends on the flight step, because you can't price hotels until you know where the plane lands.

Ask for all of that in one generation and you'll watch it skip a tool call or invent a price. It has no place to pause and check. Tool use and function calling gives the agent the ability to take one real action. Planning and reasoning decides which action goes first, what comes next, and when to throw the order away.

This page compares the two orders you'll actually choose between. A fixed upfront plan is cheap and easy to audit. An interleaved loop that reasons after every tool result costs more and adapts. For the loop itself in detail, see ReAct pattern. For branching many possible plans instead of one, see tree of thoughts. For splitting the plan across specialists, see multi-agent systems.

Think of It Like This

A printed map versus a GPS that recalculates

You drive to a wedding with a printed map. You planned the whole route at the kitchen table: highway, exit 40, left at the church. It's fast to follow and easy to explain. Then exit 40 is closed. The paper has nothing to say. You keep driving the plan because the plan is all you've got.

With a GPS you plan almost nothing upfront. It names the next turn, watches where you actually go, and recalculates the moment you miss it or hit traffic. You pay for that attention with battery and constant chatter, but you never sit at a closed exit wondering what to do.

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

The analogy stops at prices. A closed road looks closed. A bad hotel result looks like success: zero good options, normal formatting, no error. A rigid agent drives on. A GPS would at least see the barrier.

How It Actually Works

Call the goal $G$ : cheapest one night trip plus its total. Call the plan $P = [a_1, a_2, a_3]$ : an ordered list where $a_1$ is the first action, $a_2$ the second, and $a_3$ the third. Call the state $s_t$ : everything the agent knows after step $t$ . Call the observation $o_t$ : what the tool just returned. Call the action $a_t$ : the tool call the agent makes next. In plain words, the plan is the list, the state is the memory, the observation is the receipt, and the action is the move.

Turn the goal into checkable steps

You don't hand the agent one vague sentence. You break $G$ into pieces small enough that each maps to one tool: search flights, search hotels near the arrival airport, add the two cheapest compatible options. Each piece has a check. Did the flight tool run. Did it return prices. Did the hotel search use the airport the flight actually landed at. Without that split the model answers from memory instead of calling tools, and you can't tell which step failed.

Plan-and-execute writes once, then runs

Plan-and-execute reasons once and locks $P$ before any tool runs. For the trip it writes: search flights from Chicago, search hotels near the arrival airport, sum the cheapest pair. Then it runs $a_1$ , $a_2$ , $a_3$ in order. It only replans when a step errors loudly, like an API failure.

The trade is clear. You spend one planning call plus one call per tool, so three tools cost four calls total. The sequence is predictable and easy to log. But the plan was written with no prices in hand. If the cheapest flight lands where hotels are thin, the agent still searches there, finds little, and adds anyway. Nothing failed, so nothing triggers a rethink.

Don't use a fixed plan when a later step depends on an unknown earlier result. Airport choice, part availability, or any filter that only appears after the first search will break it quietly.

The ReAct loop decides one step at a time

The ReAct loop never holds more than the next move. It reasons a little from the current $s_t$ , takes one $a_t$ , reads the new $o_t$ into $s_{t+1}$ , and only then picks the next action. Thought, action, observation. Then thought again.

That costs more. Three tools now cost about six calls, because each tool call is wrapped in its own reasoning call. You pay in latency and in variance, since the agent can choose differently on a rerun. What you buy is adaptation as the normal case, not a recovery mode. When the first hotel result comes back thin, the next thought already sees it and can switch airports or reconsider the flight before the total is set.

The loop assumes $o_t$ carries signal you can act on and that tools report honestly. When observations are vague or tools return plausible junk, the loop steers by noise. It can also wander, retrying similar searches instead of stopping.

Worked example: 730 dollars fixed versus 590 dollars adaptive

Take two real options with small numbers you can check by hand.

Flight F1 costs 420 dollars and lands at Haneda. Hotels near Haneda cost 310 dollars for the only workable option. Flight F2 costs 480 dollars and lands at Narita. Hotels near Narita cost 110 dollars.

The fixed plan picks the cheapest flight first, because at plan time that's all it can compare. It runs:

420 plus 310 equals 730. So the fixed total is 730 dollars.

The loop runs the same first flight, then reads the observation: 310 dollars, one thin option, zero deals. Its next thought switches. It checks the other airport, finds 110 dollars, and totals the new pair:

480 plus 110 equals 590. So the adaptive total is 590 dollars.

The saving is 730 minus 590 equals 140 dollars. The call count tells the rest of the story. Fixed uses 1 planning call plus 3 tool calls, which is 4 calls. The loop uses 3 reasoning calls plus 3 tool calls, which is 6 calls. You pay two extra calls to find the 140 dollar saving. When steps don't depend on each other, those extra calls buy nothing, and you should keep the fixed plan.

Code

The point here is the arithmetic the agent must redo instead of trusting memory. Recompute both totals and the saving in plain Python, then compare.

1def total(flight: float, hotel: float) -> float:2    return flight + hotel3
4
5fixed = total(420.0, 310.0)  # rigid plan keeps first flight6print(fixed)  # -> 730.07
8adaptive = total(480.0, 110.0)  # loop switches after thin hotels9print(adaptive)  # -> 590.010
11print(fixed - adaptive)  # -> 140.0

The three printed numbers are 730.0, 590.0, and 140.0. They match the hand calculation above and the diagram below. If your agent reports a total, rerun this check before you believe it.

Watch Out For

A stale plan that looks successful

You'll see totals like 730 dollars with green checks everywhere. Every tool ran. No error fired. But the hotel leg returned zero good options and the plan added the fallback anyway. The symptom is a clean run with a useless trip: correct formatting, wrong answer.

Fix it at the plan level. Only use plan-and-execute when no step needs an earlier result to make sense. Otherwise require the loop, or add an explicit replan trigger on thin results, such as zero deals or a price above a bound, so quiet disappointment still counts as signal.

Paying for reasoning with nothing to adapt to

You'll see the loop run six calls to reproduce exactly what one fixed plan would have done. Three fixed flight searches on known routes don't change after each result, so each fresh thought has nothing new to decide. The symptom is higher latency and a higher bill for the same sequence, plus occasional needless variation.

Fix it by matching the method to the dependency. If you can name every step and its inputs before any tool runs, write the plan once and run it. Save the loop for tasks where $o_t$ can change the next $a_t$ .

The Quick Version

Decomposition turns one goal into ordered tool sized steps, each with its own check for whether the tool actually ran.
Plan-and-execute locks the full order before acting, which costs 4 calls for 3 tools and stays predictable until the world differs from the plan.
A reason-act-observe loop picks only the next action from the latest tool result, which costs about 6 calls for 3 tools and adapts by default.
In the trip example, the fixed plan totals 730 dollars from 420 plus 310, while the adaptive loop totals 590 dollars from 480 plus 110 and saves 140 dollars.
Use a fixed plan when steps are independent and known upfront, and use the loop when a later step depends on an earlier result you haven't seen yet.