Two years ago, connecting a model to an internal system meant writing an adapter. Every integration had its own: a schema written by hand, an auth path invented for the occasion, a serialization format that matched nothing else, and error handling that existed only where someone had been bitten. The adapters worked, and they rotted, and each one was a small private dialect that only its author could maintain.
That layer is now a protocol with a standards body behind it and broad implementation across vendors and enterprises. Tool access has stopped being something each team invents.
This is a genuine simplification, and it has been mistaken for a larger one. The work did not disappear. It moved — from writing the connection to governing it.
What standardization actually removed
Three costs, all real:
The dialect problem. A tool description now means the same thing to different clients. Capability discovery, argument schemas, error shapes — the things every team was inventing separately — are now interoperable. The adapter is no longer the artefact; the tool is.
The rewrite tax. Changing which model or client sits in front of a set of tools used to mean redoing the integration layer. That coupling is mostly gone, and it is worth more than it sounds: substitutability at the model layer is a resilience property, and it was previously expensive enough that teams simply did without it.
The maintenance floor. Standard transports and standard error semantics mean the boring parts stay fixed without anyone owning them personally.
What it handed back
Once connecting is easy, the difficulty relocates to authority. The questions that now take the engineering time are not about wire formats:
Which systems may an agent touch, in which state? A tool surface is not a capability list, it is an attack surface and a blast radius. The instinct to expose everything because exposing is now cheap is the same instinct that made people put everything in the context window when windows got long, and it fails the same way.
Under whose authority does a call execute? This is the question standardization made unavoidable. An agent acting with a service account’s permissions is not acting as the user who prompted it, and the difference shows up the first time an agent reads something the requesting user was never allowed to see. Identity has to propagate through the call chain, not stop at its entrance.
What does the write path require? Read access and write access are different products. We gate writes on explicit confirmation of intent, keep them idempotent so a retried step cannot double-apply, and make every write reversible or bounded. An agent that retries after an ambiguous timeout is normal; a write path that cannot survive that is a defect.
What did it actually do? Tool call and result belong in an audit trail with the identity that authorized them, retained on the same terms as any other privileged system access. When something goes wrong the question is never “what did the model say” — it is “what did it touch, with whose rights, and what came back.”
What does an untrusted tool response mean? A tool result is data, not instruction. Content fetched through a tool can contain text that looks like direction, and a system that cannot maintain that boundary has handed control of the agent to whoever can write into the systems it reads. This is now the most consequential thing on the list, and it is not something a protocol can solve for you.
How we build against it
- Tool surfaces are scoped per task, not per system. The default is nothing exposed; each tool is admitted for a reason someone wrote down.
- Read and write paths are separated, with different approval, different logging, and different eval treatment.
- The user’s identity propagates to the call. Service-account convenience is available for background paths only, and those paths cannot serve user-facing answers.
- Tool responses are treated as untrusted input at every step, including when they come from systems we own.
- Every tool has a defined behaviour on failure, and that behaviour is exercised in the eval suite rather than discovered in an incident.
The pattern underneath
Standardization at a layer does not remove the work at that layer. It relocates it upward, to the questions the standard deliberately leaves open — which are usually the questions about authority and consequence.
The glue is gone, and that is real progress. What is left is the part that was always the actual engineering: deciding what a system is allowed to do, and being able to prove afterwards what it did.