Naming a service

You should not have to become an integration engineer to teach the system about a service you already use. An early version of this could take a technical specification if you supplied one — useful, but the easy half of the job. The half that mattered was more natural: name the service in plain language, and let the system work out how to talk to it, preferring certainty over guesswork at every step it can.

Fig. 8.1 — A discovery order that spends judgement only once certainty runs out.

Once a service is understood, the capability it offers is indistinguishable from any other — built in, described by you, or connected from elsewhere. Where a capability came from stops being something to think about. One distinction survives that flattening, and it is the one that matters: a capability is a request, never a grant, and it is checked against what actually exists and what the current run is allowed to do, every single time it is used — not once, at the moment it was set up.

One tool plane, many origins

A built-in capability, a connected server, a skill a person described in a sentence, and an API named and discovered on the spot — four different origins, and by design, one indistinguishable shape once each has been understood.

Fig. 8.2 — Provenance stops mattering once a capability is understood.

This flattening is what makes the rest of the system uniform. The planner that decides what to try next, the ranker that shortlists candidates, the permission guard, and the ledger that records what ran — none of them need a special case for “capability that happened to arrive by API discovery” versus one written by hand. A new kind of source can be added later without teaching every downstream component about it individually.

Real services are also part of what tests the design honestly. A capability that only ever runs against a tidy stand-in can look finished while quietly depending on assumptions a real, occasionally inconsistent service will not meet — which is why the discovery ladder and the permission checks around it are exercised against services actually in use, not only against fixtures built to be agreeable.

Turning any public API into a tool

Naming a service in plain language and letting the system work out how to talk to it has a natural extension: once a public API is understood, it can be repackaged, on the fly, as a proper tool server that speaks the same open protocol the rest of the agentic tooling already understands — so the newly wrapped API sits on exactly the same footing as anything built in from the start.

Fig. 8.3 — A public API becomes a tool server on the same open protocol as everything else — not a one-off, bespoke integration.

The distinction from simply naming a service is what happens after the API is understood. Rather than the system holding a private, ad-hoc note to itself about how to call that one API, it produces a small server that any tool-using client speaking the same open protocol could talk to. The wrapping step turns a one-off integration into something reusable and portable, instead of a fact known only inside a single conversation.

Every safeguard already described in this book still applies at full strength here. A newly wrapped API is a request, not a grant — it is checked against permission before every use, its calls land in the same usage ledger as anything else, and anything it would change outside the system still waits for an explicit yes. Turning a public API into a tool makes it reachable. It does not make it trusted by default.

Plugging into tool servers you did not build

Wrapping a public API is one direction: turning something that was never a tool into one. The other direction is just as useful — connecting to a tool server that already exists, built and run by someone else, speaking that same open protocol from day one.

A growing number of products and teams now publish exactly this kind of server: a running service that exposes a defined set of capabilities over the open tool protocol, ready for any compatible client to connect to. Rather than treating each of those as a bespoke integration to be built from scratch, the system can register a remote server directly and make everything it offers available to the agentic loop as ordinary capabilities.

Fig. 8.4 — Someone else’s server, discovered directly and folded into the same rules that govern everything else.

Taken together, wrapping and connecting close a loop worth naming plainly: wrapping turns something into a tool server; connecting reaches a tool server someone else already runs. Between the two, almost anything reachable on the open internet — a service with no server yet, or a server already running — can end up on the same capability plane, described identically, governed identically.

This is also where trust becomes an explicit, ongoing decision rather than a one-time act of faith. A remote server run by someone else is code and infrastructure a person did not write and cannot fully inspect, so registering one is treated with the same seriousness as approving a large, irreversible change to owned material: proposed, reviewed, and only then relied on — and every call it makes remains bound by the same read-versus-act distinction, the same budgets, and the same ledger as every other capability in the system.

Breadth is only valuable if it does not quietly rewrite the rules the rest of the system lives by.