Day 10 · Close the Loop with the Right Tool
Day 8 made the loop the unit of work and showed why each extra turn costs more than the one before it. Day 9 cut turns at the front by planning the route. This issue cuts turns at every step by changing what the agent calls when it gets there.
Here is the observation that opens it. Two agents can run the same model, hold the same plan, and reach the same answer — and one of them takes seven turns while the other takes two. The thing that changes is not the agent. It is the shape of the tools the agent has to call. One agent is handed a toolbox of raw capabilities and has to stitch them into an answer; the other is handed a tool that already understands the task and returns the answer in one call.
Every tool an agent calls either ends a turn or feeds the next one. A tool that returns raw material — a search result the agent must filter, a record the agent must enrich, a list the agent must rank — is a tool that keeps the loop running. A tool that returns a closed answer is a tool that lets the loop stop. The interface between the agent and the rest of your system is not a wrapper around your API. It is the unit that decides whether the loop ends here or runs another turn.
Two agents, same task: answer the question “what is the status of my last order, and when will it arrive?”
The first agent has four tools, each a clean primitive: look up the customer by email, list orders for a customer, fetch shipping for an order, fetch carrier ETA for a tracking number. Sensible names. Clean separation. The agent calls them in order — customer → orders → shipping → ETA — and assembles the answer on the fifth turn. Nothing is wrong with any single tool. The agent simply paid four turns to do the assembly.
The second agent has one tool: latest order status for this customer. It takes the customer’s email and returns the order, the items, the carrier, the current status, and the expected arrival window — in one call. Two turns and the answer is back.
Same model. Same data. Same question. The only difference is whether the tool matched the task the agent was doing — or merely exposed the capabilities the system happened to have. Three patterns produce this kind of extra-turn loop across almost every team that ships an agent, and all three feel like reasonable defaults:
The grep-it-yourself tool. The tool returns more than the agent needs — fifty search hits instead of the best match, a full record instead of two fields, a list when one answer would do. The agent’s next turn is filtering, sorting, or picking. That filter is a turn you paid for, run for a question your tool could have answered itself.
The one-call-per-field tool. The tool exposes one capability cleanly, and to get a useful answer the agent has to call three or four of them and stitch the results together. Each call is a separate turn. The agent has become the integration layer — which is the most expensive integration layer you can buy, because it is charged in tokens and re-processed by every turn after it.
The “now what?” return. The tool returns data without context — a list of IDs, a row from a table, a status code. The agent’s next turn is scanning back through its own earlier turns to remember why it asked for this and what to do with it. The tool was a function. The agent had to be the function that wrapped it.
None of these tools are badly built. They are simply built for a different consumer than the one calling them.
The flexibility question
The obvious objection: doesn’t a toolkit of clean primitives give the agent more flexibility? Isn’t exposing the building blocks the right move — let the model compose them however the task needs?
The trade-off is simple: flexibility and turn cost pull in opposite directions, and the right balance depends on how predictable the agent’s tasks are.
Primitives are right for the unknown. When the agent’s task isn’t known in advance, or when the same agent serves many different jobs, exposing clean capabilities is the only design that works — task-shaped tools you haven’t thought of yet can’t exist yet. The cost of composition shows up in turns, but the alternative is not being able to do the work at all.
Task-shaped tools are right for the known. Most agents in production do not do unknown work. They do the same handful of tasks thousands of times — answer order questions, reconcile billing entries, triage support tickets, summarise a known kind of report. For tasks this repeatable, the agent doesn’t need flexibility; it needs the right tool for the job. Shipping the same composition turn after turn, for every run, is paying every customer to re-discover what your engineers already know.
The two combine. The strongest production agents carry a small number of task-shaped tools that cover the common path, alongside a smaller set of primitives for the edges. The task-shaped tools close most loops in one or two turns; the primitives are there for the cases the task-shaped tools weren’t designed for. Neither layer replaces the other.
The simple rule: tasks the agent will do hundreds of times — give it a tool that knows the task. Tasks the agent will do once or twice — primitives are enough.
Flexibility is paid for one turn at a time. Let the agent pay for it only on the tasks that actually need it.
Most tool redesigns follow the same progression:
Scope → Filter → Compose → Close.
Scope the tool to the task before its API is written. The question to ask is not “what data does this expose?” but “what task is the agent doing when it calls this?” A tool called answers a system question. A tool called answers an agent question. The first is reused across forty places in your codebase; the second is the one the loop actually needed. Both can exist — but only the second ends a turn.
Filter inside the tool, not after it. If the agent’s first move after every call is to filter, sort, or pick the top result, that work belongs inside the tool. The cost of doing it inside is paid once, by you, in code. The cost of doing it inside the loop is paid every run, by the agent, in tokens — and re-processed by every turn that follows it. A tool that returns fifty rows so the agent can pick three has handed the loop forty-seven rows of work it never needed.
Compose capabilities into the call. If two of your tools are always called together, they want to be one tool. Folding a follow-on call back into the original removes a turn from every run. The combined tool is harder to write — joins, lookups, edge cases — but harder to build once is cheaper than easy to build and paid for every run. Composition inside the tool is amortised; composition inside the loop is recurring.
Close the loop with a self-sufficient return. The tool’s return should make the next step obvious: either the agent has the answer it needed and the loop ends here, or the next call is unambiguous from what just came back. Helpful is what the agent uses on the next turn — everything else is weight the loop has to carry. If the agent has to revisit its earlier turns to know what to do with the return — what it asked for, why it asked, what the value means — the return wasn’t closed.
The first rung is the one most often skipped, because it requires the engineering team to think like the agent rather than like the database. The last rung is the one most often misunderstood — teams add more fields to the return on the theory that more context is helpful, when the cost shape from Day 8 says the opposite: every extra field becomes weight the loop has to carry for the rest of the run.
Engineering. Take the three tools the agent calls most often. Read each one as the agent reads it — the input contract, the return shape, what the agent does on the very next turn. If the next turn is filter, sort, or pick the top result, that work belongs inside the tool. If the next turn is another call to enrich the result, those two tools want to be one. If the next turn is scanning back through prior turns to remember what to do with this return, the return is too thin. One careful pass through your three highest-volume tools is usually where the largest single reduction in turn count per task lives.
Platform/Infrastructure. Tool definitions are platform infrastructure now. A tool registry that tracks call volume per tool, the agent’s typical next-turn action after each call, and the size distribution of returns is what surfaces the loop-extending tools before the cost report does. As organisations adopt tool registries and emerging protocols such as MCP, the work shifts from simply exposing tools to exposing the right shape of tools for the agent work they actually serve.
Architecture/CTO. Agent tools are a distinct architectural layer with their own design discipline. They are not microservices in disguise — those are built for low-level reuse by other code. They are not screen-level APIs — those are built for a human at the other end. They are built for a model that pays in turns. Reviewing them as a layer in their own right, with named scope and return-shape standards, is what keeps them from drifting back into raw primitives over time.
Sustainability/ESG. Each redundant turn an agent runs is energy, water, and hardware time spent re-processing prior context to do work the tool layer could have done once. Tool discipline removes redundant turns at their source, which means the saving compounds with every deployment and every run. It is also one of the few efficiency moves whose footprint reduction is straightforward to measure: turn count per task, before and after.
Business/Product. The unit economics of an agentic feature are set by how many turns each task takes. A task that takes two turns instead of seven can materially reduce operating cost — often far more than teams expect — while also running faster, which is what the customer feels at the other end. Tool design is the product feature your users will never see directly and will pay for in every line item. Knowing which tasks are turn-heavy and why is what tells you which agentic features will scale beautifully and which will not.
Five seats, one tool layer, fewer turns per task.
Take the agent you measured on Day 8 and replanned on Day 9. Pull the trace from one full run.
For each tool call in the trace, look at the very next turn. Write down what the agent did there: filter, sort, enrich, follow up, or revisit earlier turns. That single column is your audit.
Pick the tool whose next-turn pattern repeats most often across the twenty runs — that is your highest-leverage candidate. Fold the recurring next-turn work back inside the tool: move the filter inside, combine the follow-on call into the original, or thicken the return so the agent doesn’t have to revisit context to use it. Ship the new version of that one tool, change nothing else, and re-run the same twenty tasks.
Compare turn counts against your Day 9 baseline. If the average drops, you have just removed a recurring turn from every future run of this agent — a saving that compounds, not a one-off.
One caution, so you don’t over-correct: not every tool wants to be a task-shaped tool. The primitive that the agent calls twice a year on an edge case is doing its job; folding it into something larger would only add weight. Reshape the tools your loop actually leans on. Leave the rest alone.
One tool, one fold, twenty runs. That is the work.
A wrong-shaped tool keeps the loop running. A right-shaped tool lets it stop.
Days 8, 9, and 10 have made the loop visible, planned its route, and shaped each tool to end the turn it’s called from. The next lever is the one a long loop quietly drifts on — context. The longer the loop runs, the more context it accumulates, and the more every later turn pays to carry forward. Some of that context is the agent’s working memory and needs to stay. Most of it is residue and needs to go. The next principle is on telling the two apart, and on knowing when a fresh loop is cheaper than another turn of the old one. See you in the next issue.