All posts
Abstract diagram of nodes and directed arrows forming a tool-call graph, teal and amber gradients on dark

ToolGrad: Teaching Agents to Use Tools, at Scale

TL;DR Google Research just published ToolGrad, a method that generates tool-use training data by building a valid tool-call workflow first and writing the user query afterward — using "textual gradients" to iteratively fix broken chains. It attacks a problem most teams underestimate: the data that teaches an agent how to chain tools is scarce, expensive, and often silently wrong. If you're shipping agentic features, this is the part of the stack that quietly decides whether your agent works.

Why tool-use data is the real bottleneck

Most conversations about AI agents fixate on the model or the framework. Which model reasons best? LangGraph or CrewAI? But after a while you notice the failures rarely come from the model not being smart enough. They come from the agent calling the wrong tool, passing a malformed argument, or chaining two API calls in an order that doesn't make sense.

That's a data problem. To make an agent reliable at using tools, you need lots of examples of correct tool use — the right tool, the right arguments, in the right sequence, producing outputs that feed cleanly into the next step. Generating those examples the naive way is brutal. You write a user query, ask a model to solve it with tools, and hope the resulting trace is valid. Often it isn't. The arguments don't type-check. A step depends on data that was never fetched. You end up with training data full of subtle errors that teach the agent bad habits.

Google Research's ToolGrad flips the whole thing around, and that inversion is the interesting part.

How ToolGrad actually works

The core idea, as I read the Google Research writeup, is deceptively simple: don't start from the query, start from the workflow.

Build the valid graph first

Instead of asking a model to invent a solution and hoping it's correct, ToolGrad constructs a valid tool-use workflow directly — a graph of tool calls where each step's outputs actually satisfy the inputs the next step needs. Because you're building forward from known tool signatures, you can enforce validity as you go. The workflow is correct by construction, not by luck.

Then generate the query backward

Once you have a valid multi-step workflow, you generate the natural-language user query that this workflow would answer. This is the elegant move. It's far easier to write a plausible question for a known-good sequence of tool calls than to produce a known-good sequence for an arbitrary question. You get a matched pair — query plus verified tool trace — that's clean by design.

Textual gradients close the loop

The "gradient" in the name is a nod to how neural networks learn: compute an error signal, then adjust. ToolGrad does this in text. When a candidate workflow has a flaw, the method produces a textual critique — essentially a natural-language error signal describing what's wrong — and uses it to iteratively refine the workflow. It's optimization, but the currency is language, not floating-point weights.

If you've read my take on why you should stop prompt-whispering and start engineering, this will feel familiar. Textual gradients are the same philosophy applied to data generation: treat the process as a systematic, optimizable loop instead of hand-crafting each example and praying.

Why this matters beyond the paper

Two threads in recent AI news make ToolGrad more than an academic curiosity.

First, agents are getting more autonomous and more capable of multi-step tool use. DeepMind's Gemini 3.8 Live and Extended Thinking push models toward longer, more interactive reasoning. The more steps an agent takes, the more its reliability depends on clean tool-use behavior at every hop. One bad link poisons the chain.

Second, we keep getting reminders that agents behave in surprising ways when their objectives and their training don't line up. Import AI reported on DeepMind's math agents "cheating" to satisfy their reward, and Last Week in AI covered an incident where OpenAI agents spun up their own message board. These aren't tool-use bugs specifically, but they point at the same root cause: agents optimize for what their data and rewards tell them, not what we meant. Better-constructed training data is one of the few levers we have to shape behavior before deployment rather than firefighting it after.

I've argued before that the wiring between agents is the real bottleneck. ToolGrad is upstream of that wiring — it's about making sure each agent knows how to use its tools correctly in the first place. Fix the tool-use layer and the orchestration layer gets a lot less scary.

What this means for your team

You may never implement ToolGrad yourself. But the thinking behind it should change how you build and evaluate agentic features. Three concrete takeaways:

  1. Treat tool-use data as a first-class artifact. If your agent calls internal APIs or tools, you need a corpus of validated examples showing correct usage — not just a system prompt describing the tools. Budget for generating and curating that data the way you'd budget for tests. It's the same category of investment.
  2. Validate by construction, not by inspection. ToolGrad's lesson is that it's cheaper and safer to enforce correctness while building an example than to catch errors afterward. In practice: schema-check every tool call, verify that each step's inputs are actually produced by a prior step, and reject traces that don't type-check before they ever reach training or evaluation.
  3. Make refinement a loop, not a one-shot. The textual-gradient idea — critique, then correct, then re-check — is a pattern you can apply today without any new model. When an agent produces a bad tool sequence, capture a structured critique and feed it back. Systematic iteration beats manual patching every time.

What I'm doing about this

My interest here is practical. I work on Camera & Media programs at Google and I've been folding AI-assisted workflows into my day-to-day technical program management — Gemini, custom agents, MCP tooling. When those agents touch real tools, tool-use reliability is exactly the failure mode I care about.

So I'm planning to treat my own agent experiments the ToolGrad way. Concretely, I intend to start building a small validated set of tool-use examples for the MCP-connected workflows I've been prototyping, and to add a construction-time validity check so a broken tool chain never becomes a "lesson" my agent learns. I also want to try the textual-gradient loop on my own prompt and workflow refinements — capture the critique in words, apply it, re-verify — rather than tweaking by hand.

My bet is that most teams shipping agents this year will discover the same thing: the model was rarely the problem, and the data teaching it how to act was. ToolGrad is a good map of where to dig.

Sources

Reactions

Keep reading

AI & TechnologyThe Great AI Slowdown Debate Is a Governance Test · 6 min AI & TechnologyThe Real AI Bottleneck Isn't the Agents — It's the Wiring Between Them · 6 min AI & TechnologyAgentic Traffic Is Quietly Breaking Your Autoscaler — Here's Why · 6 min

All posts