Google's ToolGrad back-writes the user query from a chain it has already executed

Answer-first only works if the answer can be checked, and ToolGrad checks it by running it. Its loop has four modules that propose, execute, select and update, and it repeats until the sample contains a user query, a verified API workflow and a final AI response ^[9]. The query arrives afterwards, from a single LLM step, because the authors argue an explicit tool-use solution is less ambiguous input than a prompt ^[6].

Each pipeline spends its money in a different place. In the query-first version the target is fixed before search starts: sample from an API pool, write a hypothetical instruction, then send a depth-first-search agent after a chain that satisfies it ^[4]. The Google post calls this "inherently inefficient because its core concept is to distill valuable trajectories from a complex agent exploration for training an LLM" ^[5]. ToolGrad's loop has no instruction to satisfy, so a proposal that fails execution feeds the update step and the workflow it was extending survives ^[9].

In ToolGrad, the gradient is text. TextGrad used an LLM critic to produce plain-text feedback for refining a prompt, and ToolGrad aims the same feedback at constructing valid API workflows out of a large tool library ^[7][8]. In the experiment that library was ToolBench, 16k+ real-world APIs ^[10]. That group hand-annotated evaluation data for its earlier InstructPipe work and says that does not scale to fine-tuning ^[16].

What is worth arguing about is the out-of-distribution result. Gemma-3 at 1B, 4B and 12B were fine-tuned on ToolGrad-500 and evaluated on BFCL, whose tool set differs from ToolBench's ^[12][13], against base models, the proprietary Gemini, GPT and Claude, and the tool-use specialists ToolACE and Hammer-2.1-7B ^[14]. The post says the fine-tuned models match state-of-the-art proprietary LLMs on OOD datasets with unseen tools ^[15]. For that to reach another stack, your tools have to be callable during generation, because calling them is what establishes that a chain is valid ^[9]. And your schemas have to sit close enough to ToolBench's API surface that a chain built there resembles a chain your model will be asked for ^[10].

That cost claim is load-bearing and, in the post's prose, unquantified: more complex data at a higher pass rate for lower generation cost, with no figure on any of the three gaps ^[11][18]. ToolGrad-500 is the name of the dataset, as close as the prose comes to a quantity ^[12]. Those three fine-tunes span a 12x parameter range from 1B to 12B ^[17], and the post reports them as a set, so the size at which a 500-scale recipe stops holding is not stated ^[12].