API as a product strategy is not enough for the agent era

API as a product strategy got SaaS this far. It will not get SaaS through the next five years.

The doctrine is familiar. Treat your API like a product. Give it a roadmap, a product manager, a developer portal, versioning, SLAs, a feedback loop. Build for the developer as customer. It is good advice and it built a generation of platform businesses. But the doctrine was written for a world where the consumer of your API was a human developer integrating it into another product. That world is shrinking. The new consumer is an agent acting on behalf of a user, in real time, against the surface of your own product. And API-as-a-product, as currently practised, does not serve that consumer.

We think the framing needs to change. Not abandoned — extended. Here is what we mean.

The original doctrine solved a real problem

API productisation in SaaS emerged because internal APIs were being treated as plumbing. Documentation rotted. Endpoints drifted. Versioning was ad hoc. External developers — partners, customers integrating you into their stack, ecosystem builders — could not depend on the contract. So companies appointed API product managers, published portals, ran developer relations, and held the API to the same standard as the rest of the product.

That worked. The teams who took it seriously built platform businesses on top: Stripe, Twilio, Shopify. The teams who didn't ended up with APIs that exposed a small, brittle slice of what their product could actually do.

Which is most of the industry. Industry surveys consistently show most organisations struggle with API documentation — Postman's State of the API research, for instance, has reported that more than half of developers cite inconsistent documentation as a significant problem — and most established SaaS products were built UI-first with the API bolted on later. The result is what we've called the 2% problem: the public API surface exposes a fraction of what the product can actually do. Everything else lives in UI flows, internal services, and code that was never meant to be called from outside.

API-as-a-product, even when done well, was a strategy for serving human developers. It assumed the consumer could read docs, write integration code, handle quirks, and ship a project on a quarterly timeline. None of that describes an agent.

What changes when the consumer is an agent

An agent is not a developer. It does not read your portal. It does not file tickets when something breaks. It does not adapt to inconsistent naming or missing fields. It calls a tool, gets a result or an error, and either continues, retries, or stalls.

Four things change when the consumer shifts from developer to agent.

Coverage stops being optional. A human developer who hits a missing endpoint files a feature request and ships around it. An agent that hits a missing endpoint cannot complete the task. If your API covers 2% of the product, your agent reaches 2% of the product. There is no workaround. We've written more on this in API products are not the same as agent-ready products — the gap is the whole problem.

Semantics matter more than syntax. A developer can tell that update_record and patch_entity are the same operation in different parts of your platform. An agent picking from a list of tools needs each tool to be named, described, and scoped consistently — or it picks wrong. Naming drift across product lines, harmless for human integrators, becomes a tax on every agent invocation.

Auth has to be per-user, not per-app. Most API product strategies treat auth as an app-level concern: issue a key, scope it to a tenant, you're done. Agents act on behalf of individual users with individual permissions. A tool call must execute as the authenticated user, see what they see, write what they can write, and leave an audit trail that ties back to them. App-level keys break this. We go into the auth shift in more detail in SaaS integration in the agent era.

Maintenance compounds differently. A developer integration breaks loudly — a deploy fails, a customer complains. An agent integration drifts quietly — the agent picks a slightly wrong tool, fills a field with a slightly wrong value, and the user only notices a week later when the report is off. Silent drift is the failure mode you don't see until it has cost you something.

None of this is solved by writing better docs or hiring another API product manager. The shape of the consumer is different, so the shape of the product surface has to be different.

What API product management gets wrong about agents

The common reaction inside SaaS companies is: we already have an API product strategy, agents are just another consumer, we'll add an "agents" persona to the roadmap. This is the wrong move, for three reasons.

First, it assumes the gap is one of polish, not coverage. Most API product roadmaps focus on developer experience — better SDKs, cleaner docs, faster onboarding. Agent-readiness is not a polish problem. It's a coverage problem. The capabilities are missing from the API entirely, not poorly documented.

Second, it underestimates the maintenance load. A product surface designed for agents has to stay current as the product changes. Every UI release that adds a field, renames an action, or changes a permission boundary has to flow through to the agent's view of the world. That cadence does not fit a quarterly API roadmap.

Third, it conflates two consumers with conflicting interests. Human developers prefer stable, slow-moving APIs with long deprecation windows. Agents prefer up-to-date, high-coverage tool surfaces that track the product. Trying to serve both from a single API product team usually means one gets neglected — historically, the agent side, because it doesn't have a champion in the room yet.

The industry response to this — "productise the API harder" — papers over the structural mismatch. The API was built UI-first, the agent needs the UI's coverage, and no amount of product management makes a 2% surface into a 100% surface.

What an agent-aware product strategy looks like

Here is the framing we'd offer instead. API-as-a-product remains the right discipline for the developer surface. Don't dismantle it. But the agent surface needs its own treatment.

A few things define that treatment:

• Coverage is measured against the UI, not against the API. If your product does it, an agent should be able to reach it. The gap between those two numbers is the size of your real problem.
• The surface is generated from the product, not hand-built. Maintaining a separate tool layer by hand, product by product, replicates the bespoke connector problem at portfolio scale. We've written about the maths of that — it doesn't compound.
• Auth and execution honour the user. Tool calls run as the authenticated user, with their permissions and their audit trail. Not as a shared service account.
• Maintenance is part of the SDLC. When the product changes, the agent surface changes with it, automatically, with the same tests and observability that gate the rest of your releases.
• The tool layer is a distinct product surface, owned by someone. Not a side project of the API team. Not an internal hack. A surface with a roadmap and a maintainer, the same way leading SaaS companies productised their APIs a decade ago.

This is what we mean by Tools-as-a-Service as a category — the surface that sits between the agent and the product, generated from the systems you already own, maintained as the product evolves. Some companies will build it themselves. Most won't, because the maths of building it product by product across a portfolio doesn't work. Either way, the strategic point stands: the agent surface is its own product, and treating it as an extension of the API product roadmap will leave you with the same 2% gap you started with.

What follows

If your company already has an API product strategy, you're ahead of the companies that don't. The instinct to treat the developer surface as a real product is the right one. The work now is to extend that instinct — not to a new persona on the same roadmap, but to a separate surface with its own coverage target, its own maintenance model, and its own ownership.

The companies that do this in the next 18 months will have agents that can reach the whole of their product. The ones that keep stretching API-as-a-product to cover the agent case will end up with agents that can reach 2% of their product and a roadmap full of features the agent can't use. The shape of the consumer changed. The shape of the strategy has to change with it.