Tools Need Contracts, Not Charisma

The easiest way to make an agent look more capable is to give it more tools. The easiest way to make it less reliable is to do the same thing carelessly.

tool_call = {
  "name": "query_warehouse",
  "input_schema": {...},
  "timeout_ms": 5000,
  "retryable": true
}

That is the shape I trust. A tool as a contract. Named. Typed. Time-bounded. Explicit about whether failure should trigger a retry or a handoff. What I do not trust is the soft, dreamy version of tool use where the product acts as if the model is simply having a wider conversation with the universe.

We are now deep enough into the tool-calling era that the distinction matters. A model plus tools is not just a smarter assistant. It is a distributed system with a language model in the middle. Once you accept that, the design priorities become a lot less theatrical. What matters is not how fluent the call looks in the transcript. What matters is whether the tool boundary is stable enough that another engineer could reason about it at three in the morning.

Why contracts win

Contracts create useful friction. They force the builder to decide what the tool expects, what it returns, how long it may run, and what error surfaces need to be exposed. They stop the model from smearing ambiguity across the seam between systems. If a document parser must return a structured object, then the next step can validate it. If a browser extractor must return a boolean and a numeric price, then the pipeline can reject sentimental prose about the product looking 'probably available'.

This is why I think tool ecosystems will mature in the same way APIs did. First comes enthusiasm. Then wrappers. Then pain. Then finally a more boring generation of infrastructure where everyone admits that schemas, auth, rate limits, and observability were the real product all along.

The danger of charisma

Charisma is what lets a model hide weak integration design behind a convincing answer. The user sees a polished explanation and assumes the system is grounded. Meanwhile the tool call may have partially failed, returned stale data, or silently dropped a field the downstream action needed. The model sounds confident, so the product feels coherent right up until something expensive happens.

I think many agent failures are basically contract failures wearing a language-model mask. The system was too forgiving about the boundary between free-form reasoning and structured action. The cure is not to ask the model to be more careful in some abstract sense. The cure is to make the boundary stricter.

This is one of those places where software engineering quietly defeats product mythology. A good tool integration is not impressive because the model sounds clever while using it. It is impressive because the tool call leaves behind a record that can be validated, replayed, and audited. That is what makes the capability transferable beyond a single demo run.

Tools need contracts, not charisma. The more quickly the industry internalises that, the sooner agent products stop feeling like improvisation and start feeling like software.