The next agent speedup may come from calling the tool before the model finishes thinking (2026)

A new agent runtime pattern hides part of tool latency by predicting the next structured call while the model continues reasoning. The result is not a more autonomous agent. It is a faster one, provided the call is read-only, the arguments match exactly, and the product can safely throw away wrong guesses.

Quick read

Question	Answer
What changed?	The model that performs the task also predicts its own next tool call, reusing the prefix KV cache instead of running a separate draft model. 1
Where does it fit?	Search, retrieval, database lookups, and other read-only calls with enough waiting time to overlap with model reasoning. 1
What is the signal?	On the paper's 4B-scale experiments, average next-call Hit@1 rose from 44.1 to 61.2 for Qwen3-4B and from 48.9 to 66.3 for Qwen3.5-4B, while task success was preserved. 1
What blocks launch?	A wrong prediction must have no side effect, and the runtime must verify the complete tool name and argument object before reusing the result. 1

What changed

Most tool-using agents pay the same tax on every step: the model emits a call, the product sends it, the external system answers, and only then can the model continue. The model's thinking time and the network or database wait time sit one after another.

Speculative tool calling overlaps them. A single model runs in two modes. In agent mode, it reasons, calls tools, reads observations, and completes the task. In speculator mode, it sees a partial trajectory and predicts the next structured call, including the tool name and argument dictionary. The runtime executes that candidate early. If the eventual call is identical, the cached result is ready when the agent reaches it. The paper's design reuses the prefix KV cache and does not require a second draft model. 1

Diagram showing an actual agent stream and a speculation stream converging on the same flight-status tool call — The paper's example shows the useful case: both streams produce the same structured call, so the speculative result can be reused. 1

The training change is as important as the serving trick. The authors generate speculation targets from the agent's own on-policy rollouts, then alternate agent updates with speculator updates. A short supervised warmup precedes reinforcement learning. This addresses the "speculator-agent gap" that appears when a separate draft model predicts plausible calls that do not match the deployed agent's actual behavior. 1

The reported improvement is specific, not a general claim about all agents. Evaluation covers search QA and conversational tool use, with HotpotQA, MuSiQue, BrowseComp-Plus, and τ-bench Airline and Retail tasks. The main comparison is a Qwen3 or Qwen3.5 model at roughly 4B parameters, not a production frontier model. Average next-call Hit@1 improves from 44.1 to 61.2 for Qwen3-4B and from 48.9 to 66.3 for Qwen3.5-4B after the joint RL stage. 1

There is a useful predecessor. A May paper on real-time agents combined asynchronous I/O with speculative tool calling and reported 1.3x to 1.7x speedups for strong cloud models and 1.6x to 2.2x for small models across tool-calling benchmarks. Today's paper narrows the model-side problem: teach the deployed agent to predict its own next call, rather than bolt on a separate speculation policy. 2

The social signal is early and modest. An X account focused on ML systems and inference described the mechanism as issuing a likely future call while the agent is still reasoning, then reusing the result only when the call matches exactly. 3 A separate paper-monitoring account reposted the title. 4 That is evidence of fresh attention, not evidence that a major lab has shipped the feature.

Why PMs should care

The product benefit is easy to state and easy to overclaim. Speculation can reduce wall-clock latency when the next tool call is predictable and the tool itself is slow enough to overlap with reasoning. It cannot make an unpredictable workflow fast, and it does not remove the cost of a wrong call.

Three product implications matter.

The cache becomes part of the agent contract. A normal response cache asks whether two requests are equivalent. A speculation cache asks whether an uncommitted call became the committed call. That means the cache key must cover the tool identity, normalized arguments, user and tenant scope, authorization context, and freshness policy. A cached answer from the wrong account or from the wrong point in time is a correctness bug, not a performance miss.
Tool permissions determine the addressable surface. The paper explicitly positions the method for read-only calls such as search, retrieval, and database lookup. Orders, record updates, outbound messages, and other mutations need dry-run semantics, rollback, human confirmation, or a hard rule that speculation stops before the side effect. 1 The first pilot should therefore target an information-gathering workflow, not a customer-support workflow that can change an account.
Latency needs a new decomposition. Track model time, tool wait time, speculative execution time, and committed time separately. The useful metric is not Hit@1 alone. A prediction can be correct but arrive after the real call, or be cheap to execute but save almost no user-visible time. The PM scorecard should include:
- exact next-call Hit@1 and argument-level match rate;
- speculative execution acceptance rate and wasted-call rate;
- p50 and p95 end-to-end latency, split by tool and workflow;
- cost per successful task, including discarded calls;
- stale-result, authorization, and cache-invalidation failures;
- task success and user correction rate before and after the feature.

The closest public production precedent is adjacent rather than identical. Netflix describes an in-house serving platform built around a unified JVM control plane, Triton, and vLLM. Its team added custom decoding support, pinned compatible serving versions, used red-black or versioned rollout depending on interface risk, and merged vLLM and Triton metrics because the default bridge exposed only 9 of more than 40 vLLM metrics, including important cache signals. 5 The lesson for speculative tool calling is practical: the feature belongs in the serving layer, and it will be difficult to debug if speculative branches, cache utilization, and rejected results are invisible.

For a concept primer, Modal's 40-minute explainer, Speculation is all you need: Intro to Speculative Decoding for High Performance Inference, walks through the draft-and-verify pattern and the production tradeoffs around acceptance metrics, format shifts, and MoE verification cost. It was published on March 12, 2026 and had 1,316 views in the retrieved metadata, so treat it as an accessible explanation of the underlying idea rather than a current adoption signal. 6

How to implement now

Pick one read-only workflow with measurable wait. Start with search, retrieval, or a database lookup that appears repeatedly after a recognizable reasoning prefix. Record the current tool latency and the fraction of runs in which the next call is stable. Do not start with a workflow whose value depends on a mutable external state changing between prediction and commitment.
Add a shadow speculator before executing anything. Produce a candidate call, but only log whether it matches the agent's eventual call. This gives the team a baseline for Hit@1, argument drift, and the possible latency savings without creating side effects or cache pollution.
Execute only safe candidates. Require an explicit read-only permission class, a bounded timeout, tenant-aware cache keys, and a freshness limit. Keep the speculative result marked as uncommitted. The agent must still emit the final call and pass exact structural comparison before the runtime serves the cached result.
Roll out behind a workflow-level flag. Use a holdout group and compare p95 latency, task success, stale-result rate, and cost per success. Keep a synchronous path available when the prediction is low-confidence, the tool is stateful, or the cache is cold. Netflix's rollout experience is a useful precedent here: pin the serving image, expose the metrics that the scheduler actually needs, and use versioned deployments when an interface change makes a mixed rollout unsafe. 5
Promote the model only after held-out workflows pass. The paper's results are promising, but they cover two task families and 4B-scale models. Before treating self-speculation as a platform capability, test code execution, web navigation, long-running workflows, and any tool that returns user-specific or fast-changing data. Those are exactly the cases where prediction confidence, freshness, and side effects can break the apparent speedup. 1

The PM takeaway is narrow but actionable: speculative tool calling is a latency-hiding primitive, not a new autonomy layer. Pilot it where the next call is predictable, the tool is read-only, and a wrong guess is cheap to discard. The launch decision should be based on saved p95 milliseconds per successful task, not on a Hit@1 number detached from cache freshness, waste, and rollback behavior.

The next agent speedup may come from calling the tool before the model finishes thinking

Quick read

What changed

Why PMs should care

How to implement now

References

Related content