Internal integration platform vs embedded iPaaS: which one fits when agents are the caller

You're a Head of AI or CTO at a B2B SaaS company. Your engineering team has spent the last six months arguing about two options. Build the integration platform in-house — own the connectors, control the runtime, absorb the cost. Or buy an embedded iPaaS — ship faster, outsource the connector maintenance, accept the vendor boundary.

Both answers were designed for a world where humans configured integrations through a UI. Neither was designed for the world you're now in, where AI agents are the primary caller.

This piece compares the two honestly. Where each one wins. Where each one breaks. And what to reach for when the caller isn't human.

Short version: an internal integration platform wins when integrations are core to your product and you need runtime control agents can honour. Embedded iPaaS wins when the integration is a checkbox on a feature list and the buyer is a human admin. Neither is agent-native, which is the third option most teams miss.

How an internal integration platform works

An internal integration platform is a system your team builds and runs. It sits between your product and the third-party APIs it needs to reach — CRMs, ticketing systems, data warehouses, whatever your customers ask for. Your engineers write the connectors, maintain the auth flows, absorb the schema changes when a vendor ships a breaking release, and operate the runtime that executes each call.

The stack usually looks like this. A connector layer wraps each third-party API in a normalised shape your product can consume. An auth service holds OAuth tokens, refreshes them, and routes calls under the right customer identity. A queue absorbs retries and rate limits. An observability layer catches failures before your support team hears about them. Everything runs on your infrastructure, under your SDLC, wired into your existing CI, tests, and monitoring.

The reason teams choose this path is control. Every layer is one you own. When connector deprecation happens — and it happens continuously, not on a schedule — you decide how to respond. When a customer needs a niche endpoint, you add it. When a security review asks who's calling what, you have the audit trail. The trade-off is obvious: you're funding a small integration engineering team forever, and that team's velocity is now a hard ceiling on how many integrations your product can offer.

How embedded iPaaS works

Embedded iPaaS — vendors like Prismatic, Paragon, Workato Embedded, and Tray Embedded — is a hosted platform your product integrates into rather than builds. (Unified API vendors like Merge show up in the same buy-vs-build conversation but are architecturally distinct: they normalise a category of APIs behind a single schema rather than hosting a workflow runtime.) You embed their UI or SDK in your product, and your customers use it to connect their own third-party accounts. The vendor maintains the connectors, hosts the runtime, and takes the maintenance load off your team.

The stack from your side is thin. You embed a component. You wire a webhook or two. You map some of your product's data to their normalised schemas. On their side sits everything you'd otherwise be building: connector catalogues covering hundreds of SaaS apps, OAuth flows for each, retry logic, monitoring dashboards for your customers, and a visual builder your customers' admins use to configure workflows.

The reason teams choose this path is speed and coverage. You ship 50 integrations in a quarter instead of five. Your team stops being an integration factory. Your product marketing gets a partner logo wall. The trade-off is that you've handed the runtime, the connector roadmap, and often the customer experience to a vendor. When a customer needs an endpoint the vendor doesn't cover, you're either waiting or building it yourself anyway. When agents become the caller, you're depending on the vendor's model of what agent access should look like — which, right now, is mostly "same integrations, different UI."

Comparing the two on the dimensions that matter

A few of these deserve unpacking. The auth row matters more than it looks. Most embedded iPaaS runtimes execute a call using a token attached to the connection — configured once by a customer admin, then reused across every workflow that touches that connection. That works when a human admin has authorised a defined automation. It doesn't hold when an agent is deciding, per turn, what to do on behalf of an end user. The audit trail collapses to "the workflow did it," and least privilege is impossible to enforce.

The cost row also misleads teams. Embedded iPaaS looks cheaper on day one and stays cheaper for narrow use. Once you're routing serious volume, or once every agent turn produces a tool call, per-request pricing catches up fast. Meanwhile the internal platform's fixed cost is exactly that — fixed — and the marginal cost of the next call is close to zero. If integrations are a growth vector for your product, the crossover happens sooner than the vendor's pricing page suggests.

When to choose an internal integration platform

Build in-house when integrations are structurally part of your product, not a peripheral feature. Concretely:

• Integrations are how customers get value from your product. If your product is a data platform, an analytics tool, or anything where the value proposition is "we work with everything you already use," the connector layer is your product. Outsourcing it means outsourcing the roadmap for your differentiator.
• Your customers need niche endpoints that no vendor will build. Vertical SaaS is full of this — the ticketing system used by 200 hospitals in the northeast, the ERP used by mid-market European manufacturers. Nobody's building those connectors for you.
• You need runtime control for security or compliance reasons. Regulated industries, healthcare, financial services — you need to answer specific questions about where data goes and who called what, and you need the answers to live in your SIEM, not a vendor's dashboard.
• You have an engineering team that can absorb the ongoing maintenance cost without it being the whole team's job. This is the honest one. If the connector maintenance cost will consume more than about 20% of your platform team's capacity, the compounding cost will eventually break the case.

When to choose embedded iPaaS

Buy embedded iPaaS when the integration is a checkbox, not a product surface. Concretely:

• Your buyers need a wide catalogue, fast, and none of the integrations are deep. Sales prospects ask "do you integrate with Salesforce, HubSpot, Zendesk?" and the honest answer is "we push data one way, once a day." That's the sweet spot for embedded iPaaS.
• The integrations are configured by human admins and run in the background. Sync contacts. Create tickets. Post to Slack. Workflows a person sets up once and rarely touches.
• Your engineering team's time is better spent on core product. If integrations are commoditised for your category and every competitor has the same 40 connectors, the strategic move is to not build them.
• You accept the vendor boundary. Runtime, roadmap, pricing model. When the vendor raises prices or deprecates a connector you depend on, you'll live with it.

One caveat worth naming: embedded iPaaS is a poor fit for agent-driven integrations. The runtime assumes a human designer and a background executor. That's the wrong shape for a caller that's making live decisions on behalf of a specific user.

How Pontil fits

The internal vs embedded iPaaS debate assumes those are the only two options. When the caller is an AI agent, neither one is a clean fit. An internal platform gives you runtime control but doesn't solve the underlying problem — that your APIs expose about 2% of what your product can do, and building bespoke agent connectors on top compounds the same integration engineering tax that's already stretched thin. Embedded iPaaS was built for human admins configuring workflows, not for agents deciding what to do per turn under a real user's identity.

Pontil sits in a different layer. We generate tools from the codebase you already have, run them as Tools-as-a-Service, and execute each call under the authenticated user — not a shared service account. That gives you the runtime control an internal platform promises without funding another engineering team, and the coverage an embedded iPaaS promises without the vendor-defined runtime that breaks for agents.

What we'd choose

If integrations are your product, build internally — and design the runtime for agent callers from the start, not just for human-configured workflows. That means per-user identity at the call boundary, tool contracts your agents can discover, and observability that traces which agent, on behalf of which user, called what.

If integrations are a feature and your buyer is a human admin configuring background sync, buy embedded iPaaS. Save your team for the product.

If you're building agents on your own platform and you're stuck between the two, the honest answer is that this is a different problem. The right question isn't "internal vs embedded iPaaS" — it's "what does the tools layer for our product actually look like, and who's going to keep it current as the product evolves." That's the question worth spending the next three months on, not the build-vs-buy debate that framed the last six.