Day 9 · Plan the Loop Before You Run It
Day 8 made the loop the unit of work and showed why it costs more than the calls inside it: every turn re-reads everything before it, so cost climbs faster than the number of turns the loop takes — closer to the square of the turn count than to a straight line. That issue was about spending less per turn — bound it, stop it, prune it, summarise it. This one is about needing fewer turns.
The picture is simple. Two agents — same model, same tools, same access — given the same task. One finishes in five turns. The other takes fourteen, lands on the same answer, and costs many times more. The single thing that separates them is whether the agent thought about the route before it took the first step.
And this turn count matters more than it looks. Under Day 8’s cost shape, the early turns are the most expensive, because everything they do is re-read by every turn that follows. Cutting four wandering turns at the start of a fourteen-turn loop isn’t a 28% saving — it removes those four turns AND every later turn that would have re-read them. A planned loop, put plainly, is one that decides its route before it spends a turn walking it.
Two agents, same task: reconcile a customer’s billing dispute across three systems — the payment processor, the subscription ledger, and the support log. Same model. Same tools. Same access.
The first agent writes down its plan before doing anything: pull the disputed charge, find the matching ledger entry, check the support log for a refund request, compare the three. Then it executes that plan, top to bottom. Five turns. Done.
The second agent skips the plan and starts working. It pulls a charge — wrong one. Backs up, tries again. Opens the support log before it has the ledger entry to compare against, realises it can’t use it yet, sets it aside. Twice it re-reads its own earlier notes to remember where it had got to. Fourteen turns later, it produces the same answer the first agent produced nine turns earlier.
Nothing was broken. The slow agent was the same model running the same task. It simply paid, turn after turn, to find a route a single planning turn would have laid out at the start. And under Day 8’s cost shape, the turns it wasted were the worst ones to waste — the early ones, which every later turn paid to re-read.
Three patterns produce this kind of wandering across almost every team that ships an agent, and all three feel like reasonable defaults:
The act-first default. Most agent frameworks let the model call a tool on its very first turn. Planning is something you have to add — it isn’t what you get out of the box. So the default behaviour of any untouched agent is to start moving before it has worked out where to go.
The one-step-at-a-time trap. Without a plan, the agent picks each move from the result of the last one — never from the task as a whole. A move that looks right in isolation is often wrong for the route, and the agent has no way to see that until it hits a dead end.
The “where was I?” tax. Without a plan to anchor to, the agent rebuilds its sense of where am I, what’s left to do from the full conversation history on every turn. That re-reading isn’t progress. It’s the loop paying just to keep track of itself.
The planning question
The obvious objection: doesn’t a reasoning model already plan? It visibly “thinks” before it answers — isn’t the loop already planned?
The honest answer is that the model’s thinking and an explicit plan solve different problems, and the right tool depends on the task.
Reasoning handles the step. When a reasoning model thinks, it works through what to do in the current response. For a short loop with one or two tools, where the next step is obvious from the last result, that is enough on its own. Adding a separate planning step here is Day 3’s mistake one level up — reaching for more machinery than the task needs.
A plan handles the route. For longer loops that touch several tools, branch, or have to back out and try again, internal reasoning on its own is fragile. By default, the model’s thinking informs the immediate answer but isn’t carried forward to the next turn. Some newer model setups can preserve reasoning across turns. That helps the model, but it doesn’t solve the loop problem. Preserved reasoning is still internal to the model: opaque, unstructured, not visible to your tools, your orchestration layer, or your team. A written plan is structurally different — a visible, named list of steps the loop can checkpoint against, your monitoring can flag, and a human can read in the trace. Reasoning, preserved or not, doesn’t give you that. The plan does.
The two combine. On genuinely hard agentic work, the strongest agents use both. The plan keeps the loop on a stable route; reasoning keeps each step on that route sharp. Neither replaces the other.
The simple rule: short, single-tool tasks — reasoning is enough. Long or branching loops — write the plan. Hard tasks — use both, on purpose.
Reasoning sharpens the step you’re on. A plan steers the loop you’re in. Pick by the loop, not by the model.
The operating ladder for a planned loop has four rungs:
Decompose → Sequence → Checkpoint → Re-plan.
Decompose the task before any tool runs. Break it into named sub-goals — pull the charge, match the ledger, check the support log, compare — so the whole route is visible at once instead of discovered one step at a time. Sequence the sub-goals into an order, and rule out the paths you can already tell are dead. This is the rung that does the most work, because every wrong path the agent skips here is a wrong path it doesn’t have to walk down and back out of later. Checkpoint at every step — after each move, the agent asks one short question: am I still on the route I laid out? Divergence is caught the turn it happens, not ten turns later. Re-plan when the answer is no. A divergence costs one cheap planning turn to absorb; that turn is far less than the wander it prevents.
The first and the last rungs are the ones most often skipped. Decompose is skipped because nothing makes you do it — the framework simply runs without a plan if you don’t ask for one. Re-plan is skipped for the opposite reason: teams treat the plan as something that must be followed rigidly, and so avoid planning at all rather than re-plan mid-run. Cheap, frequent re-planning is exactly what makes the discipline robust. The plan does not have to be right. It only has to remove the moves that were obviously going to be wrong.
Engineering. Add one step before the agent executes anything: have it emit an ordered list of the tool calls it intends to make, then run that list. Measure turns-to-completion on the same real tasks before and after. The planning turn costs you one — count how many it removes.
Platform / Infrastructure. Watch the turn-count distribution, not the average. The wander hides in the tail — a handful of fourteen-turn runs drag the bill far more than the median suggests. Flag runs whose turn count overshoots the plan they emitted at the start.
Architecture / CTO. Which agents need a plan is a design decision, not a per-team guess. Long or branching loops earn a planning step; short, single-tool tasks don’t. Bake that threshold into the platform so every team inherits the same default instead of each team re-deciding it.
Sustainability / ESG. Removing early turns is among the highest-leverage carbon cuts in an agentic system, because the early turns are the ones re-read most by every turn after them. Fewer turns at the start means less repeated compute all the way down the run.
Business / Product. A planned loop is faster and cheaper at the same time — the turns it skips are latency the user feels and tokens the bill counts. The flip side matters too: forcing a plan onto a one-step task is Day 3’s over-sizing, one level up. A faster agent and a cheaper agent are usually the same agent.
Five seats, one plan, one loop that knows its route before it walks it.
Take the agent you measured on Day 8 — the long, branching one.
Add a single step before it executes anything: ask it to write the ordered sequence of tool calls it intends to make, then proceed. Change nothing else. Run the same twenty real tasks and capture two numbers per run: turns taken, and how that compares to its Day 8 baseline.
Then set those against your Day 8 loop signal-to-noise. If that ratio told you how much of each run was re-reading rather than working, this tells you how much of that re-reading was avoidable simply by knowing the route in advance. The planning turn costs you one. Count how many it bought back.
One agent, one planning turn, twenty runs. That is the work.
A reactive loop pays to discover the wrong path. A planned loop pays once to skip it.
Planning makes the loop take fewer turns. The next lever is making each turn do more. Most agents loop because their tools hand back raw material — a search that returns ten documents the agent must then read, filter, and re-query. A tool that returns the finished answer ends the turn instead of feeding the next one. The next principle is the tool that closes the loop: designing what the agent calls so it doesn’t have to call again. See you in the next issue.