Research

MachinoAI Research

TRENDINGAI Agents

ToolGrad: Efficient Tool-use Dataset Generation with Textual “Gradients”

Generate the successful tool-use workflow first, then synthesize the user query around it.

Zhongyi Zhou, Kohei Uehara, Haoyu Zhang, Jingtao Zhou, Lin Gu, Ruofei Du, Zheng Xu, Tatsuya HaradaJun 17, 2026Findings of ACL 202610 min read
AI Agentstool useagentssynthetic dataLLM post-trainingTextGradfunction callinganswer-first data generationtextual gradientsAPI workflow synthesis

TL;DR

ToolGrad uses proposer, executor, selector, and updater modules to build verified API workflows; its ToolGrad-500 dataset reaches a 99.8% generation pass rate and trains compact Gemma-3 models that perform strongly on tool-use benchmarks.

Why It Matters

Tool-use data generation is often the bottleneck for reliable agents. ToolGrad reframes dataset construction so successful tool chains are produced before prompts, reducing failed exploration and making long-horizon tool-use data cheaper to generate.

Research Brief

The shortest useful explanation.

ToolGrad uses proposer, executor, selector, and updater modules to build verified API workflows; its ToolGrad-500 dataset reaches a 99.8% generation pass rate and trains compact Gemma-3 models that perform strongly on tool-use benchmarks.

answer-first data generationtextual gradientsAPI workflow synthesistool-use fine-tuningOOD tool usetool useagentssynthetic data

Core Explanation

Prior work generates a user query and then searches for a tool-use solution, causing annotation failures and high cost. ToolGrad reverses the order: it first constructs valid tool-use chains through iterative textual-gradient-guided API selection, then synthesizes the corresponding query and response.

Why It Matters

Tool-use data generation is often the bottleneck for reliable agents. ToolGrad reframes dataset construction so successful tool chains are produced before prompts, reducing failed exploration and making long-horizon tool-use data cheaper to generate.

ToolGrad constructs tool-use chains from API mini-batches before synthesizing the user query.

ToolGrad answer-first generation

Official Google Research figure contrasting query-first tool search with ToolGrad API mini-batch construction.

ToolGrad iterative workflow with API proposal, execution, selection, and update.

ToolGrad workflow

Official figure showing proposer, executor, selector, and updater stages.

Table comparing pass rate, ground-truth tool uses, LLM cost, and optimization steps.

Generation efficiency comparison

Original result table comparing DFS and ToolGrad generation efficiency.

Section 01

Problem

01. Problem

Tool-use datasets are expensive to create because the conventional pipeline first invents a user query and then searches for a valid API execution path. The search can fail, waste tool calls, and preferentially produce short trajectories. ToolGrad asks whether the direction can be reversed: construct a verified tool-use solution first, then synthesize the query and response from that solution.

1Query-first generation creates an instruction and then searches for a solution.2DFS-style exploration can have low pass rate and high generation cost.3Long-horizon successful workflows are difficult to obtain reliably at scale.

Section 02

How It Works

03. How It Works

Each iteration samples an API mini-batch. An API Proposer selects up to m candidate APIs. API Executors run the candidates in parallel and return execution reports. An API Selector chooses the most valuable API and identifies the chain it should extend. The Workflow Updater appends that API and asks an LLM to regenerate the query and response so the sample remains coherent. The loop repeats for a fixed number of iterations.

1API Proposer -> candidate APIs.2API Executors -> parallel execution reports.3API Selector -> best API and target chain.4Workflow Updater -> new workflow plus query and response.

Section 03

Architecture

05. Architecture

ToolGrad is an agentic data-generation loop around a large API library. The main control plane contains four modules: proposer, executor, selector, and updater. Executors are parallelized because execution is the expensive step. The final generated artifact is a triplet containing a user query, a verified API workflow, and the response.

1Input: API database and current workflow.2Control loop: proposer -> executors -> selector -> updater.3Output: query, workflow, response triplet.4Generation configuration in v3: m=3 proposals, batch size bs=50, 10 iterations, p=10 negative APIs, Gemini-2.5-Flash-Lite for generation.

Section 04

Experiments

06. Experiments

The authors compare ToolGrad against DFS-based ToolBench generation and evaluate models fine-tuned on ToolGrad-500 against ToolBench and BFCL. Generation efficiency is measured by pass rate, ground-truth tool uses, LLM cost, and tool cost. Tool-use quality is evaluated on ToolBench and BFCL, including subscale breakdowns.

1Generation: DFS pass rate 63.8% vs ToolGrad 99.8%; ground-truth tool uses 2.1 vs 3.4; LLM cost 64.5 vs 63.9; tool cost 34.3 vs 20.0.2ToolBench single-turn scores: ToolGrad 1B 14.1, 4B 17.6, 12B 19.6.3BFCL ToolGrad 12B non-live overall 75.25; 4B 65.33; 1B 49.08.4BFCL ToolGrad models improved over their corresponding Gemma-3 baselines on 19 of 24 subscales.

Formulas

ToolGrad dataset representation

mathcalD=(q,mathcalW,r)\\mathcal{D}=\\{(q,\\mathcal{W},r)\\}

A training sample contains a user query q, an API workflow W, and a response r.

WAPI workflow composed of chains
quser query
rresponse conditioned on the workflow

API proposal

(textttAPIi,textttinsti)i=0i<m=textttLLMpr(textttAPIbs;mathcalWt)\\{(\\texttt{API}_i,\\texttt{inst}_i)\\}_{i=0}^{i<m}=\\texttt{LLM}_{pr}(\\{\\texttt{API}\\}^{bs};\\mathcal{W}_t)

The proposer filters a random API mini-batch into at most m candidates for extending the current workflow.

mmaximum number of API proposals
bsAPI mini-batch size
W_tcurrent workflow

API selection

j=argmaxiV(mathrmrepim,mathcalWt)j=\\arg\\max_i V(\\{\\mathrm{rep}_i\\}^m,\\mathcal{W}_t)

The selector chooses the API with the highest hypothetical value based on execution reports and the current workflow; in practice an LLM acts as the proxy for V.

Vhypothetical value function
jselected API index
rep_iexecution report for candidate i

Related Research

References