Cloud based integration platform vs the tools layer: which one fits agents

Your team tried browser automation. Or RPA. Or a mix of both. The demos worked. Production broke every time the UI shifted a button. Now you're looking at a cloud based integration platform as the grown-up answer — and wondering whether that's actually the right shape for what your agents need to do.

This piece is for heads of engineering and VPs of product who have already hit the automation dead end and are evaluating what comes next. The short version: a cloud integration platform is the right answer for system-to-system workflows between third-party SaaS products. It's the wrong shape when the caller is an agent trying to reach inside your own product. Different problems, different layers.

Here's how each one actually works, where each fits, and how to tell which one you're looking at.

How a cloud based integration platform works

A cloud based integration platform — usually sold as hosted iPaaS or integration platform as a service — is a managed environment for connecting one SaaS application to another. You log in, pick a source (Salesforce, HubSpot, NetSuite), pick a destination (Snowflake, Slack, a data warehouse), and build a flow between them. The vendor hosts the runtime, maintains the connectors, and handles the auth refreshes. You get a UI-first flow builder, a library of pre-built connectors, and monitoring for the pipes.

The cloud integration architecture behind this is well-understood. A connector library sits on top of a workflow engine, which sits on top of a hosted execution runtime. Events come in through webhooks or polling. Data moves through transformation steps. Results land in the target system. Vendors like Workato, Boomi, and MuleSoft have refined this shape since the iPaaS category emerged in the early 2010s. It works. Integration debt on the average enterprise runs into the millions per year, and this is the category built to absorb it.

The assumption underneath the model: both endpoints are third-party SaaS products with stable public APIs, and a human designs the flow before it runs. Change either assumption and the architecture starts leaking.

How the tools layer works

The tools layer is a different category. It sits between an AI agent that reasons and the product the agent needs to act on. Instead of connecting product A to product B, it exposes product A's capabilities to an agent as a callable surface — tool definitions, an execution runtime, and the auth plumbing to run each call as the real end user rather than a shared service account.

The motivating problem is different too. SaaS products spent a decade being built for the UI. Their APIs kept up with some of that surface; most of it they didn't. When those companies now try to build agents on their own platforms, the agent can only reach the two percent of the product the API happened to expose. Rewriting the API takes years. Bespoke connectors per product don't compound across a portfolio. So the tools layer generates connectors from the codebase that already exists, runs them under the authenticated user's identity, and maintains them as the product changes. We wrote about this at more length in what is Tools-as-a-Service and where does it fit.

The caller is an agent, not a workflow author. The endpoint is your own product, not a third-party SaaS. Nothing about a hosted iPaaS is designed for either of those.

How they compare

The honest read on the table: these aren't competitors. They solve adjacent problems and the failure mode is picking the wrong one for the shape of work you have.

When to choose a cloud based integration platform

Pick a hosted iPaaS when the work is genuinely system-to-system and the flow is designed in advance.

• You're syncing systems of record. Salesforce to your data warehouse. HubSpot to NetSuite. Zendesk to Jira. These flows are stable, high-volume, and well-served by a vendor library.
• The workflow author is a human, not an agent. A revenue ops manager building a lead-routing flow. An IT team wiring up onboarding automations. The value is the flow builder and the connector library.
• You need pre-built connectors to popular SaaS. If most of your integration backlog is "connect to product X" where X is a well-known SaaS, buying that library is cheaper than building it.
• Latency isn't the constraint. Batch sync every fifteen minutes is fine. Real-time isn't the point.
• You want someone else to own connector maintenance. For third-party APIs you don't control, letting a vendor absorb the breaking changes is worth paying for.

This is the mature use case. The category exists for it. If your problem looks like this, buy the platform and move on.

When to choose the tools layer

Pick the tools layer when the caller is an agent and the surface it needs to reach is your own product.

• You're building agents on top of your own platform. The agent needs to do what your UI does — create records, run reports, trigger workflows, act on user data. Not sync data between other people's tools.
• Your API exposes a fraction of your product. The features live in the codebase; the API surface was built for a specific integration partner years ago; the gap is now the blocker. If you don't know the size of the gap, we wrote a piece on how to calculate it.
• Every action needs to run as the end user. Not a shared service account. Audit trails, row-level security, and permissions all depend on the real identity flowing through to the tool call.
• Rewriting the API isn't fundable. A two-to-five year rewrite isn't going to survive the next planning cycle, and bespoke per-product connectors don't compound across a portfolio.
• The agent picks the tool at runtime. No human sits between the reasoning and the invocation. That changes what the interface has to do — see orchestrator vs tools layer for why this matters.

When you see these conditions together, an iPaaS won't help. The connectors are on the wrong side of the boundary, the auth model is wrong, and the whole runtime is designed for a caller that doesn't exist in your scenario.

How Pontil fits

We build the tools layer. Pontil is a Tools-as-a-Service platform that makes SaaS products accessible to AI agents — generating tools from the customer's existing codebase, running them under the authenticated user's identity, and keeping them current as the product changes.

We're not an iPaaS and we're not trying to become one. If your problem is Salesforce-to-Snowflake, buy a hosted iPaaS. If your problem is that you're building agents on your own product and they can only reach two percent of what the UI can do, that's what we're built for. You can see how the runtime works on the product page or read our primer on the agent stack to see where the tools layer sits relative to everything else.

What we'd choose

Most teams reading this already have a hosted iPaaS. That's fine. The mistake is trying to stretch it to cover the agent access problem, or worse, concluding that because iPaaS doesn't fit, the whole category is broken.

Both are true at once:

• For system-to-system flows between third-party SaaS, a cloud based integration platform is the right answer. The category is mature, the trade-offs are known, and the coverage a vendor library provides is worth paying for.
• For agent-to-own-product access, the tools layer is the right answer. Different caller, different surface, different auth model, different maintenance discipline.

The question that decides which one you need isn't a feature comparison. It's this: who is calling, and what are they trying to reach? A workflow-author connecting Salesforce to Slack is one problem. An agent trying to run half your product on behalf of a customer is a different one. Pick the layer that matches the shape of the work, and stop trying to force the other one to fit.