Six Steps Deep: Capping Tool Loops at 40 Jobs a Day

01 · What a tool loop does to your budget across forty jobs a day

Every agentic workload your team ships has one cost shape that dominates the rest: the loop of model calls wrapped around tool results. A planner calls a search tool, reads a file, patches it, runs a test, reads the failure, patches again. Each new turn feeds every earlier result back into the next prompt. In a single demo run the loop is invisible. Across a sustained queue of forty jobs a day it becomes the line item that decides whether the budget survives the quarter.

Two properties make loops dangerous for operations teams. They compound, because every extra step re-pays for the context accumulated so far rather than adding a small increment. And they are open-ended, because without an explicit ceiling a confused agent does not stop; it retries, re-scopes, and re-reads. Leads who treat depth as an implementation detail inherit both problems at once, usually in the form of a surprise token bill and a run that nobody can fully reconstruct.

The fix is not to forbid tools. It is to treat every loop as a bounded, metered pipeline with a documented ceiling and a complete step record. The rest of this primer covers the ceiling, the record, the accounting, and a rollout pattern that a team can execute without stalling delivery.

02 · Set the depth cap before the loop sets one for you

Start by naming what you are counting. Depth can mean tool calls per task, model turns per task, or nested calls where one tool result triggers another tool. Pick one definition per workflow and write it down, because ambiguous ceilings are the reason two engineers enforce different rules in the same repository.

• › Scoped code changes: a small ceiling, often around six tool calls, works well. The agent reads a file, edits, runs one verification, and stops.
• › Exploratory debugging: allow a middle range, roughly twelve to fifteen calls, because the agent needs to gather evidence before it commits to a fix.
• › Research and summarisation: permit the deepest runs, but require a written intermediate plan so the extra steps are purposeful rather than repetitive.
• › Nested or spawned tool calls: count them against the same ceiling, not a separate one, or a single task can multiply into dozens of uncapped sub-loops.

Two enforcement details matter more than the number itself. First, make the limit a hard stop that returns a partial result plus a clear status such as depth-exceeded, so callers can retry or escalate instead of guessing. Second, emit a soft warning at eighty percent of the ceiling, so you can see which tasks are straining their budget before they hit the wall. A ceiling that only truncates silently trains your team to distrust the agent.

Finally, review the ceilings on a schedule. A limit set in a quiet week will be wrong after a migration or a new customer integration, and the wrong limit shows up as either wasted spend or abandoned work.

03 · Record every step as its own metered event

Depth limits are only defensible if you can prove what happened inside the loop. The unit of evidence is the step record: one entry per model call or tool call, appended in order, never overwritten.

• › Identity and order: task id, run id, sequence number, and the step that triggered this one.
• › Tool details: tool name, a truncated or hashed version of the arguments, the result size in bytes, and the tool exit status.
• › Model details: the model identifier for that step, since many teams mix a fast model for retrieval with a stronger one for the final synthesis.
• › Token accounting: input tokens, output tokens, cache writes and cache reads, recorded separately for the step.
• › Timing: latency per step, and whether the step ended normally, with a tool error, or by hitting the ceiling.

Store digests rather than full payloads where results are large or contain customer data. The goal is replay and reconciliation, not a second copy of your production corpus. With per-step records, a truncated run becomes a five-minute review instead of a debate: you can see exactly which call consumed the budget and whether the ceiling cut the work at the right moment.

Step records also give you leverage on quality. Patterns like repeated identical searches, three consecutive failed edits, or a tool that returns nothing at step two are all visible only in the step log, and each one is a prompt, tool, or guardrail fix waiting to happen.

04 · Price the steps on real tokens, with cache writes and reads kept apart

Loop cost is a token question, not a call-count question. A twelve-step loop that re-reads a large context each turn behaves very differently from a twelve-step loop that appends small deltas. Counting calls hides both.

Meter every step on the tokens actually consumed, and keep cache writes and cache reads as separate figures. Long loops that revisit the same instructions and history are exactly where caching changes the economics: the write is paid once, and subsequent steps draw cheaper reads. If your accounting collapses both into one number, you will misjudge which workflows are expensive and which are merely verbose.

Model choice per step is the second lever. A lightweight model handles repetitive retrieval and formatting steps well, while a stronger model earns its cost on the final reasoning and review pass. This is where a relay such as Quanta fits naturally: one balance covers the range of models your team already uses, every call is metered on real tokens, and cache writes and cache reads are priced separately, so the per-step records you collected in the previous section reconcile line by line against the bill.

Keep the reconciliation routine simple. Each week, sample a handful of runs, match step tokens to metered tokens, and confirm the cache split looks the way your loop structure predicts. Any drift is either a logging bug or a workflow that has grown past its intended shape.

05 · Roll out depth caps across three weeks without stalling delivery

Team leads succeed with limits when the rollout is staged rather than sudden.

• › Week one, shadow mode: record depth, per-step tokens, and cache splits for every run without enforcing anything. This is your baseline and your evidence for choosing ceilings.
• › Week two, soft enforcement: turn on warnings and the eighty percent signal, and let teams see which workflows would have been truncated. Adjust ceilings before they bind.
• › Week three, hard enforcement: activate the hard stop with the partial-result contract, and announce the depth-exceeded status so callers handle it deliberately.

Support the rollout with three artefacts: a per-team budget view built from step records, an alert that fires when a task reaches its ceiling repeatedly, and a short review template that asks what the truncated run was trying to finish. The third artefact matters most, because a ceiling that keeps cutting valuable work is a product problem, not an ops problem.

Over the following month, treat ceilings and step logs as one system. Tighten limits on bounded tasks to cut waste, loosen them where evidence shows the loop is doing useful exploration, and keep the step record as the shared ground truth for both decisions. Teams that run heavy, sustained workloads find that this discipline pays twice: fewer runaway runs, and a clear, metered explanation of every token spent.

When you are ready to run these workloads on a single metered balance with cache pricing you can reconcile step by step, open an account with Quanta and connect the tooling your team already uses.