ToolGrad builds training examples for AI tool use. It constructs a working sequence of software calls and writes a matching request and answer. Researchers then use those examples to train a model.
That is a narrower and more useful idea than an assistant rebuilding itself during a chat. The interesting questions are what gets improved, when the training happens and how much the result carries over to real requests.
Google Research published its ToolGrad explainer on September 10, 2026. The paper’s history starts in August 2025, with version three in June 2026. The new blog explains an existing research project.
What ToolGrad changes
ToolGrad starts with usable tool steps, then builds the request around them. That reverses the approach of inventing a request first and searching for a solution.
A tool call asks another piece of software to do something. A library assistant might search a catalog, check which branch has a book and look up that branch’s opening hours. One call’s result can supply information the next call needs.
My guide to AI agent workflows covers checking the results of tool actions in everyday work. ToolGrad addresses a different job, preparing examples from which a model can learn to make those calls.
A practice example needs more than a plausible answer. The request, calls and reply should agree. If the request asks where a book is available, an answer containing only the book’s author leaves the job unfinished.
Building one practice example
Imagine a library with separate catalog, availability and opening-hours tools. This is a made-up illustration, not a ToolGrad run, a real library system or a research result.
The framework proposes candidate additions, executes them, selects a useful addition and updates the matching request and response. It repeats this process as the workflow grows. Google describes these four modules.
Here is how an example could develop.
- Find a usable starting result. A catalog lookup returns the identifier for a book. The example now has something a later call can use.
- Try an addition. An availability lookup accepts that identifier and returns a branch with a copy. A failed lookup would not establish that result.
- Extend the example. Suppose the availability call is selected. The request and answer are revised so they ask and answer where the book can be found.
- Consider another step. A branch-hours lookup could support a request that also asks when to visit. The wording must change again to match the expanded work.
The actual method makes selections using model judgments and execution reports. In ToolGrad, textual gradients guide changes to the example being constructed. They are not numerical updates to the student’s internal model weights. The paper explains this distinction.
You can picture the output as one practice sheet containing the question, the working steps and the answer. Building the steps first helps the author know which question the sheet can support.
A real user still asks first. Writing practice material in reverse does not mean a deployed assistant gets to replace your request with an easier one.
When does model training happen?
Training the student is a separate stage. The author repository provides distinct paths for generating examples, formatting data, fine-tuning Gemma 3 and evaluating the resulting models.
Fine-tuning means giving an existing model additional training on examples. That training adjusts the model’s learned settings, often called weights. Editing a practice sheet and changing a model through training are different operations.
For our imaginary library, constructing another successful branch lookup would produce more training material. It would not, on its own, change the student model. A later training run would have to use that material.
The researchers’ dataset is called ToolGrad-500. The repository links the dataset and provides training and model-evaluation instructions. I have not run those instructions or independently reproduced the reported results.
For someone inspecting the project, I would start by opening a dataset example and tracing its request through the calls to the reply. That is a useful reading exercise before deciding whether reproducing the training serves a real need.
Did the student really outperform its teacher?
The starting model matters. The paper says Gemma-3-12B already exceeded the data generator, gemini-2.5-flash-lite, on both reported benchmarks before this fine-tuning. The generated examples improved it further. See the paper’s bootstrapping discussion.
The student therefore did not receive every useful ability from the model preparing its examples. It arrived with earlier training.
If I were checking a claim that one model taught another to outperform it, I would put three results beside each other.
- The generator’s score on the same test.
- The student’s score before the additional training.
- The student’s score after that training.
The first comparison tells you whether the student beat the generator. The second tells you how much the student changed. Combining those questions can make an improvement sound more mysterious than it is.
A less capable assistant can still help prepare useful exercises. A person writing a practice worksheet does not need to outperform every student who studies it.
What does a successful tool-use result prove?
The reported improvements concern tool calling on the tested benchmarks. Google’s comparison uses tools different from those used to build the training data. That is useful evidence of transfer within the tested setting, not a ranking of every skill an assistant might need.
Scores also improved on real-user questions in the Berkeley Function Calling Leaderboard (BFCL). The gains were larger on its synthetic question sets.
The BFCL evaluation used single-turn tasks. Multi-turn and agent tests were outside the study. The paper reports the breakdown alongside those limits.
Google also reports a high pass rate for generating data. That rate describes example construction, not the share of arbitrary customer requests a deployed model will complete. The experiment sections give the scope.
Return to the library example. A call might run correctly and return opening hours for the wrong branch. Or the answer might use last week’s schedule even though the person asked about a holiday.
Those are possible mistakes in our illustration, not failures reported in the study. They show why I would inspect the inputs, returned information and final answer separately. A successful call is one piece of evidence.
Will ToolGrad keep learning while I use it?
Continuous learning for personalization is future work in Google’s explainer. The reported project does not establish that an everyday chatbot retrains itself during normal use. Google’s future-directions section makes that boundary clear.
The paper also reports limits from scaling generated data, repetition across independently produced samples, differences from human requests and transfer to broader reasoning workflows. Its discussion and limitations explain the open questions.
A library user might ask whether they can pick it up after work. That request needs context about the book, the branch and the person’s intended time. A neat practice question written after finding a solution may not contain that ambiguity.
Changing the book title in the same exercise a thousand times would also leave important cases untouched. An unavailable book, two matching titles or a broken lookup would require different checks. This is my illustration of coverage, not a measurement of ToolGrad’s dataset.
How I would read the next self-improvement claim
First, locate the change. Is the system revising its working example, training a model or adapting during real use? Ask for the evidence that connects one stage to the next.
Then match the result to the task you care about. For an assistant that helps with research or files, I would want to see how it handles missing information, a failed call and a result that conflicts with the request.
These questions do not cancel a useful benchmark result. They help decide what to test next before relying on the method in a different setting.
For ToolGrad, the useful idea is concrete. A working solution can help create better practice material. The next test for your own workflow is whether those gains carry over to the requests and failure cases you actually encounter.
For more practical explanations of AI tools and how I use them, join the softDev23 newsletter. It covers news, guides and product updates.
Sources originally checked September 13, 2026; primary research sources rechecked September 15, 2026.
