Your AI Agent Is Stuck With the Tools Humans Bothered to Write. SMITH Lets a Tiny Model Forge Its Own — and Beat One 7x Its Size.

Every AI agent you have ever used is a language model plus a set of tools. The model does the thinking; the tools do the doing — calculators, search APIs, code runners, database queries. Strip away the tools and the smartest model becomes a very eloquent chatbot that can't touch anything.

Here's the problem nobody talks about: your agent can only use tools a human bothered to write. If the perfect tool for your task doesn't exist as an API, the agent is stuck improvising with whatever is on the shelf. Researchers have tried prompting models to write new tools at inference time — but that approach has a fatal split personality: the part that writes the tool is decoupled from the part that uses it, with no signal telling the writer whether its tool is one it could actually call.

A team at Appier Research and National Taiwan University (paper submitted August 25, 2026, since accepted at NeurIPS) just closed that loop. Their framework, SMITH — Schema-grounded Multi-task Iterative Tool Honing — trains a single model to both create tools and use them, in one reinforcement-learning loop. And the headline result is startling: a 4-billion-parameter Qwen3 trained with SMITH outperformed an untrained 30B tool-writing model — a model more than seven times its size.

What the researchers did

The core idea is disarmingly direct: train one policy to do both jobs. During training, every rollout is one of two task types:

1. Build tasks — write a tool from a few examples. The model is shown a handful of demonstrations and must produce working code plus a proper schema (name, parameters, types, description) for a reusable tool.
2. Use tasks — invoke a tool from the pooled tool library on a held-out question it has never seen. The model must read schemas, pick the right tool, and call it correctly.

Crucially, both tasks share one policy, so experience as a tool user feeds back into skill as a tool writer — and vice versa. The tools a model writes become precisely the tools it can reliably invoke, because it learned both sides of the interface from its own execution outcomes.

The second key idea is the reward design. When a tool-using attempt fails, the failure can sit in three places: the schema (bad parameter definitions), the code (runtime errors), or the outcome (right tool, wrong answer). SMITH gives each its own reward axis, so a broken schema doesn't pollute the learning signal meant for broken code.

The results: small beats big

The numbers are hard to argue with. A 4B Qwen3 trained with SMITH on 13 procedural reasoning tasks reached 79.8% macro-average accuracy on held-out tasks — the best across every method the team evaluated, and ahead of an untrained 30B-A3B tool-writer.

On generalization it got better: the same 4B model hit 40.4 on TabMWP-Hard and 42.6 on out-of-domain GQA — a +7.6 gain over the best same-backbone inference-time baseline — with zero visual or tabular training data. Its tools also transferred upward, lifting both a tiny LFM-2.5-350M student and the much larger Qwen3-30B-A3B, and the same recipe worked on Qwen3-8B and Granite-3.3-8B without modification.

In other words: coupling creation and use inside a single trained policy is a scalable path to generalization — no larger frozen teacher, no more complex scaffold, no out-of-domain supervision required.

Why it matters

For agent builders, this reframes the economics of tooling. Today, every new capability needs a human to design an API, document it, and wire it in. SMITH points to agents that extend their own toolbelts on demand — a scraper for the weird site, a parser for the proprietary format — each one already wieldable, because writing and wielding were learned together.

There's a cost story too. The tools are reusable and shareable across models and tasks — write once, invoke cheaply forever. A well-tooled 4B model beating a 30B model is a deployment budget argument: smaller model, smaller bill, same or better results.

How YOU can use it

You don't need Appier's RL cluster to steal the pattern. SMITH's design translates directly into a prompting and workflow discipline you can use today:

1. Run the build-then-use loop on every new tool

Never let your agent write a tool and walk away. Force the close of the loop with a two-step prompt:

STEP 1 — BUILD:
You are a tool creator. From these examples, write a reusable tool
(function + schema: name, parameters, types, description) for [task].

Examples:
[2-3 worked examples]

STEP 2 — USE:
Now forget you wrote it. Read ONLY the schema above, pick the tool,
and call it on this new input: [unseen input].
If the call fails, diagnose: is the schema wrong, the code wrong,
or the answer wrong? Fix that layer, then retry.

The "forget you wrote it" line matters: it decouples the user from the writer, exposing schema gaps the writer couldn't see.

2. Debug tool failures in three layers — schema, then code, then outcome

This is SMITH's three-axis reward turned into a checklist. When an agent's tool call fails, resist the urge to regenerate everything. Check in order:

1. Schema: Are the parameter names, types, and descriptions accurate? Can a stranger read the schema and know what to pass? Most tool failures are here.
2. Code: Does the function run on a trivial input without exceptions?
3. Outcome: Does it produce the right answer on a known case?

Fix the failing layer only, then re-run. You'll converge far faster than with blind regeneration.

3. Build a personal tool pool and make it reusable

Save every working tool with its schema into a shared library — a folder, a doc, whatever you use. When a new task arrives, have the agent read the pool first before writing anything new. SMITH's transfer result tells you something important: a good tool library is model-portable. Invest once; every future model benefits.

4. Enforce schema-first discipline

The "schema-grounded" half of SMITH is the secret sauce. Before your agent writes tool code, make it write the schema first — name, parameters, types, one-line description. If it can't state the interface cleanly, it doesn't understand the tool yet. This one habit eliminates a huge class of "the tool exists but nobody can call it" failures.

Key takeaways

• Agents are bounded by the APIs humans bothered to write — and inference-time tool creation leaves the writer decoupled from the user.
• SMITH jointly trains tool creation and tool use in a single RL policy, alternating build tasks (write a tool from examples) and use tasks (invoke pooled tools on unseen questions), with separate reward axes for schema, code, and outcome failures.
• A 4B Qwen3 trained with SMITH hit 79.8% on held-out tasks, beating an untrained 30B tool-writer, generalized out-of-domain (+7.6 on GQA), and its tools transferred to both smaller and larger models.
• Steal the patterns today: build-then-use loops, the schema→code→outcome debugging checklist, a reusable personal tool pool, and schema-first discipline before any tool code.

Read the original paper: "Joint Optimization of Tool Creation and Use for Large Language Model Agents" — Zhi Rui Tam, Chieh-Yen Lin, Yun-Nung Chen, Shao-Hua Sun, Hung-yi Lee (Appier Research / National Taiwan University) — arXiv:2608.24571 (submitted 25 Aug 2026; accepted at NeurIPS). https://arxiv.org/abs/2608.24571