Why Your Agent Makes 40 Tool Calls to Do a 6-Call Job

Sprawl Is a Cost, a Latency, and a Trust Problem — In That Order of Visibility

Tool-call sprawl shows up on three meters, but you notice them in reverse order of how much they actually matter. The token bill is the loudest — every redundant retrieval re-injects a few thousand tokens of context, and a chatty agent can 3–4x its own input cost without changing a single output. Latency is next: each sequential tool call adds a full round-trip plus model think-time, and users feel a multi-step agent that takes fifteen seconds far more than they feel the invoice.

The one that actually kills the product is trust. When an agent visibly re-reads the same file, asks the same question two different ways, or contradicts a result it just produced, the user concludes — correctly — that it doesn't know what it's doing. We've watched internal pilots get quietly abandoned not because answers were wrong but because the path to them looked unhinged. The output was fine; the behaviour wasn't legible.

The trap is that none of this shows up in your averages. Median trajectories look healthy. The damage lives in the tail — the 10% of requests where the agent enters a loop and burns thirty calls. That tail is where your cost, your latency SLO, and your reputation all die at once.

Instrument Step Counts Before You Touch the Prompt

The first move is never a prompt tweak. It's measurement. You cannot reason about sprawl from a chat transcript — you need structured telemetry on every trajectory. We log, per request: total tool calls, calls per distinct tool, repeated calls with identical or near-identical arguments, tokens consumed at each step, and wall-clock latency split between tool execution and model inference.

Then you look at distributions, not means. Plot tool-call count as a histogram and the bimodal shape jumps out immediately: a tight cluster of well-behaved trajectories and a long, ugly tail of thrashers. That tail is your whole problem. Optimising the median is theatre; the tail is where the budget goes.

A few heuristics we apply when standing up this instrumentation:

• →Tag every tool call with a hash of its normalised arguments so duplicate retrievals are trivially countable.
• →Track 'information gain' as a proxy — did this step add a new entity, document, or fact to the working set, or just re-fetch something already present?
• →Separate model latency from tool latency; a slow agent is sometimes a slow API, not a confused planner.
• →Alert on per-trajectory step count over a threshold, not on aggregate cost — the tail is what you want paged about.

Thrashing vs. Reasoning: The Diagnostic Is Information Gain

The hard judgment is telling productive multi-step reasoning apart from a doom loop, because on a step-count graph they look identical. A genuinely hard task legitimately needs many calls. The distinction isn't how many steps — it's whether each step changes the agent's state.

Genuine reasoning narrows the problem: each tool call returns something new, the working set grows, and the next action is conditioned on the last result. Thrashing is the opposite — the agent re-reads context it already holds, re-runs a query with cosmetically different arguments, or oscillates between two hypotheses without committing. The signature of thrashing is high step count with flat information gain. Steps go up; the working set doesn't.

Second-guessing loops are the most common variant we see. The model gets a correct tool result, distrusts it (often because of the same poorly-calibrated self-confidence that breaks human-in-the-loop gates), and re-derives it a different way to 'check.' That instinct is reasonable in a human and catastrophic in a loop with no stopping rule. It's also why your eval harness needs to score trajectories, not just final answers — a right answer reached by flailing is a latent production incident.

The signature of thrashing is high step count with flat information gain. Steps go up; the working set doesn't.

Three Techniques That Actually Cut Sprawl

Once you can see the tail, three interventions do most of the work in our delivery. None of them are exotic; the discipline is in applying them deliberately rather than hoping a bigger model fixes it.

Action-space pruning is the highest-leverage and the most overlooked. Most agents are given too many tools, with overlapping responsibilities and vague descriptions, and they thrash trying to choose. Cut the toolset to the minimum, make each tool's purpose mutually exclusive, and gate tools by state so the agent literally cannot call a retrieval it doesn't need yet. A smaller, sharper action space removes whole categories of wrong turns.

Forced commitment breaks the second-guessing loop. Make the agent state a plan and a step budget up front — 'this will take roughly four retrievals and one synthesis' — and then hold it to that contract. When it tries to re-verify a result it already has, the planning scaffold can refuse. We pair this with mid-trajectory eval checks: a lightweight check that fires partway through a long trajectory and asks, in effect, 'is this still making progress, or should we stop and return what we have?' That single circuit-breaker prevents the worst tail trajectories from ever completing.

• →Action-space pruning: fewer tools, non-overlapping descriptions, state-gated availability.
• →Planning budgets: force an upfront step estimate and treat overruns as a signal to halt, not to keep going.
• →Forced commitment: once a tool returns a valid result, forbid re-derivation unless an explicit contradiction is detected.
• →Mid-trajectory eval checks: a progress probe that can terminate a thrashing run early instead of letting it burn the budget.

Be Honest: Most Sprawl Is Bad Tool Design, Not a Bad Model

Here's the uncomfortable part. When we audit a sprawling agent, the root cause is usually our own tool layer, not the model's reasoning. The model is compensating for tools that lie about what they do or return more than they should.

The patterns repeat. A tool description says 'searches documents' but actually only searches one index, so the agent calls it repeatedly hoping for different scope. A retrieval tool returns 8,000 tokens of raw chunks, so the agent re-reads to find the relevant line and burns context every time. Two tools overlap, so the model tries both 'to be safe.' An error returns an empty result instead of an explicit failure, so the agent retries blindly. In every case the model is behaving rationally given a broken interface — the same way RAG that works in the demo falls apart in production because retrieval quality was never the thing being measured.

Before you reach for chain-of-thought tuning or a frontier model upgrade, audit the tools. Tighten descriptions to be specific and disjoint. Make tools return narrow, structured results instead of dumps. Make failures explicit and typed. Most of the sprawl we've eliminated came from fixing the interface, not the prompt — which is also cheaper and more durable than prompt-whispering against a moving model.

What's Still Hard, and Where to Start

None of this is fully solved. The genuinely difficult open problem is the thrashing-vs-reasoning boundary on novel, hard tasks: an aggressive step budget that protects your tail will also clip legitimate deep reasoning on the rare request that actually needs it. Tuning that threshold is empirical, per-workflow, and it drifts as the model and the task distribution change — which is why this lives or dies on a trajectory-level eval harness rather than vibes.

Mid-trajectory progress detection is also still crude. 'Information gain' is a useful proxy but it's gameable — an agent can fetch new-but-irrelevant data and look productive. And forced commitment trades one risk for another: commit too early on a wrong path and you've built a fast way to be confidently incorrect.

The practical starting point is unglamorous: instrument step counts, plot the distribution, and stare at your ten worst trajectories. You will learn more from reading those ten transcripts than from any benchmark. Nine times out of ten the fix is a sharper tool layer and a planning budget — not a better model.