← Back to Payloads
Opinion2026-06-25

Function Calling Is A Footgun. Tool-Use Is The Next Memory Layer Disaster Waiting To Blow Up Production.

Every agent framework in 2026 is built on function calling. Anthropic, OpenAI, Google, LangChain, CrewAI, AutoGen — they all push tool-use as the foundation of the agent stack. It is a footgun, and the industry is building the next wave of brittle agents on top of it the same way it built 2024 on top of vector databases. The agent framework industry raised billions on the premise that more tools equals more capable agents. The data says the opposite.
Quick Access
Install command
$ mrt install opinion
Browse related skills
Function Calling Is A Footgun. Tool-Use Is The Next Memory Layer Disaster Waiting To Blow Up Production.

Function Calling Is A Footgun. Tool-Use Is The Next Memory Layer Disaster Waiting To Blow Up Production.

Six months ago I called the agent memory industry a category error with a Series A. Nobody changed what they were building. Now I'm saying the same thing about function calling.

Function calling is the dominant pattern for giving agents capabilities. Anthropic's tool use. OpenAI's function calling. Google's function declarations. Every agent framework — LangChain, LlamaIndex, CrewAI, AutoGen — builds on top of it. It is the foundation of the agent stack.

It is also a footgun. And the industry is building 2026's agent ecosystem on top of it the same way it built 2024's on top of vector databases.

Three Failure Modes Nobody Wants To Measure

1. Tool list explosion. Production agents routinely ship with 30, 50, 80+ tools. The model's attention budget for tool selection is the context window. Past ten tools, accuracy drops measurably. Past twenty, it collapses. Every tool you add costs you reliability on every other.

2. Argument hallucination. The model invents parameters that don't exist, fills optional fields with garbage, and converts types in ways the schema doesn't allow. With long tool lists, the model picks up patterns from one schema and applies them to another. A send_email tool gets a priority field because the model saw it on a Slack tool three descriptions up.

3. Tool misuse. The model picks the right tool for the wrong reason. Calls delete_user instead of get_user because the user said "remove". The intent-matching is probabilistic, the failure is silent, and you don't see it until production.

The Vendor Trap

The reason every agent ships with too many tools is the same reason every agent used to ship with a memory layer: selling "one agent for everything" is easier than selling "five narrow agents that do specific things well."

Customers want one agent. Vendors deliver one. Tools pile up. The agent degrades. Vendors blame the prompt. Customers buy a better template. Nobody fixes the architecture.

This is the memory layer pattern again. Memory was sold as the fix for agents that forgot things. It didn't work because the underlying problem was bad prompt and tool design. Adding memory moved the failure mode around. It did not address it.

What Actually Works

If you want an agent that does not hallucinate tool calls, do five things:

1. Keep the tool list under seven. If you cannot describe your domain in seven tools, you do not have an agent problem. You have an architecture problem. Split into multiple narrow agents.

2. Schema-first with strict validation. JSON Schema, required fields marked required, enums where you have them. Reject any call that fails validation. Make the model fail loudly when the schema is wrong.

3. Validate intent, not just the schema. A second LLM call asking "did the agent pick the right tool?" catches misuse cheaply.

4. Constrain the model. Don't pass free-form text into tools. Parse intent into a typed structure first.

5. Log every tool call with rationale. "Model called delete_user because..." If you cannot reconstruct why, you cannot debug it.

The Take

Function calling is the API economy for agents. Every tool is a vendor integration, every vendor integration is a contract. The pattern looks like progress and it is mostly debt.

The agent framework industry raised billions on the premise that more tools equals more capable agents. The data says the opposite: more tools equals less reliable agents. The model is not the bottleneck. The tool design is.

The next eighteen months are going to look exactly like the last eighteen months of memory: a wave of "tool registry" and "tool governance" startups selling infrastructure for a problem that only exists because the underlying system is broken. They will raise money. They will fail. Customers will be left with brittle agents and a bill.

If you are building an agent, stop adding tools. Cut the list in half. Cut it again. Strict schemas, intent validation, full logs.

The agent industry is about to learn the same lesson memory learned: the tool is not the product. The architecture is.

Related Dispatches