iPaaS meaning in the agent era: the definition still fits, the assumptions don't

iPaaS means integration platform as a service — cloud-hosted middleware that connects applications, data, and processes across a business. The definition hasn't changed. The assumptions underneath it have. iPaaS was built to move records between systems on a schedule, with humans designing the flows and other systems as the callers. Now agents are the caller, the schedule is "whenever the user asks," and the flows have to be discovered at runtime. The definition still fits. The category no longer covers the job.

What iPaaS actually means

Integration platform as a service is cloud-hosted middleware. You buy it as a subscription, log in, and build integrations in a low-code canvas. The platform gives you pre-built connectors to common SaaS products, a workflow engine to define the logic, and hosted runtime so you don't operate the servers. Vendors like Workato, Boomi, MuleSoft, and Tray.ai sit here.

The design assumption is stable. Two known systems, a known mapping between them, and a schedule or trigger that fires the flow. A human integration engineer builds it once. It runs the same way every time. That model held for two decades of SaaS integration work — Salesforce to NetSuite, Marketo to Snowflake, Zendesk to Jira. We wrote a longer piece on what iPaaS actually is and how the architecture works if you want the full walkthrough.

Where the definition stops fitting

iPaaS assumes the caller knows what it wants before the flow runs. An agent doesn't. An agent decides at runtime which capability to invoke based on what the user asked and what tools are available. That's a different shape of problem.

Three specific mismatches:

Flows are pre-designed. Agent needs are open-ended. An iPaaS recipe moves an opportunity from Salesforce to NetSuite when the stage changes. Useful. Predictable. But an agent asked to "draft a renewal quote for the top three at-risk accounts" needs to reach dozens of capabilities in an order nobody scripted. You can't pre-build every flow an agent might want.

Runtime executes as a service account. Agents need delegated identity. iPaaS connections use a shared service credential — one integration user with broad scope. That model breaks for agents, which need to act as the authenticated user so permissions, data visibility, and audit trails honour the real identity. We covered why this matters in agent identity vs user identity.

Connectors expose CRUD. Agents need workflows. Most iPaaS connectors mirror the underlying API — create record, update record, list records. Fine for a system-to-system sync. Bad for an agent that needs to "process this refund," which is six API calls with conditional logic. The tool granularity is wrong.

iPaaS vs the tools layer

Different layers of the stack. Not competing categories.
‍

The honest read: if you're syncing Salesforce and NetSuite, iPaaS still fits. If you're building an agent on your own product that needs to reach what your UI can do, iPaaS was never the right shape. It was built to connect systems into your product. The agent problem is exposing your product out to agents. Different direction, different requirements.

What the agent era actually needs

Three things iPaaS wasn't designed for:

1. Tools generated from the product, not the API. In our experience, most SaaS products expose only a small fraction of their capability through public APIs. The rest lives in internal endpoints the UI already uses. Agents need reach into that surface, not just the documented public one. A connector library maintained by a vendor can't touch it.
2. Delegated auth at the tool call, not the connection. Every tool invocation carries the end user's identity, not a shared credential. This is what makes permissions, rate limits, and audit trails actually work at agent scale.
3. Maintenance aligned with the product's SDLC, not a vendor release cycle. When your product changes, your tools should change with it — through your own CI, your own tests, your own observability. Not a support ticket to a connector vendor.

None of that is a criticism of iPaaS. It's a category built for a different job. Asking it to serve agents is like asking an API gateway to be a database — the layer is wrong.

How Pontil fits

Pontil is a Tools-as-a-Service platform. We sit in the tools layer of the agent stack, between the model that reasons and the product that gets acted on. That's a different layer from iPaaS, and a different job.

We generate agent tools from the customer's existing codebase — including the internal endpoints the UI already uses, not just the documented public API. Tools stay current through the customer's own CI. Runtime executes as the authenticated user, so permissions and audit trails honour the real identity. If you want to see how the pieces fit together, the Pontil product page walks through it, and why agent projects stall covers the structural problem this all sits on top of.

What this means for the reader

If you're evaluating iPaaS in 2026, ask what job you're actually doing. If it's system-of-record sync between two known SaaS products, the category still fits and the vendors are mature. If it's making your own product reachable to the agents you're building, iPaaS is the wrong layer — not because the vendors are bad, but because the assumptions don't match. The definition of iPaaS hasn't changed. The scope of what it can cover has narrowed. Pick the layer, then pick the tool.