There is a recurring scene in agent research that anyone who has shipped a system will recognise. A team builds a frontier model, evaluates it on a clean benchmark, declares victory, and then discovers, the moment the model is given real tools to work with, that performance falls off a cliff.

The reasons are not mysterious. Real tools have ambiguous documentation, brittle error messages, undocumented rate limits, and side effects that other tools cannot see. A model that reasons beautifully about a sandboxed Python interpreter will, presented with a real production API, behave like a tourist who has lost the phrasebook.

What has emerged in the last year is a small but increasingly serious sub-discipline devoted entirely to the design of tools for agents to use. Its practitioners care about things that traditional API designers rarely think about: idempotency by default, explicit affordance vocabulary, error messages written for a reader who is reading them once and acting on them immediately.

The early results are striking. Identical models, given access to the same underlying systems through agent-friendly tool layers rather than human-friendly ones, post double-digit gains on long-horizon benchmarks. No retraining required. The model became smarter because the world became more legible to it.

There is a tempting conclusion here, which is that intelligence is partly a property of the environment. Whether or not one accepts that framing, the practical implication is hard to escape. The next generation of capable agents will not be built only by training labs. They will be built, at least as much, by whoever decides what an agent is allowed to touch, and how.

On the Surprising Importance of the Tool Call