Your APIs expose 2% of what your product can do

Your product can do a lot. Your API exposes a fraction of it.

This isn't a criticism — it's a description of how SaaS products are built. You spent years making the interface capable. Users can do things in your product today that weren't possible two years ago: complex workflows, custom logic, multi-step processes that span different parts of the platform. The API kept up with some of it. Not most of it.

For a long time, that gap didn't matter. Users worked through the UI. Partners used the API for the simpler integrations. The gap between the two was an engineering detail, not a commercial problem.

Now it matters. Because agents use the API, not the UI — and when the API only exposes 2% of what users can do, agents can do 2% of what users can do.

Where the gap comes from

The gap isn't the result of bad API design. It's the result of a sequencing problem that applies to almost every established SaaS product.

APIs were built for the integration use cases that existed when they were written: webhooks, point-to-point data sync, third-party developer access, basic CRUD. The UI was built for users — and user expectations evolve fast. Features get added to the UI because that's where the feedback loop is. The API gets updated when there's a specific integration requirement, which is less often and for a narrower scope.

The compounding effect over several years of product development is the gap. Workflows that live in the UI because they were too complex to expose through the API. Permission checks that were easier to enforce in the controller layer. Custom field logic that was added to a form without an API equivalent. None of these are architectural failures. They're the natural result of building product for the consumer who was there: the human user.

What 2% looks like in practice

The 2% figure is illustrative, not precise. The real number varies by product. But the pattern is consistent: when teams map their agent's required task list against their current API surface, the coverage is almost always much lower than they expected.

A product where users can build custom workflows through a drag-and-drop interface often has no API surface for those workflows. A product with a sophisticated permission model often has API endpoints that don't enforce those permissions the same way the UI does. A product where users fill in forms with conditional logic often has API endpoints that accept the fields but bypass the logic.

The agent inherits all of these gaps. A task that takes a user 30 seconds in the UI might be completely unreachable for an agent because the underlying API calls don't exist, don't chain correctly, or don't produce the same validated result.

Why this is a commercial problem now

Enterprise customers are starting to ask "can your product be acted on by an agent" as a real procurement question. It's not yet a standard line on an RFP, but the conversations are happening. Sales cycles are starting to include questions about API coverage, about whether the product integrates with the buyer's agent infrastructure, about whether their agents can do what their users can do.

SaaS companies that can say yes have an advantage. Companies that have to explain that their API covers some use cases but not others — that some workflows are UI-only — are having a harder conversation.

The gap that was an engineering detail is becoming a commercial liability.

Why the obvious fix is slow

The obvious fix is to close the gap: build the API endpoints, expose the workflows, make the full product surface callable. This is the right architectural answer.

It's also a multi-year project. Every workflow that needs an API equivalent is engineering work. Every permission check that needs to be expressed in an API contract is a refactoring effort. Every form with conditional logic that needs a backend expression is a sprint. Across a product with years of accumulated UI-first development, the gap is large enough that a full API rebuild competes with the product roadmap for engineering capacity and wins only if leadership decides it's more important than the features that are supposed to drive growth.

Most leadership teams don't make that decision, for rational reasons. The result is that the gap stays open, the commercial pressure grows, and the agent project stalls.

Starting without a full rebuild

The alternative to a full API rebuild is to close the gap selectively and pragmatically, starting with the task list the agent project actually needs.

Not every capability needs an API equivalent. The agent needs to do specific business tasks. Those tasks require specific capabilities. Mapping the required capabilities to the current API surface gives you a prioritised list — not "rebuild the entire API" but "expose these fifteen capabilities that block the first five agent tasks."

This is a tractable project. It's not the architectural ideal, but it's the path that ships in months rather than years, and it's the path that delivers real agent capability to users rather than waiting for the full surface to be ready.

The 2% to 100% problem doesn't get solved all at once. It gets solved by knowing which 2% you're at and which capabilities close the gap for the use cases that matter most.