API strategy
Platform integration
API products were built for human developers, not agents. Why having an API isn't enough — and what an agent-ready product actually looks like in 2026.
Most SaaS companies think they already have an API product. They have endpoints, they have docs, they have a developer portal. So when the agent project lands on the roadmap, the assumption is reasonable: the API is there, agents can use it. Then the agents ship, and they can do a small fraction of what the UI can do. The API product was built for human developers integrating other systems. It was never built for agents acting on behalf of users.
When people search for api products, they usually mean one of two things. Either products that ship with an API attached, or all products with api call surfaces a developer can reach. Both definitions are too generous.
Most SaaS APIs were built for a specific job: let a partner sync records, let an admin script a bulk update, let a customer's data team pipe events into a warehouse. The surface that got exposed was the surface those jobs needed. Everything else stayed in the UI, where it had been built first and where it kept getting richer release after release.
That's fine when the consumer is a human developer with a narrow integration goal. It breaks the moment the consumer is an agent trying to do what a user can do.
There's a category of integration software — embedded iPaaS, traditional middleware, partner connectors — built around the API surface as it exists. That software that integrates one system with another is good at its job. It's also the wrong shape for agents.
Three differences matter.
First, coverage. Integration software needs the few endpoints the integration calls for. An agent needs whatever the user might reasonably ask for next, which is a much larger and less predictable set.
Second, identity. Traditional middleware and partner-connector integrations typically authenticate as a service account or a shared partner key. Modern embedded iPaaS platforms do support per-user OAuth, but that identity is configured per integration at setup time — not discovered and bound at runtime. Agents have to act as the authenticated user on every call — their permissions, their data visibility, their audit trail — without a human in the loop wiring up the connection first.
Third, discovery. Integration software is configured by a human who read the docs once. Agents have to find the right tool at runtime, from a description, without help.
None of this is a flaw in existing integration software. It's a category mismatch.
The obvious response, once a team sees the gap, is to rebuild the API surface. Expose everything. Make the API a true mirror of the product.
We've watched several teams start down this path. It takes two to five years, it competes with every other roadmap item, and at the end of it the product has moved on — the UI has another two years of features the new API still doesn't reach. The gap doesn't close. It just moves.
The second response is bespoke connectors per product. Hand-write tool definitions for each agent use case. This is faster, but it doesn't compound. Every product change breaks something. Every new product starts the work from zero. At portfolio scale, the maintenance cost overtakes the build cost within a year.
Neither approach is wrong in isolation. Both are unfundable at the scale most multi-product SaaS companies operate at.
We think the useful frame isn't "do you have an API product" — it's "can an agent reach what your UI can do, as the authenticated user, reliably enough to ship." Four things have to be true:
The gap between those columns is the work. It isn't a documentation problem and it isn't a model problem. It's a structural one: the product was built UI-first, the API kept up with some of it, and now the agent has to reach the rest.
We built Pontil for exactly this gap. Tools-as-a-Service generates the tools agents need from the codebases that already exist — no API rewrite, no per-product connector backlog. The runtime executes each tool call as the authenticated user, so permissions and audit trails honour the real identity rather than a shared service account. Maintenance is automated and aligned to your SDLC, so when the product changes, the tools change with it.
We think of it as meeting products where they are. The API surface you have is the contract; we generate the agent-reachable layer on top of it and keep it current. If your team is sizing the rewrite-versus-bespoke question, the demo is the fastest way to see the third option in practice.
If you're a product or engineering leader looking at the agent roadmap, the question to put on the table isn't "do we have an API product." Almost everyone does, by some definition. The question is whether the API product you have matches the four columns above — and if it doesn't, which of the three responses (rewrite, bespoke, generation) actually fits the time and money you have.
The teams getting this right aren't the ones with the cleanest APIs. They're the ones who stopped treating the API as the finished product and started treating it as one surface among several the agent has to reach.
