Day 8 · Right-Size the Agentic Loop
Day 3 was about right-sizing the model — picking the smallest technology that does the job. This is the same discipline, one level up, applied to an agent loop: a model that plans, calls a tool, reads the result, decides again, and keeps going — sometimes three turns deep, sometimes twenty. The call is no longer the unit of work. The loop is.
Days 3 through 7 tuned the single call from both ends: the right model, fewer calls, a leaner prompt, a retrieval layer that earns its tokens, an output shaped before it is asked for. Every one of those gains was real. In a loop, each one either compounds across every turn or quietly evaporates. Right-sizing the loop is the next layer of discipline — controlling two things most teams never set on purpose: how many turns the loop takes, and how much each turn carries.
The reason loops need their own principle is that they carry their own past. Turn one sends the task. Turn two sends the task, plus turn one’s answer, plus the tool result it produced. Turn twelve sends all of it — every query, every retrieved document, every line of the agent’s own reasoning — re-submitted and re-read at full input price. Cost rarely rises in a straight line with the number of turns. As context accumulates, later turns become disproportionately more expensive, because each one re-reads what came before. A right-sized loop is one that takes as few turns as the task needs, and carries as little as each turn needs.
A team builds an agent to triage incoming bug reports. It reads the report, searches the codebase, checks recent commits, pulls up similar past issues, and proposes a root cause. On a simple bug in the demo, it finishes in three turns and feels like magic.
In production, on a real bug, it runs eleven to fourteen turns. The team expected the bill to be roughly fourteen times a single call. It was several times higher than that. Nothing was broken. The agent was simply paying, on every turn, to re-read everything it had already done.
By turn twelve, the prompt carried the original report, six search results, four full files, and the agent’s prior reasoning — all paid for again at input price. Most of the tokens in the loop were not spent solving the bug. They were spent re-reading the loop.
The team made three changes. They carried a short running summary between turns instead of the full transcript. They set a turn budget. They gave the loop an explicit definition of “done.” Turn count fell. The total tokens per run fell much further — because the expensive part was never the work, it was the weight each turn carried.
Three patterns produce this kind of waste across nearly every team that ships an agent, and all three feel like reasonable defaults:
The full-transcript default. Most agent frameworks carry the entire message history into every turn, because that is the safe general behaviour — it guarantees the model never loses context. It also guarantees that every turn re-pays for every turn before it. The default is correct for the framework and expensive for your agent.
The generous turn ceiling. Max-iterations is set high, or left unset, so the agent “doesn’t get cut off mid-task.” A ceiling that never binds does not bound anything. It just lets a confused agent wander for thirty turns instead of failing fast at eight.
The missing finish line. The loop ends when it exhausts its turn budget or when the model happens to announce it is done — not on an explicit success condition. So an agent that solved the task at turn six often spends turns seven, eight, and nine confirming a result it already had.
The framework question
The obvious objection: doesn’t my agent framework handle all of this? The honest answer is that it handles the scaffolding, not the discipline.
A framework gives you the loop — it runs the turns, threads tool calls, and assembles the message history. What it does not do is decide what your particular loop should carry from turn to turn, how long it should be allowed to run, or what “finished” means for your task. Those are properties of your agent, not of the runtime, and the framework’s defaults are tuned to be safe for everyone rather than efficient for you.
The framework runs the loop. The principle decides what the loop is allowed to spend.
The operating ladder for a lean loop has four rungs:
Bound → Stop → Prune → Summarise.
Bound the loop before it runs. Set a maximum number of turns the agent may take — a hard budget, sized to the longest legitimate task, not to the worst case the framework will tolerate. Stop on success. Give the loop an explicit definition of done — a condition it can check — so it ends when the task is solved, well short of the budget, instead of running until the budget runs out. Prune what each turn carries. Before the next turn, drop the context the next decision will not use — stale tool outputs, abandoned branches, raw results already distilled into a conclusion. Summarise when pruning is not enough. Replace a growing transcript with a compact running state — the facts established so far, the open questions, the next step — so the loop carries its conclusions forward, not its full history.
The first rung is the most often skipped. Teams ship agents with the framework’s default iteration ceiling untouched — the same mistake as Day 7’s default max-token cap, one level up. A turn budget that never binds is decoration. The second rung is the most undervalued: a real stopping condition is usually worth more than any per-turn saving, because the cheapest turn in a loop is the one that never had to happen.
Engineering. Measure two numbers per run: turns taken, and total input tokens summed across all turns. Carry a running summary between turns instead of the full transcript. Set the turn budget to the longest real task, and write an explicit success check so the loop stops on done, not on exhaustion.
Platform / Infrastructure. A loop’s cost lives in a number no single-call dashboard shows: input tokens summed across every turn of a run. Track tokens-per-run and turns-per-run as first-class metrics. A team that only watches tokens-per-call is blind to the most expensive thing the system does, because the expense is in the repetition, not the call.
Architecture / CTO. The turn budget, the stopping condition, and the carried state are part of the agent’s design contract — not knobs buried in a config file. Treat them the way you treat any system limit: owned, sized to the workload, tested against real tasks, and revisited when the workload changes.
Sustainability / ESG. A loop multiplies the footprint of a single call by its turn count, and then again by the weight each turn carries. Bounding turns and pruning carried context is among the highest-leverage carbon levers in an agentic system, because it acts on the most-repeated tokens in the most-repeated operation.
Business / Product. A loop that wanders is slow as well as expensive — every extra turn is latency the user feels. Bounding the loop and giving it a finish line improves cost and response time at the same time. A faster agent and a cheaper agent are usually the same agent.
Five seats, one ladder, one loop that earns each turn it takes.
Pick one agent in production this week — the one with the highest bill, or the one that visibly takes many turns to finish.
Pull twenty real runs. For each, capture two numbers: how many turns it took, and the total input tokens summed across every turn of the run. Then estimate a third — of those input tokens, how many were new information the turn needed, versus history it had already seen.
That ratio of new-work tokens to total loop tokens is your loop signal-to-noise — how much of the loop is solving the task versus re-reading itself. Set beside Day 6’s retrieval signal-to-noise and Day 7’s output signal-to-noise, you now have one number for the input layer, one for the output layer, and one for the loop that wraps them. In most untuned agents, loop signal-to-noise is the lowest of the three — most of what a loop pays for is re-reading itself.
One agent, twenty runs, one ratio. That is the work.
A call pays once. A loop pays for everything it remembers, on every turn it takes.
Bound, stop, prune, summarise — that is how a loop spends less per run. But the deepest saving in a loop is not making each turn lighter. It is needing fewer turns. An agent that wanders for fourteen turns and an agent that finishes the same task in five are usually running the same model with the same tools — the difference is whether either one stopped to think before it started moving. The next principle is the turn that pays for itself: planning the loop before you run it. See you in the next issue.