1. Introduction
Language agents increasingly call external tools before producing a final answer. A system may query a search engine, execute code, call a calculator, inspect a database, or use a structured API to reduce uncertainty before it responds [@yao2023react; @schick2023toolformer; @qin2023tool]. In many implementations, however, the decision to use a tool is left to heuristics: call the tool whenever a prompt says so, whenever confidence looks low, or whenever a fixed workflow stage is reached.
That can work operationally, but it obscures the actual trade-off. A tool call is not free. It consumes latency, tokens, external-system budget, and sometimes reliability headroom. At the same time, it may improve answer quality by exposing evidence or computation the base model did not already have. A sensible routing rule should compare those gains and costs in one unit rather than treating tool use as ceremonial structure.
This paper makes one narrow contribution. It derives a one-step expected-utility threshold for deciding whether an agent should call an external tool before answering, and then composes that threshold with an answer-versus-abstain decision. The result is not a benchmark claim. It is an analytic routing principle that states what a calibrated tool-use policy would need to estimate in order to justify another tool call.
2. Setup
Fix an input x. After internal reasoning but before any external call, the agent holds a current candidate answer a and an estimate
p=P(a is correct∣I),
where I denotes the information currently available to the agent.
If the agent answers now, let utility be
Uans(p)=pB−(1−p)H,
where B>0 is the benefit of a correct answer and H>0 is the harm of an incorrect one.
Now consider a one-step tool call. The call costs Ct>0. It returns usable information with probability s∈[0,1]. Conditional on a usable return, the agent updates to a post-tool answer whose correctness probability is p+. If the call does not return usable information, assume the agent falls back to the current answer. This fallback model is intentionally simple: it isolates the value of a tool call as the expected improvement it produces when it actually delivers useful information.
Under this setup, the tool-call action has expected utility
Utool=−Ct+s(p+B−(1−p+)H)+(1−s)(pB−(1−p)H).
The paper does not assume that p+ is directly observed. It only assumes the routing stack can estimate the expected post-tool correctness improvement well enough for decision-making on the task family of interest.
3. Main Result
Subtracting the direct-answer utility from the tool-call utility gives
Utool−Uans(p)=−Ct+s(B+H)(p+−p).
The one-step tool-call criterion is therefore immediate.
Proposition 1. Under the fallback model above, calling the tool is utility-improving if and only if
s(p+−p)>B+HCt.
The interpretation is straightforward. A tool should be called only when its success-probability-weighted improvement in answer correctness is large enough to pay for its own cost once correctness and error are converted into the same utility scale. If wrong answers are very costly, then H is large and the threshold becomes easier to satisfy. If tool calls are expensive or rarely useful, the threshold rises.
This is not a theorem about how to estimate p+−p. It is a theorem about what quantity a tool-routing policy should compare against cost once that estimate is available.
4. Answer Versus Abstain
Many tool-using agents also have a third option: abstain, defer, or hand the case to a human. Let abstention incur cost A≥0, so that
Uabs=−A.
Direct answering is preferred to abstaining exactly when
pB−(1−p)H≥−A,
which rearranges to
p≥τans:=B+HH−A.
Proposition 2. Under the answer-versus-abstain model above, the agent should answer directly rather than abstain if and only if
p≥B+HH−A.
This is the standard selective-prediction boundary written in the deployment utility units of the agent.
5. A Three-Way Routing Policy
The tool-call boundary and the abstention threshold can be combined into a simple three-way myopic policy.
- Estimate the current direct-answer correctness probability p.
- Estimate the tool-success probability s and the conditional post-tool correctness p+.
- Call the tool if s(p+−p)>Ct/(B+H).
- Otherwise, answer directly if p≥(H−A)/(B+H).
- If neither condition holds, abstain.
This policy makes the routing structure explicit. Tool use is not justified because a workflow diagram contains a tool slot; it is justified only when the expected gain from the tool dominates its cost. Likewise, abstention is not justified by generic uncertainty alone; it is justified only when direct answering falls below the relevant utility threshold.
6. Interpretation for Tool-Using Agents
The rule clarifies several recurring deployment questions.
First, there should be no universal tool-call threshold. A calculator in a low-latency math assistant, a search API in a legal workflow, and a database call in a customer-support agent can face very different benefits, harms, and call costs even if the model-side confidence estimates look superficially similar.
Second, tool value depends on both usefulness and reliability. A tool that would be highly informative when it works may still be a bad routing choice if its usable-return probability s is low or its latency cost Ct is high. Conversely, a modest tool may still be rational when wrong answers are extremely costly.
Third, the result separates calibration from orchestration. Estimating p, s, and p+ is an estimation problem. Choosing whether to answer, call a tool, or abstain is a decision problem. Those are often conflated in practice when one heuristic score is used as both a predictor and a policy.
7. Limitations and Validation Needed
The paper has substantial limitations.
The most important is that real systems rarely estimate p+−p directly. They instead rely on proxies such as historical tool usefulness, domain detectors, verifier scores, or learned routing models. If those proxies are badly calibrated, the threshold can be systematically wrong.
A second limitation is the fallback model. In reality, tool failures may degrade the final answer, trigger retries, or cause abstention rather than simple fallback to the current candidate. The present derivation chooses the simplest case because it exposes the core expected-improvement threshold cleanly.
A third limitation is myopia. There may be settings where a sequence of tool calls is jointly worthwhile even though no single call clears the one-step threshold by itself. The current result does not solve that long-horizon planning problem.
Empirical validation would therefore need at least four elements: estimates of current answer correctness p, estimates of usable tool-return probability s, estimates of conditional post-tool correctness p+, and deployment-specific utility values for B, H, and A. A serious test would compare the expected realized utility of this rule against always-call, never-call, and heuristic router baselines on the same task distribution. None of those experiments are reported here.
8. Relation to Existing Work
Tool-using language agents motivate the practical setting [@yao2023react; @schick2023toolformer; @qin2023tool]. Selective prediction and abstention theory motivate the answer-versus-abstain threshold 2. The present paper does not claim to replace those lines of work. Its narrower claim is that one-step tool use can be written as a cost-sensitive decision problem in the same utility language as abstention, yielding a compact routing boundary that states exactly when a tool call is worth buying.
9. Conclusion
External tools help language agents only when they improve answer quality enough to justify their cost. Under a one-step fallback model, the routing condition is simple: call the tool only when the success-probability-weighted correctness gain exceeds the utility-scaled call cost. Once that criterion is composed with an answer-versus-abstain threshold, direct answering, tool use, and abstention become parts of one decision rule. The claim is deliberately limited: this is an analytic routing principle and a statement of what must be estimated before it can be trusted, not an empirical benchmark result.
References
[@yao2023react; @schick2023toolformer; @qin2023tool; @geifman2017selective]