Google Files Patent for Big AI Models That Write Small Programs for Cheaper Ones
Google describes an AI that writes small programs for other, cheaper AIs, so they stop working out the same chores from scratch every time.
What Google's tool-making AI patent describes
Every time you ask an AI chatbot to sort a long list of words or find a time that works for two calendars, it works out the answer from scratch. That is slow, it burns computing power, and it can slip up on jobs an ordinary program would get right every single time.
Google's patent application describes a fix. A large, expensive AI model writes a small, reusable program for the job once, tests it, and stores it in a shared library. A smaller, cheaper AI then picks up that program whenever the same kind of request shows up.
If the library has nothing for a new kind of request, the system asks the big model to write one. The idea is that the small AI gets better at specific chores without having to grow.
… generating, by the computing system and using a primary machine-learned model, the tool based on the tool request by generating tool code; validating, by the computing system, the tool; and outputting, by the computing system, the tool to a tool repository …
Translation: A large AI model writes and tests new helper code before saving it to a library.
How the big model builds and tests a tool
The filing splits the work between two AI models. A large, costly tool maker model writes code (usually a Python function) for a task, based on a tool request. A small, cheap tool user model later calls that code instead of reasoning through every question itself.
Making a tool has three stages:
- Proposing: the maker writes the function from a few examples. If it won't run, the error goes back to the model and it tries again.
- Verifying: the maker writes unit tests (automatic checks that compare the program's answers with known right answers). If a test fails, the failure is logged and fed back with the code so the model can fix the cause.
- Wrapping: the finished code is packaged with examples showing how to turn a plain question into a call to the function.
The maker can also produce several candidate versions and keep the best performer. Finished tools go into a tool cache (a shared library). A dispatcher checks whether a matching tool exists. If not, it asks the maker to build one, or queues the request for a human developer.
At use time, the small model reads a tool index (a list of available tools), writes the call, and a toolkit interface runs the code in a sandbox and hands the result back. The examples include sorting words alphabetically, scheduling a meeting between two calendars, and solving a book-shelf ordering puzzle.
Why smaller AI models stand to gain here
The practical payoff is cheaper, faster AI answers. The filing says a large model only needs to run a few times to make a tool, while many small models can then reuse it. Small models can run on devices like smartphones and tablets, and the filing says that keeps more of your data on the device and cuts trips to cloud servers.
It also targets a real weakness: AI models guess probabilistically, so even simple, rote tasks can come out wrong now and then. Handing those tasks to ordinary code gives the same answer every time. The filing also describes a shared tool library that several contributing systems could fill, which would let one tool serve many AI models.
Google's 29th filing we've tracked since May on AI models working together builds on one that looks up facts alone and one that grades each search.
Chatbots spend a lot of computing power on chores a plain program does instantly and perfectly. Sorting a list or untangling a seating puzzle word by word costs money every time, and every answer carries a small chance of a slip. That cost is real and everyday, and the filing's answer fits its size: pay the big model once, then reuse the result.
The weak spot is trust. In the claims, the same large model that writes the code can also write the tests that check it, so a flawed tool could pass flawed tests. The filing does describe sampling several versions and updating tools based on feedback from use, which helps.
When this works, you will never notice it. The savings simply show up as quicker, cheaper answers, and how often the checks catch a bad tool decides whether the idea holds up.
Get our take in your Top Stories
Liked this breakdown? Add Patentlyze as a preferred source on Google, and our plain-English take shows up more often in your Top Stories the next time Google patent news breaks.
There are more where this came from
We read every patent application Big Tech publishes and send you the ones worth knowing. Plain English, free, every week.
The drawings
16 drawing sheets from US 2026/0310426 A1 · click any drawing to enlarge
Want this weekly breakdown for a company we don't cover? Patentlyze Pro →
Be the first to weigh in