Platform integration
Agent infrastructure
iPaaS explained: what integration platform as a service actually is, how the architecture works, where it holds up, and where it stops short for AI agents.
iPaaS is one of the most-cited categories in enterprise integration, and one of the most-misapplied when teams start building AI agents. This piece answers the question directly: what integration platform as a service actually is, how the category was built, where it still holds, and where it stops short when agents — not humans — are the caller. The Pontil view in one sentence: iPaaS solved system-to-system integration for human-designed workflows, and it's the wrong shape for agent-to-product access. The sections that follow define the term, unpack the architecture, compare it against the two adjacent categories teams confuse it with, walk through where it holds and where it breaks, and close on what actually fits the agent use case.
Integration platform as a service is cloud-hosted middleware for connecting applications, data sources, and services. The category was defined by Gartner in the early 2010s to describe what SnapLogic, Dell Boomi (now Boomi), Informatica, and MuleSoft were already selling: a hosted environment where you build integrations — usually with a visual designer — deploy them without running your own middleware, and let the vendor handle uptime, connector maintenance, and the runtime. Workato arrived shortly after and became one of the category's defining vendors.
The iPaaS meaning has drifted since. Vendors now use it to cover everything from B2B EDI to embedded integrations to workflow automation. The stable core is narrower: a managed platform for building, running, and maintaining integrations between systems, delivered as a service rather than software you host. That's the iPaaS definition worth using.
Three things follow from that definition. The platform is multi-tenant and cloud-hosted. It ships a library of pre-built connectors to common SaaS applications, databases, and message brokers. And it provides some form of orchestration — usually a low-code designer where non-engineers can wire flows between systems.
Most iPaaS platforms share the same rough shape, regardless of vendor. Understanding the layers matters, because it's the layers — not the marketing — that decide whether the category fits a given problem.
At the base sits a library of connectors: pre-built adapters to Salesforce, NetSuite, Workday, ServiceNow, and the several hundred SaaS applications enterprise customers ask for. Each connector wraps the target system's public API. When the target's API changes, the vendor updates the connector, and every customer using it gets the fix.
This is the layer that gets the marketing attention, and it's also where the category's first structural limit sits. Connectors cover what the target's public API exposes — nothing more. If a SaaS product's UI can do 100 things and its public API exposes 20, the iPaaS connector covers 20. This isn't a vendor failing; it's a definitional constraint.
Above the connectors sits a visual designer where users compose flows: pull records from system A, transform them, push them to system B. This is where the low-code framing comes from. Some platforms lean heavily on this (Workato, Zapier at the SMB end); others treat it as one interface among several (Boomi's hybrid model, MuleSoft's Anypoint Studio for developer-heavy flows).
The orchestration layer's assumption is that a human is designing the workflow up front, at design time, and the runtime is executing that design deterministically. This assumption is load-bearing for the whole category — and it's the one agents violate.
At the top sits the runtime: the hosted execution environment that runs the flows, handles retries, manages credentials, logs the results, and surfaces failures. This is what makes iPaaS a service rather than a framework. You don't operate the middleware yourself.
Runtimes vary meaningfully across vendors — some run in the vendor's cloud, some support hybrid or self-hosted execution for data residency, some are event-driven and some are batch-oriented. But the pattern is consistent: pre-designed flows execute in a managed environment.
Three categories get conflated in every buying conversation. The distinction matters because they solve different problems, and picking the wrong one is how integration projects get stuck for six months.
All three are legitimate categories. All three run into the same wall when the caller shifts from a human-designed workflow to an agent making decisions at runtime — which is the shift this article is really about.
A more detailed treatment of one of these boundaries lives in our comparison of API gateway vs iPaaS, which is useful if you're deciding between the two for a non-agent problem.
Worth stating clearly: iPaaS is not a broken category. It solved a real problem and continues to solve it. If your integration profile matches the shape iPaaS was built for, it's often the right answer.
The fit is strong in four situations. First, when the integration is between two or more discrete systems and the workflow is stable — order-to-cash from Salesforce to NetSuite, HR onboarding from Workday to Active Directory, ticket sync between Jira and ServiceNow. These are designed flows that don't need to change hourly.
Second, when the target systems already have mature public APIs. iPaaS connectors compound on top of what the vendor's API exposes; if the API covers the workflow, the connector will too.
Third, when the primary consumers are business users who need to compose flows without writing code. The visual designer is genuinely useful for that audience, and the alternative — bespoke integrations built by engineering — is slower and more expensive at the workflow level.
Fourth, when governance sits with a central IT or integration function that wants a single audit surface for all cross-system data movement. iPaaS platforms are built around that operating model.
None of that is going away. The rest of this piece isn't an argument against iPaaS in its native territory. It's about what happens when the caller changes.
The shift that breaks the model isn't the addition of AI to iPaaS marketing. Every iPaaS vendor now claims AI features — natural language flow builders, AI-assisted mapping, embedded copilots. Those are real product improvements, and they matter for the human user of the platform. They don't change the underlying architecture.
The shift that breaks the model is when the caller becomes the agent. When an agent — not a human designing a flow at design time — needs to reach a SaaS product's capabilities, four things stop working.
Design-time flows don't fit runtime decisions. iPaaS assumes the workflow was designed up front. Agents decide what to do at runtime based on user intent. Pre-composed flows can't cover the decision space; the moment you need conditional logic that wasn't scripted, you're outside what the flow was built for. The orchestrator versus tools layer distinction is where this really shows up.
Connector coverage is capped at the public API. If a SaaS product's UI can do 100 things and its public API exposes 20, an iPaaS connector will cover 20. Agents built by that same SaaS company on top of their own product can't reach the other 80. This is the problem we wrote about here, and it's why iPaaS doesn't solve the agent-readiness problem for established SaaS companies — the ceiling is the same one the API had.
Auth model is wrong. iPaaS runtimes typically execute flows using stored service credentials or an OAuth grant for the integration itself. The connector acts as the integration user, not as the end user whose intent triggered the agent. For agent tool calls, the identity that matters is the end user's, so permissions, data visibility, and audit trails honour the real person. iPaaS wasn't designed for that boundary.
Maintenance model doesn't compound. Every iPaaS connector is a piece of code the vendor maintains against the target's public API. When a SaaS company wants agents to reach its own product, spinning up bespoke connectors per product doesn't compound — it just moves the maintenance burden inside the company. Connector deprecation becomes a permanent operating condition, not a scheduled event, and the iPaaS event model isn't built for that.
The cleanest way to see the mismatch: iPaaS was designed to connect systems a customer uses. The agent problem, for an established SaaS company, is exposing their own product's capabilities to agents — including capabilities the API never covered. Different shape. Different layer.
The access problem this article ends on — an established SaaS company whose agent project stalls because the APIs cover a fraction of what the UI can do — is the problem Pontil was built for. We sit in the tools layer of the agent stack, not the integration layer. We make SaaS products accessible to AI agents by generating and running the tools agents need against the systems the SaaS company already owns.
That operating model is deliberately different from iPaaS. We work on codebases the customer owns, so we can reach capabilities beyond the public API surface. Tool calls execute as the authenticated user, not as a shared service account, so identity and audit hold up under security review. Maintenance is automated and SDLC-aligned, so tools stay current as the product changes rather than drifting until they break. If your integration problem is system-to-system between third parties, iPaaS is likely still the right answer. If it's your own product's capabilities being unreachable to your own agents, the tools layer is a different conversation.
The honest answer is: not one thing. iPaaS keeps its territory for system-to-system integration. API gateways keep their territory for API management. What's new is a category — the tools layer — that sits between the agent and the product, and that operates on the systems the customer owns rather than on the third-party contracts iPaaS was built around.
What's worth watching over the next 24 months is how established integration vendors respond. Some will extend into agent tooling and hit the coverage ceiling their connector model imposes. Some will partner. Some will treat it as adjacent and stay in their lane. The buying question for enterprise teams isn't which iPaaS vendor is winning the AI marketing race — it's which layer of the stack actually holds the problem you have, and whether the vendor you're evaluating is built for that layer or borrowing the label.
If the problem is your agents can't reach your own product, no amount of iPaaS AI branding will fix that. It's a different layer, and it needs a different shape.
Stay up to date on the ever changing agentic landscape.
GET STARTED
Start with a 30-minute discovery call
contactus@pontil.com
