Platform integration
Agent infrastructure
SaaS integration is splitting into two problems: system-to-system and agent-to-product. Here's why the old playbook breaks and how to evaluate the new tooling.
"SaaS integration" used to mean one thing: getting two systems to exchange data through their APIs. A CRM talks to a marketing tool. A billing system updates a data warehouse. The contracts are stable, the volumes are predictable, and the integration team owns a map of which webhook fires when.
That definition is now too small. The same SaaS products being integrated are also building agents on themselves — and those agents need to reach functionality the public API never exposed. Pontil's view: SaaS integration is splitting into two problems, and most teams are still solving only the old one. This piece covers what changed, why traditional integration platforms don't close the gap, how to evaluate the tooling that's appearing in the space, and where buyers should actually invest first.
For most of the last fifteen years, SaaS integration was a system-to-system problem. A company bought Salesforce, HubSpot, Workday, and a data warehouse. Something had to move records between them. That something was either a point-to-point script, an embedded iPaaS like Workato or Boomi, or — for enterprise scale — a MuleSoft deployment fronting an integration layer.
The assumptions baked into that world are worth naming. Integrations are between systems, not between a system and a reasoning agent. Triggers are events: a record changes, a webhook fires, a scheduled job runs. The catalogue of operations needed is small — sync contact, create invoice, update opportunity — and stable. And the consumer of the integration is another piece of software with a fixed set of needs.
None of those assumptions hold for agent access. An agent isn't reacting to a webhook on a known schema. It's deciding, mid-task, that it needs to read a customer's renewal history, update a deal stage, and pull the last three support tickets — and it needs the capability to do all of that to exist as discoverable tools before the conversation starts. The catalogue isn't small. It's everything the product can do. And the consumer isn't another system with stable requirements. It's a model whose requests are shaped by whatever the user asked.
This is the structural change. Old SaaS integration moved data between systems on known triggers. Agent-era SaaS integration has to expose product capability to a reasoning layer on demand. The first is mostly solved. The second is where every established SaaS company we speak to is stalling.
It helps to separate the two problems explicitly, because the tooling, the buyers, and the failure modes are all different.
The two layers aren't substitutes for each other. A team still needs system-to-system integration for the data-movement problems it always had. What's new is that the agent-to-product layer has its own requirements, its own buyers, and — increasingly — its own category of tooling. Treating the new problem as a variation of the old one is what gets agent projects stalled. Vendors who repackage iPaaS as "AI integration" are betting nobody notices the difference. Buyers should notice.
Integration software as a service — the iPaaS category — is mature, well-understood, and good at what it does. It is not a sufficient answer for the agent-access problem, and it's worth being specific about why. There are three structural reasons.
It's built around connectors to third-party systems, not capability surfaces of your own product. An embedded iPaaS like Prismatic or Tray Embedded helps a SaaS company connect into its customers' other tools. That's a real and valuable problem, and it's distinct from the problem of exposing your own product's full capability to an agent your own team is building. The direction of the arrow is reversed, and the catalogue scale is different by an order of magnitude. It's worth noting that some embedded-iPaaS vendors — Paragon, for instance, with its ActionKit product — are now extending into the agent-tool layer. That's a reasonable response to where the market is going, and it sharpens rather than blunts the point: the agent-tool problem is its own category, with its own requirements around codebase-derived tools, per-user auth, and CI-driven catalogue maintenance, even when adjacent vendors extend toward it.
The operation catalogue is fundamentally bounded. iPaaS platforms ship with a curated set of pre-built operations per connector — usually the canonical CRUD plus a handful of common workflows. That's appropriate for the integrations they were designed for. It's a hard ceiling for agents, which need access to whatever the product can do, not a tasteful subset.
The auth model is wrong for agent execution. iPaaS integrations typically authenticate per-tenant or per-connection — a customer-scoped OAuth token or a service account — rather than executing each call as the specific end user who triggered the agent. Most major iPaaS platforms support OAuth user-delegated flows, and per-customer OAuth connections are in fact the default in embedded iPaaS. But agent tool calls need to execute as the authenticated end user on every call, so that permissions, data visibility, and audit trails honour the real identity. Retrofitting per-user, per-call identity onto a per-tenant runtime is not a small change. It's a different runtime.
None of this makes iPaaS bad. It makes iPaaS the wrong layer for agent access. The teams getting stuck are the ones who assumed their existing integration platform investment would extend.
If the consumer of the integration is now a reasoning agent rather than another system, the evaluation criteria shift. We've written separately about how agent-readiness is becoming a commercial differentiator; the buyer-side version is figuring out what to look for in the tooling that gets you there. Five questions matter more than the others.
1. Does it generate tools from your existing codebase, or does it assume a clean OpenAPI spec? If your APIs cover only a fraction of what your product can do — and for most established SaaS products, they cover around 2% — a tool generator that needs a spec to start is only ever going to expose that 2%. The interesting tooling reads from where the capability lives: services, controllers, internal handlers.
2. Does it run tools as the authenticated user, or as a service account? Ask to see the auth flow. If the answer involves a shared token, the integration will leak data across user boundaries the moment an agent uses it in production. This is not a theoretical concern.
3. How does it handle product change? SaaS products ship constantly. If a tool catalogue is generated once and then maintained by hand, it goes stale within a sprint. The platforms worth looking at integrate with your CI and re-scan on every meaningful change.
4. Is the tool layer protocol-agnostic, or does it lock you to a single client? MCP is real and useful, but it isn't the only protocol your agents will ever speak. A tool layer that only emits MCP, or only works with one foundation model provider's tool-calling format, is buying you a short window of convenience and a long window of lock-in. We covered the protocol nuance in what is MCP in AI.
5. What does observability look like at the tool-call level? When an agent gets the wrong answer, you need to know which tool it called, what arguments it passed, what the underlying system returned, and which user the call ran as. "We log to stdout" is not an answer. Production-grade tool runtimes treat observability as a first-class surface.
These five questions don't favour any one vendor. They favour any tooling that took the agent-access problem seriously from the start, instead of laminating it onto a pre-existing iPaaS or API gateway.
There are three honest answers to the agent-integration problem, and a fair amount of writing about how to pick between them. We've covered the engineering trade-offs in detail in API modernisation for agents: build, buy, or wait. The short version, framed for the SaaS integration buyer:
Build means rewriting or extending your API layer until it covers the surface your agents need. This is the most architecturally clean answer. It takes two to five years for any product of meaningful complexity, and the agent project waits. For most established SaaS companies, the rewrite has been on the roadmap for several planning cycles already and keeps getting deferred. Honesty about that pattern is the first step toward not pretending it's the plan again.
Buy means picking a tool-generation and runtime platform that meets the existing codebase where it is. This is where the new category of tooling sits. The risk is category immaturity — there is no Gartner Magic Quadrant for this yet, and won't be for a while. The upside is that the agent project ships this quarter instead of after the rewrite that hasn't happened.
Wait means assuming the foundation model providers will solve it, or that the next protocol release will close the gap, or that something simpler will emerge. Some teams are right to wait. Most aren't, because waiting has a quiet cost: every quarter the agent project doesn't ship, the competitive surface shifts, and the integration debt — which is measurable — keeps compounding. MuleSoft's 2025 Connectivity Benchmark Report, which surveyed IT leaders at enterprises with 1,000+ employees, puts the average annual cost of integration challenges at around $6.8M. That figure is for the old integration problem. The agent-era equivalent isn't smaller.
The build-vs-buy framing also misses a middle option that's worth naming: buying for the agent layer and continuing to build for the system-to-system layer. Most established SaaS teams already have an iPaaS in place for the latter. Recognising that the agent layer is a separate problem with separate tooling isn't a contradiction. It's an accurate read of where the category is going.
This is the problem Pontil exists to solve. We're a Tools-as-a-Service platform — the category we've defined for the tools layer of the agent stack. We generate agent-ready tools from your existing codebase, run them through a managed runtime where every call executes as the authenticated user, and maintain the catalogue automatically as your product changes.
The positioning is deliberate. We're not an iPaaS, an API gateway, or an agent framework. We sit between the model that reasons and the SaaS product that gets acted on, and we operate on systems you own — your APIs are the contract, your CI and tests work, your observability holds. If your team is building agents on your own platform and the integration layer is the blocker, that's the conversation we want. You can see how it works or book a demo.
The term is going to keep meaning what it has always meant: getting systems to talk to each other. That problem isn't going away, and the iPaaS category will continue to be the right answer for it.
But a second meaning is forming next to the first one, and the teams who treat them as the same problem are the teams whose agent projects are stalling now. Agent-to-product integration has different requirements, different buyers, and a different category of tooling. The honest framing — for analysts, buyers, and the vendors trying to describe themselves — is that there are two layers, and pretending otherwise serves nobody.
The question worth asking inside your own organisation isn't which SaaS integration platform to standardise on. It's whether your current platform is solving the layer you actually need solved next.
