MidTool puts general tool use into the model's mid-training stage
A new Snowflake and University of Washington paper shows how dedicated mid-training can improve an agent's tool grounding, multi-step execution, and recovery—and gives PMs a concrete test for whether a tool-use prior matters in their own workflow.
An agent that can call a tool once in a demo still has to learn four separate behaviors in production: recognize when a tool is relevant, fill its schema from messy context, chain several calls, and recover when a response is incomplete. A new Snowflake and University of Washington paper argues that teams may get better results by teaching those behaviors during mid-training—the stage between broad pre-training and task-specific post-training—rather than leaving all of them to prompt examples and fine-tuning.
Quick take
| Field | PM read |
|---|---|
| Trend | General tool use is becoming a model capability that can be shaped before the final agent fine-tuning stage. MidTool is an open data-construction pipeline built specifically for that purpose. 1 |
| Fresh signal | Fengqing Jiang, Yite Wang, and colleagues submitted MidTool to arXiv on August 20, 2026. The team includes researchers from Snowflake, the University of Washington, and the University of North Carolina at Chapel Hill. 2 |
| Problem solved | Post-training traces are narrow. Documentation, API specifications, code, tool schemas, and failure cases contain the broader knowledge an agent needs to choose and operate tools. MidTool turns those materials into training data for grounding, composition, clarification, and recovery. 1 |
| Evidence boundary | The reported gains come from Qwen3 4B and 8B base models, a fixed set of supervised fine-tuning and reinforcement-learning recipes, and three agent benchmarks. The results are evidence for a training direction under that setup; they are not a production reliability guarantee. 1 |
| Action window | This week, choose one workflow with a stable tool catalog and a human acceptance decision. Test whether a model with a stronger tool-use prior reduces invalid calls, repair turns, and handoff failures before you consider a larger model. |
What changed
Mid-training adds a targeted learning stage after a model has learned general language and code, and before a team teaches a narrower task through supervised fine-tuning or reinforcement learning. MidTool asks whether that stage can give a model a reusable prior for general tool use.
The authors built MidTool-Mix, a corpus with 20.3 billion tokens and 11.22 million samples. The mixture contains web pages, PDFs, code repositories, and native agent trajectories. Web data accounts for 42% of the token budget, code for 26%, PDFs for 23%, and native agentic trajectories for 9%. 1
The pipeline has two distinct synthesis branches:
- Context-grounded augmentation turns documentation and code into question-and-answer examples and tool trajectories. The examples teach a model to find a tool boundary, infer arguments from surrounding text, and recover the structure of a workflow.
- Native agentic synthesis builds executable trajectories from real APIs, Model Context Protocol (MCP) skills, and collected rollouts. The pipeline validates schema grounding, turn order, required arguments, and consistency between a tool call and its response. 1
The experiment starts with Qwen3-4B-Base and Qwen3-8B-Base. The authors compare supervised fine-tuning alone with mid-training followed by the same fine-tuning recipe, then add reinforcement learning in a second comparison. Mid-training and supervised fine-tuning use 32 H200 GPUs. The reinforcement-learning setup uses 526 synthetic tool-use environments on 8 B200 GPUs. 1
The performance pattern is clearest on harder, multi-step tasks. The table below reports the overall BFCLv3 score and the overall Pass@1 score on τ²-Bench. BFCLv3 measures function calling, including multi-turn interactions and hallucinated calls. τ²-Bench tests interactive completion in airline, retail, and telecom environments. 1
| Base size | Recipe | BFCLv3 overall | τ²-Bench overall Pass@1 |
|---|---|---|---|
| 4B | SFT only | 39.73% 1 | 8.54% 1 |
| 4B | MidTool-Mix + SFT | 50.25% 1 | 12.23% 1 |
| 4B | MidTool-Mix + SFT + RL | 54.18% 1 | 19.96% 1 |
| 8B | SFT only | 47.62% 1 | 10.43% 1 |
| 8B | MidTool-Mix + SFT + RL | 55.12% 1 | 21.31% 1 |
MidTool-Mix also raises the 4B model's overall MCP-Universe score from 13.20 with SFT alone to 23.80 after mid-training, SFT, and RL. The corresponding pass rate rises from 1.68% to 10.06%. The 8B model reaches an overall score of 25.16 and a pass rate of 9.50% after the same sequence. MCP-Universe covers browser automation, finance, location, multi-server workflows, and web search. 1
The paper's own results also set a useful boundary. Telecom remains difficult on τ²-Bench, and web search remains weak on MCP-Universe. The authors describe search-heavy and exploratory behavior as a separate supervision problem. A general tool-use prior appears to transfer more readily than an ability to conduct open-ended research. 1
Why PMs should care
The model choice now includes a training prior
A model comparison that lists context length, price, and benchmark scores misses a product-relevant variable: what the model already learned about tools before your team added its own instructions.
For an agent product, the deployment unit is closer to model + tool schemas + context policy + execution harness + evaluator. MidTool's result suggests that a model with a broad tool-use prior may need fewer examples to learn a new tool family. The paper does not establish that transfer for your tools, so the product question becomes measurable: how many examples and repair turns does your workflow need before it reaches an acceptable handoff rate?
That question changes the buying decision. A smaller model with a better tool-use prior may beat a larger general model on a bounded workflow. A larger model may still win when the workflow depends on open-ended search, deep domain reasoning, or code-heavy interaction. Run the comparison on the workflow you ship rather than on tool-calling accuracy alone.
Tool schemas become training data and product surface
The paper treats documentation, code, APIs, and MCP skills as learning material. Zalando's August 2026 engineering account describes the same problem from inside a large organization: its teams found that missing hostnames in API specifications made it impossible to generate working API calls. Zalando also built a proxy that injects authentication headers, supports MCP access, records client identity and cost, and lets teams switch among model providers. 4
The product implication is direct. A tool catalog is part of the model's operating environment. Each tool needs a stable name, a precise description, typed arguments, authentication behavior, usable error responses, and examples that reflect real context. A model trained on clean schemas still encounters expired credentials, partial responses, ambiguous entities, and permission failures. Those cases belong in the evaluation and training loop.
Zalando reports another practical control: internal tools identify the calling application and repository in the
User-Agent, while the proxy tracks model, token, cache, and cost metadata. 4 That metadata gives a PM a way to connect model behavior to a product surface: which workflow caused the call, which tool version answered, and how much the repair loop cost.A valid call is only the first checkpoint
MidTool measures whether an agent selects a tool, supplies arguments, completes multiple turns, and adapts to unfamiliar tool environments. Your product should add the final checkpoint: whether the answer uses the returned evidence and satisfies the human handoff standard.
The paper's exploratory visual-tool experiment makes the distinction visible. MidTool-Mix raises tool success on a single-turn VisualToolBench subset from 0.5863 to 0.7231 in the authors' setup, while the overall rubric score moves from 0.0567 to 0.0661. The authors also report cases where a model invokes a tool successfully and then fails to ground its final answer in the returned evidence. 1
For a quick implementation refresher, Nicholas Broad's Training an Open LLM for Tool Calling with Reasoning walks through data format, training, reasoning traces, τ²-Bench, and benchmark results. The 28-minute video was published on February 10, 2026 and had 1,617 views when retrieved. It is useful as an accessible orientation to the mechanics; its age and audience size make it an explainer signal rather than evidence of current adoption. 5
Loading content card…
How to implement now
A team can test the product value of a tool-use prior without starting a foundation-model program. Use the following path for one workflow.
- Choose a workflow with a real handoff. Pick a task such as support-case resolution, internal data lookup, or a bounded research packet. Give the task a named user, a stable tool set, a known output format, and a person who currently accepts or repairs the result. Record the manual acceptance criteria before collecting agent traces.
- Turn the tool catalog into an owned artifact. Version every tool name, description, argument schema, permission, timeout, and error shape. Add examples with ambiguous inputs and incomplete information. Assign an owner to each tool family. A model cannot learn a stable behavior from a catalog that changes without a compatibility record.
- Collect both grounding and execution examples. Preserve the source documentation and the generated example together. Include a direct call, a multi-step call chain, a clarification turn, a malformed response, an expired credential, and a safe refusal or escalation. Keep raw tool responses so an evaluator can check whether the final answer used the evidence.
- Validate synthesized traces before training. Add deterministic checks for required arguments, enum values, tool order, permissions, and response-to-call consistency. Add a review step for whether the trajectory solves the user's task. Hold out benchmark instances and tool schemas while filtering for accidental overlap. MidTool uses teacher models and validation in its synthesis branches; the paper identifies dependence on strong teachers as an open research question. 1
- Run a controlled model comparison. Keep the prompt, tool definitions, SFT data, RL environments, and evaluator fixed while comparing the current model with a model or checkpoint that has a stronger tool-use prior. Measure valid-call rate, argument accuracy, clarification quality, multi-turn completion, recovery after tool errors, evidence grounding, latency, and cost per accepted task. Separate partial progress from a completed handoff.
- Promote on held-out workflows. Test unfamiliar schemas, changed tool versions, missing fields, permission failures, timeouts, duplicate actions, and conflicting tool responses. Require the agent to preserve human approval for irreversible actions. Promote the model only when completion, repair rate, cost, latency, and safety meet the workflow's threshold across repeated runs.
The small PM experiment is straightforward: select one workflow, freeze its tool catalog for a test period, and compare two model paths on the same held-out tasks. If the model with the stronger tool-use prior reduces repair turns while preserving evidence grounding, mid-training belongs in your model strategy. If the gains appear only on clean function calls and disappear on your real errors and permissions, invest in schemas, runtime controls, or workflow design first.
References
- 1
- 2
- 3MidTool: Mid-training Data Synthesis for Agentic Tool Use
- 4Agentic Engineering at Zalando: a snapshot
engineering.zalando.com
- 5
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.