Embedded iPaaS vs the tools layer: which one your AI agents actually need

Embedded iPaaS has spent a decade solving a real problem. If you're a SaaS company that needs to let your customers connect Salesforce, HubSpot, NetSuite, or any of the other hundreds of systems they already run, an embedded integration platform is often the right call. Paragon, Prismatic, Workato Embedded, and Merge all do this well — though it's worth noting that Paragon and Merge have both since launched agent-facing products (Paragon's ActionKit and Merge's MCP server) that overlap with the tools-layer category we'll get to shortly.

But the question on the table now is different. Your customers aren't asking for another Salesforce sync. Your product team is building an AI agent on top of your own platform, and the agent can't reach what the UI can do. So you're evaluating: does an embedded iPaaS solve that, or is this a different kind of problem?

Short version: embedded iPaaS solves third-party integration inbound to your product. The tools layer solves outbound access from your product to agents. They sit on opposite sides of your boundary. Picking the wrong one is the most common reason agent projects stall in the build phase rather than ship.

How embedded iPaaS works

Embedded iPaaS is integration platform software that ships inside your product. Your customer logs into your app, clicks "Connect Salesforce," authenticates, and a prebuilt connector starts moving data between Salesforce and your system. You don't build the connector. The vendor maintains it. You expose a config surface — usually a UI component or an SDK — and the vendor's runtime handles the rest.

The model is mature. The unit of work is a connector to a third-party system, the unit of value is removing the integration backlog from your roadmap, and the customer outcome is that your product now talks to the tools they already use. Pricing typically scales with the number of connected accounts or the volume of events. The category is well-defined and the leaders have been operating at scale for years.

What embedded iPaaS does not do, by itself, is expose your product's own capabilities to anything outside your product. The data flow is inbound. Salesforce data lands in your database; your customer's HubSpot fires a webhook; your app reacts. The iPaaS sits between your customer's other tools and your product. Your own internal surface — the actions a logged-in user can take inside your app — is not what the connector library is built around. Some iPaaS vendors now ship agent-facing add-ons, but those add-ons point at the same third-party catalog the connectors do, not at your codebase.

How the tools layer works

The tools layer is the part of the agent stack that turns a product's capabilities into things an agent can invoke. It sits between the model that reasons (Claude, GPT-5, Gemini) and the product that gets acted on (your SaaS). An agent decides it needs to update a record, draft an email, or move a deal stage. The tools layer is what makes those actions exist as callable, reliable operations with real auth, real error handling, and real observability.

The defining feature is direction. Tools-layer platforms generate tools from your existing codebase — the API surface, internal endpoints, business logic that the UI already calls. You don't rewrite. You don't wait for a foundation model provider to ship a connector for your specific product. The tools get generated, run inside a managed runtime, execute as the authenticated user rather than a shared service account, and stay current as your product changes.

This is the category Pontil operates in. It's what we call Tools-as-a-Service, and it exists because the two obvious alternatives — rebuild the API layer over two to five years, or hand-roll bespoke connectors per product — are both unfundable at portfolio scale. We've written a longer definition of Tools-as-a-Service and where it fits for anyone working out whether the layer is real or just relabelled middleware.

How they actually compare

The rows that matter most are the first two. Everything else follows from direction and consumer. If you confuse those, the rest of the evaluation goes off the rails — you end up comparing connector counts when the real question is whether the platform points at your problem at all. This is also why iPaaS vendor marketing has gotten harder to parse: several embedded iPaaS players now sell agent-facing products too, but the architectural distinction — third-party connectors versus tools generated from your own codebase — is what separates the categories, regardless of how the homepage reads.

When to choose embedded iPaaS

Choose an application integration platform when the problem you're solving is your customers asking to connect their other software to yours. Concretely:

• Your sales team is losing deals because prospects ask "do you integrate with [X]?" and the answer is no.
• Your roadmap has a growing backlog of one-off integration requests, and your engineers want them off their plate.
• You want your customers to self-serve the connection — pick a system, OAuth in, map fields, done — without filing a ticket.
• Your competitive position depends on the breadth of third-party systems you support out of the box.

In that situation, embedded iPaaS is the right call. The category leaders are good, the pricing model is predictable, and you don't need to build a connector team. This is what these platforms were designed for, and they do it well.

This is also true even if you have an agent project running. Embedded iPaaS and the tools layer aren't mutually exclusive. They solve different sides of your product boundary. Many companies will eventually need both.

When to choose the tools layer

Choose a tools-layer platform when the problem is that your own agents can't reach what your own product can do. Concretely:

• You're building an AI agent on top of your platform and the API exposes a fraction of what the UI can do. (We've written about the 2% problem — our framing for why the gap between product capability and API surface is usually larger than teams expect.)
• The first agent demo worked. The second one stalled because every new capability required a new endpoint, and the API team is six months behind.
• You have multiple products in a portfolio and writing bespoke connectors for each one would take longer than the agent strategy can wait for.
• Permissions and audit matter. The agent has to execute as the real authenticated user, not a shared service account, or the security review will kill the launch.
• You need tools to stay current as your product changes, without a manual maintenance team chasing every release.

In that situation, an embedded iPaaS's connector library — even with an agent-facing layer bolted on — won't expose your product's capabilities to agents. The connectors point at the vendor's catalog (Salesforce, HubSpot, and so on), not at your product, because your product isn't a third-party system from the iPaaS vendor's point of view. It's the host. The integration you need points the other way.

How Pontil fits

Pontil is a Tools-as-a-Service platform. We make SaaS products accessible to AI agents — the outbound side of the boundary that embedded iPaaS, even with agent add-ons, doesn't address.

The practical difference for an engineering or AI lead evaluating both: an embedded iPaaS hands your customers a connector library so they can plug their other tools into your product. Pontil generates the tools your agents need to act inside your product, runs them in a managed runtime as the authenticated user, and keeps them current as your codebase changes. We operate on systems you own, against the APIs that already exist. No rewrite, no waiting on a foundation model provider's roadmap, no shared service account.

If your agent project has stalled on access — not on orchestration, not on model choice — the tools layer is what's missing. You can see how the architecture works on the Pontil product page, or book a walkthrough if you want to talk through whether this fits your stack.

What we'd choose

The honest answer: it depends on which side of the boundary the problem sits on, and the variable that decides it is who the integration is for.

If the integration is for your customers — letting them connect Salesforce, HubSpot, Slack, or any other third-party system into your product — pick an embedded iPaaS. Paragon and Prismatic are both good defaults; Merge is strong if you want a unified API rather than per-connector logic. (Both Paragon and Merge now ship agent-facing products too, which can be useful if you want one vendor for third-party access on both sides of the boundary — just be clear-eyed that those agent tools still target the third-party catalog, not your own product.) The category is mature and you'll get value quickly.

If the integration is for AI agents reaching into your own product — letting them do what your product can do — pick a tools-layer platform. An embedded iPaaS connector library won't solve this on its own, regardless of how many connectors it ships or whether the vendor has bolted on an agent SKU, because none of those connectors point at your product. You need something that generates tools from your codebase, runs them with real auth and observability, and maintains them as you ship.

The failure mode we see most often is teams buying integration platform software for an agent problem, spending a quarter trying to make the connector library do something it wasn't designed to do, and ending up back at the same evaluation six months later. The category is right. The direction is wrong. Get the direction right first; the rest follows.