One Contract, Not a Catalog
A department store with twelve counters — each with its own register, its own return policy, its own bag-check rules — is still twelve counters. Here's why a single API is different from a gateway in front of twelve of them.
The dominant pattern for government AI right now is a catalog of small services — one for chat, one for search, one for vision, one for speech — with a routing layer bolted on top. The integrator sells you the routing layer. You buy the integration.
It is a reasonable assembly. It is not a platform.
What the difference actually is
An API contract is a single written agreement. One document describes what the backend does. One address to call. One login. One audit trail. One policy. One way errors come back.
A catalog is a collection of separate agreements that happen to share an address. Twelve services, twelve shapes, twelve sets of rules, a gateway in front stitching them together so it looks like one thing.
The difference is invisible on day one. It shows up on day three.
Imagine the contract developer and the catalog developer both starting a new app:
- The developer working against a contract asks one question: “Does the specification cover what I’m trying to do?”
- The developer working against a catalog asks five: “Which service? Which version? What’s its specification? Is the login the same as the gateway’s? Where do I log the audit record — the service’s format, the gateway’s, or both?”
By week two, the catalog developer has stopped trusting the documentation and started reading source code.
What an AI coding assistant sees
The procurement world hasn’t caught up to how developers actually build now. Mission developers open Cursor, Claude Code, or Windsurf, drop an API specification into the conversation, and the assistant generates a working client from it. The AI coding assistant is a first-class consumer of the API.
A single, cohesive specification gets that developer — and their assistant — to a working prototype in an afternoon.
A catalog slows the same work down by a factor of three to ten, because the assistant has to be told:
- Which service answers which question
- Which specification URL goes with which service
- Which shared types are subtly different between services
- Which gateway header maps to which service’s permissions
- How to combine streaming responses across calls
Every one of those is a decision a human has to make and feed in. The afternoon becomes a fortnight.
The standards world is also moving this direction. The OpenAPI community’s next-generation effort — Moonwalk SIG — is formalizing the cohesive-specification pattern in 2027. When that standard is done, every vendor will claim they meet it. The point is to ship it before the standard made it table stakes.
Why vendors build the catalog anyway
We looked hard at the catalog approach. The honest pitch for it is real for the vendor: each capability evolves on its own cadence, on its own hardware, owned by its own team. Loose coupling is a sensible engineering choice.
It is not sensible for the customer, because the customer wants the opposite. What the customer actually wants is cohesion: one login that works across every capability, one audit record that traces a workflow from start to finish, one set of rate limits, one error model, one policy engine.
Cohesion is hard to fake at the integration layer. Either every service duplicates the policy (which drifts — by month six, two of them will be wrong) or a gateway in front enforces the policy (which becomes the real API the customer is targeting — making the catalog an implementation detail).
At that point, the vendor is running a platform with a catalog inside it. They might as well ship the platform.
The trade-off
Picking one contract over a catalog has a cost.
We lose some speed in the generative AI world. The upstream teams who build individual services — vLLM is the big one — ship new versions faster than we can wrap, test, and re-expose them through our contract. There is an ongoing tax to keep up. It’s real. It’s bounded.
In exchange, a developer can drop one specification into an AI coding assistant and have it generate a working application. Not a skeleton. A working application. That’s the whole point of having a contract.
If you’re writing a procurement document
Language that would foreclose the catalog pattern in a federal AI-backend solicitation:
“Offeror shall expose all AI capabilities covered by this award through a single OpenAPI 3.1 specification with a unified authentication model, a unified audit schema, a unified rate-limit policy, and a unified error model. A federated catalog of independent microservice specifications behind a routing layer does not satisfy this requirement.”
That one paragraph filters out the catalog-plus-gateway crowd before the technical evaluation even starts. A vendor who can’t answer it cohesively is telling you what they really are.