Blog

Beyond iPaaS: Why Capabilities Are the Right Unit for an Agentic Integration Platform

Jerome Louvel ·August 10, 2026

Table of contents

Airia calls it “the next evolution beyond iPaaS.” Integrate.io calls it “AI-native iPaaS.” Nango calls it an “agentic API integrations platform.” Composio calls it “agent-native.” Merge just calls them “agentic integrations.” Five vendors, five labels, one shape: infrastructure for connecting AI agents to the systems an enterprise already owns.

That much convergence means the category is real. It also means the definition is wide open — and the question underneath it is unresolved: what does the platform actually deliver? That is the difference between an agent that works in a demo and one that survives a security review.

What iPaaS was optimized for

Boomi, Workato, MuleSoft, SnapLogic, Tray won for good reason: every company needs to connect applications and govern how systems interact, and they gave integration teams a visual platform to do it. Zapier and Make did the same further down-market. A human opens a canvas, picks connectors, draws mappings, promotes the flow.

Composio puts the mismatch well: workflows run lines, agents run loops. A workflow has fixed steps and the same outcome every run. An agent assesses, attempts, adapts, repeats — against ambiguity and incomplete data. Neither model is wrong; they are built for different execution shapes.

The load-bearing assumption is that a human knows up front which integration is needed. That breaks when the consumer is an agent, because agents encounter what they’re missing while working, and they need the minimum governed operation for a goal — not a connector catalog.

Dimension	Traditional iPaaS	Agentic Integration Platform
Primary user	Integration specialists	AI agents, developers, platform teams
Unit of work	Workflow, connector, recipe	Governed capability
Creation model	Human designs the flow up front	Agent or developer requests what’s missing
Governance	Policies around workflows	Identity, policy, approval, audit per capability
Cost model	Priced per workflow execution	Optimized for tokens, turns, task determinism
Deployment	Cloud iPaaS, hybrid runtime agents	Cloud-managed control plane, BYOC execution

iPaaS was a platform for building integrations. An Agentic Integration Platform is a platform for delivering capabilities — requested by agents, approved by humans, governed in operation.

Why cost is the honest problem

Trust gets the headlines. Cost is what stops agentic programs reaching production.

The dominant cost is not the API call. It is the tokens, turns, and retries the model burns figuring out what to call and what the response meant. The pattern is consistent: point an agent at a generic MCP server mirroring an entire SaaS API, a few hundred loosely shaped tools land in context every turn, selection accuracy degrades as the surface grows, raw JSON envelopes get dumped back into the window, and the agent spends extra turns filtering in natural language. Then someone upgrades the model to compensate.

Cost grows superlinearly with surface size while reliability moves the other way — and it is unpredictable, since the same task costs a different amount depending on how the model happened to reason.

Two principles follow, and they are the entire economic argument:

Every decision moved out of the model’s reasoning loop and into deterministic capability logic stops costing tokens.

The cheapest token is the one you never put in the context window.

Pagination, token refresh, retries, mapping, joins, error normalization — all of it belongs in the capability, not the prompt. Deterministic execution is effectively free compared to inference. And a well-shaped capability lowers the intelligence required to use it correctly, so a mid-tier model often succeeds where a frontier model was needed just to survive a messy surface. Capability design is cheaper than model size.

Where the platforms differ — and it’s the unit

Everyone agrees agents need governed access. They disagree, quietly, on what gets delivered. Three answers are on the table.

The connector inventory. Airia, Integrate.io, Composio, and Merge lead with breadth: hundreds or thousands of pre-built connections with auth, token lifecycles, and observability handled. Composio’s “action layer” framing states the value clearly — OAuth flows and vendor plumbing are miserable to build, and outsourcing them is a rational trade. Merge adds a unified API so one integration covers many vendors. Real leverage, and the security checklists they publish are the right ones.

But solving connection is not solving shape. A connector is sized for the API, not the task — GITHUB_LIST_STARGAZERS is a faithful projection of a REST endpoint, which is exactly the problem: you inherit the upstream schema, verbosity, and operation count. A unified API normalizes toward a category’s common denominator, not toward your agent’s job. An inventory dropped into context is the cost problem above. Tellingly, Composio ships tool-call optimization and “self-healing” pipelines — an admission that the raw surface doesn’t work well enough alone and shaping must happen somewhere. We agree. We think it belongs in a reviewable artifact up front, not a feedback loop tuning a surface you cannot read.

Agent-generated code. Nango’s framing is the sharpest of the five and closest to ours: coding agents build integrations, product agents consume them, integrations live as code in your repo. “Just-in-time integrations” is the right instinct.

And to be fair: separating credentials from generated code is entirely possible and is best practice. Secrets go in a vault, injected at runtime, never in the repo. That is not the gap. The gap is that secret hygiene answers “where is the credential stored,” when the question that matters is “what does binding this credential authorize.” You cannot answer that by reading imperative code — determining which endpoints a piece of TypeScript will actually call, with computed URLs, branching, dynamic dispatch, and a dependency tree, is not tractable static analysis. So verification happens by running it. Sandbox tenants narrow the blast radius, but you reviewed one observed run, not the artifact’s full behavior. The same applies to cost: you cannot statically prove generated code is right-sized or won’t fan out into an unbounded pagination loop. You find out in production telemetry.

The declarative capability. A Naftiko capability is a spec — not code, not a catalog entry. It enumerates by construction what it consumes upstream, what it exposes downstream, how it authenticates, what it masks, and what shape comes back. There is no control flow to reason about, because the surface is the artifact.

So the reviewer approving the credential binding sees the complete set of operations that credential will ever authorize, before it is bound. It can be linted, policy-checked, diffed in a pull request, and validated before it runs — not by a test run, but as a property of the document. That claim is narrower than “we keep secrets out of the repo,” which everyone does. The distinction is that a declarative artifact can be exhaustively reviewed without being executed, so the approval gate sees what production will. Neither the connector inventory nor the generated-code approach can offer that.

Why a capability is the right unit

Four properties, and they fix cost and trust simultaneously:

Right-sized. Only the operations an agent needs, shaped around the task. Smaller context, better first-try selection, fewer retries.
Deterministic. Auth, pagination, retries, and mapping execute inside the capability. Cost per task becomes budgetable.
Shaped. Return projections and summaries, not raw payloads — often an order of magnitude fewer tokens.
Governed at the boundary. Identity, policy, credentials, versioning, and audit meet in one place, which is also where you meter spend.

The security posture is not “keep agents away from secrets.” It is more specific: an agent should not be the thing that determines what a credential authorizes. It can propose, draft, and test against mocked sources — but the scope that credential grants is fixed by the reviewed spec, not discovered by watching code run.

Agent proposes or reshapes capability
        ↓
Mocked / sandbox source
        ↓
Deterministic validation
        ↓
Policy, approval, credential-binding gates
        ↓
Scoped credential binding to the real system
        ↓
Observed, audited, reversible execution

That staging model only works because the artifact is declarative. You cannot gate what you cannot inspect.

The delivery model matters too — cloud-managed, without surrendering the integration

There is a second shift running alongside this one. The iPaaS generation grew up when SaaS meant “the vendor runs it, you configure it,” and that bargain was fine when the thing being configured was a workflow. It is a worse bargain when the thing is your integration layer.

The reason is that integration logic has become integration IP. The domain mappings, the policies, the orchestration, the accumulated knowledge of which system means what — that is increasingly how a business actually runs. When it lives only inside a vendor’s proprietary runtime, as a canvas you can view but not own, leaving means rebuilding. And agents raise the stakes: the surface an agent acts through is not a background data pipe, it is the boundary where decisions become actions.

Meanwhile the operational expectation has moved the other way. Developers now expect serverless immediacy — no runtime to provision per integration, hosted endpoints, managed logs and metering, usage-based pricing. Nobody wants to stand up infrastructure to give one agent one capability.

Those two pulls only reconcile if you separate the control plane from the execution plane:

Cloud-managed by default. Hosted validation, endpoints, logs, metering, and lifecycle. Fast enough that a single developer can go from missing capability to working agent in an afternoon.
BYOC when control demands it. Execution runs in the customer’s own cloud or private network — data residency, credential custody, and private-system reach stay inside their boundary — while the catalog, policy, governance, and updates stay centrally managed.
Portable either way, because the capability is a spec. The artifact does not change between hosted and self-run; only the environment bindings do. That is what makes the choice reversible rather than a migration.

This is where the declarative unit pays off a second time. A workflow drawn in a proprietary canvas is only as portable as the vendor allows. A spec in your repository is portable by construction — which means “cloud-managed” can be a convenience you opt into rather than a dependency you inherit.

Start cloud-managed. Move execution in-house when residency, network, or credential boundaries require it — without re-authoring anything.

Four questions if you are evaluating the category

What is the unit you deliver to my agent? A mirrored endpoint, a unified-API resource, a generated wrapper, or a task-shaped contract? “How many connectors” measures reach, not fit.
Can it be validated before it runs? Can a reviewer read the artifact and enumerate every upstream operation it will ever perform? If verifying behavior requires executing it, your approval gate inspects a sample, not the surface.
What does a task cost, and can you attribute it? Per agent, per capability, per tenant. If cost is only visible after the invoice — or priced per tool call, billing you for the retries a bad surface causes — it is not governed.
Who owns the integration, and where does it run? If the logic only exists inside the vendor’s runtime, you are renting your integration layer. Ask whether execution can move into your own cloud without re-authoring, and whether you could walk away with the artifact.

iPaaS is not going away, and neither is the auth plumbing an action layer solves. But the surface AI agents consume is a different product with different physics, and it is being decided on what gets delivered, not how many connectors ship in the box.

We think the answer is a capability: declarative, right-sized, deterministic, and fully inspectable before anyone decides what it may reach.

Explore Ikanos on Shipyard

Subscribe to the Naftiko Manifest

Want to learn more and stay up to date on the latest from Naftiko? Get new posts, releases, and signals from the capability fleet in your inbox.