the tool calling part of an agent is a way smaller problem than the models we usually point at it

every agent stack i've worked on sends tool calls through the same big model that does the reasoning, so you pay a full model and a round trip for what is often just "map this request onto one of 40 typed functions". i spent a few days seeing how far the opposite extreme goes: a 48M param model that only does tool calling. it reads your function schemas plus a request and emits the calls, or an empty list if nothing applies. it cannot chat at all. the trick that makes it work at that size is that the json never comes from the model. a grammar compiled from your schemas emits all the structure, and the model only answers five kinds of question: refuse or call, which tool, include this optional arg, what value, stop or continue. so malformed json and invented parameter names aren't low probability, they're unreachable. that part holds on any catalog with no training at all. accuracy is the honest tradeoff. on catalogs it trained on it beats the comparable small baseline by 20+ points on some suites (86.3 vs 63.7 strict exact match on one of them). on catalogs it has never seen it's roughly at parity with that baseline and well below a prompted frontier model. there's a script that specializes it to your own api for about $56 of synthetic data, and that's the actual intended use, one tiny model per catalog instead of one big model prompted with everything. whole thing cost about $260 to build and it's open source, mit license, weights included. links in the comments since the rules here say to keep them out of the post. curious if anyone else has tried the small-specialist route for the deterministic part of their agent, and where it broke for you.