Six-Round Tool Loops for High-Volume Teams

01 · Step 1: Give every run a six-round ceiling

A tool-using assistant can turn a simple request into a chain of searches, inspections, retries, and edits. Under sustained load, an unbounded chain becomes both a cost problem and an operational risk. Start with an explicit policy: for this walkthrough, allow at most six model rounds per run. This is an example configuration, not a universal recommendation.

Define a round as one model invocation and the handling of any tool requests it returns. Count the initial invocation, and reserve the sixth round for a final response with tool execution disabled. Enforce that restriction in the runner, not just in the prompt. If the model still requests a tool, reject the request and return a controlled limit status.

02 · Step 2: Limit tool calls separately from rounds

Round depth does not bound total work. One response can request several tools, and a tool can trigger additional work internally. Add independent ceilings for total tool executions, parallel executions, elapsed time, model tokens, and response size. Propagate the remaining budget to nested agents and tool services; never give each child a fresh allowance.

• › Before a model call: check the remaining rounds, deadline, and token allowance.
• › Before a tool dispatch: check the execution allowance, permissions, argument validity, and remaining time.
• › After any result: update usage and decide whether another round is permitted.

Place these checks in application code. A model such as Claude Sonnet 5.5 can propose the next action, but the runner must retain authority over whether that action happens.

03 · Step 3: Record the decision before dispatching the tool

Create a run identifier at admission and a step identifier for each attempted action. Before dispatch, durably record the parent step, round number, requested tool, validated arguments or a protected reference to them, policy decision, and intended execution identifier. If the journal is unavailable, pause or fail closed rather than performing an unrecorded side effect.

Then append state transitions: dispatched, succeeded, failed, timed out, or outcome unknown. Record timestamps, latency, result references, error categories, and budget changes. Keep tool-call identifiers so results can be matched to requests. Log the operational decision and outcome, not private model reasoning. Redact credentials and sensitive payloads, and apply access controls and retention limits to the journal.

04 · Step 4: Make retries consume budget and preserve identity

A timeout does not prove that a tool failed. A deployment request may have completed even when its response never reached the runner. Mark that attempt as outcome unknown and reconcile with the downstream system before trying again.

For tools that support idempotency, reuse a stable key for the same logical action. Do not generate a new key merely because transport failed. Count each retry attempt against an execution budget, and bound retry delay by the run deadline. For irreversible actions without reliable reconciliation, require human review instead of automatic replay. Durable records improve recovery; they do not create exactly-once execution by themselves.

05 · Step 5: Meter tokens alongside execution events

For heavy workloads, the useful accounting unit is the complete run, not just the final model response. Attach available usage data to each model invocation, then aggregate it with tool executions and elapsed time. Keep cache writes and cache reads separate from other token categories, and distinguish estimated reservations from reported usage.

Quanta fits naturally as a pay-as-you-go API relay for teams consolidating sustained model traffic under one balance. Every call is metered on real tokens, with cache writes and cache reads priced separately. Open a Quanta account to put your bounded runner behind a shared relay while keeping execution policy and audit records in your own application.

06 · Step 6: Roll out with deliberate failure cases

Test looping searches, repeated invalid arguments, oversized results, partial parallel failures, and crashes between dispatch and journal updates. Verify that every termination produces a clear status, completed-work summary, unresolved-action list, and explanation of the exhausted limit.

Start with read-only tools and a small traffic slice. Track limit hits, unknown outcomes, retries, and cost per completed run. Increase limits only when traces show useful progress, not merely because more rounds produce longer answers. The goal is bounded, recoverable work whose cost and actions remain explainable.