The role of Embedded iPaaS in the AI Gold Rush

Updated on 16th June 2026 by Fraser Davidson

Picks and Shovels

Let’s get this out of the way first: AI is awesome.

When there is a genuine problem to solve, or a real need that benefits from AI, the results can be transformational. My personal favourites are the AI-facilitated chat experiences in Duolingo and the image generation capabilities of ChatGPT and similar tools. In the right context, AI can improve speed, accessibility, creativity, and user experience in ways that would have felt unrealistic just a few years ago.

However, I don’t believe Embedded iPaaS vendors should automatically adopt AI inside their own product just because the market is excited about it.

That may sound contrarian in the current climate, but I think it is an important distinction. Not every product benefits from adding AI to its core workflow. In some cases, AI genuinely removes friction. In others, it adds abstraction where users actually want control, certainty, and precision.

For Embedded iPaaS, I believe the opportunity is not to become an AI product. It is to become the infrastructure that helps AI products work safely, reliably, and at scale.

Embedded iPaaS the Facilitators

Embedded iPaaS should be a facilitator.

It should be the data orchestration layer that enables secure connectivity between applications, services, and AI systems. It should make it possible for data to move into, through, and out of AI applications in a controlled and auditable way. It should handle authentication, routing, transformation, governance, and tenant-aware delivery without forcing product teams to reinvent those capabilities from scratch.

In short, Embedded iPaaS should continue doing what it has always done best: making complex integrations repeatable, manageable, and scalable.

Historically, I have described Embedded iPaaS as the utility company for SaaS applications — the pipes that move data from one place to another. In the context of the AI boom, I think there is a better analogy available.

Embedded iPaaS is the picks and shovels of the gold rush.

That is not a secondary role. It is an incredibly valuable one. In any technology wave, the platforms that enable the ecosystem often become just as important as the applications generating the headlines. AI products need access to clean, timely, secure data. They need actions to be triggered in downstream systems. They need workflows that can be monitored and governed. That is exactly where Embedded iPaaS fits.

What this looks like in practice

A practical example helps.

Imagine a SaaS platform that wants to add an AI assistant for its users. The assistant might need to pull customer data from a CRM, enrich it with billing information from another system, retrieve product usage data from an internal database, and then send a summary into a support or messaging tool.

The AI model is only one part of that experience.

The harder problem is making sure the right data gets to the right place, in the right format, with the right permissions, for the right tenant, at the right time. That is the job of the integration layer. Embedded iPaaS makes that possible by orchestrating the flow end to end, while preserving structure, reliability, and security.

So when I say Embedded iPaaS should enable AI, that is what I mean. Not “AI for the sake of AI,” but dependable infrastructure for AI-enabled products and workflows.

Why I don’t think AI belongs inside Embedded iPaaS itself

Frankly, because if the Embedded iPaaS is well designed enough, the need is not really there.

Embedded iPaaS platforms are specification engines. They are built for data-literate users and audiences that range from semi-technical to deeply technical. These users are often configuring complex workflows, handling authentication logic, mapping fields, defining execution steps, and making decisions about how data should move between systems.

That kind of work benefits from clarity.

Users in this environment are not usually asking for more abstraction. They are asking for more visibility, more control, and more confidence in what the platform is doing. They want to know exactly what has been configured, exactly how a workflow will behave, and exactly where data is going. In an integration context, ambiguity is often the enemy.

Over the years of building Cyclr, one thing has become increasingly clear to me: abstraction is useful up to a point, but our target customer profile — our ICP, or ideal customer profile — often wants more detail, not less.

That insight matters. It shapes how we think about roadmap decisions. Whenever we review opportunities to add AI, we ask a simple question: what problem would this actually solve for our users?

So far, we have not found a compelling answer from within the Embedded iPaaS product experience itself.

The difference between assistance and abstraction

This is where the conversation becomes more nuanced.

I am not arguing that AI is useless in software infrastructure. Nor am I suggesting vendors should ignore it. The real question is whether AI improves the user’s ability to build and manage integrations, or whether it simply abstracts away important detail.

Those are not the same thing.

If AI helps users discover documentation faster, troubleshoot errors, explain connector behaviour, or recommend next steps based on clearly visible logic, there may be value there. But if AI starts replacing explicit configuration with probabilistic interpretation in areas where precision matters, the trade-off becomes much less attractive.

Integration design is not the same as brainstorming a marketing outline or summarising a meeting transcript. When users are building production workflows, they need determinism. They need to trust that what they configure is what will happen.

That is why I remain cautious about embedding AI directly into the flow-building experience.

Why this differs for other iPaaS products

If we were building an iPaaS product for non-technical users, my stance would probably be different.

Take platforms like Zapier or IFTTT. Their workflows are generally simpler, their user base is often less technical, and the value of reducing setup friction is much higher. In those environments, AI can play a clear role by helping users describe what they want in plain language and converting that into a usable automation.

That is a strong use case because the user need is obvious.

In those products, AI can serve as a guide for people who may not know what triggers, actions, mappings, or conditions they need. It lowers the barrier to entry and helps users get to value faster.

But Embedded iPaaS serves a different audience and a different job to be done. The requirements are more complex, the stakes are higher, and the users are generally better served by explicit control than by inferred intent.

The strategic opportunity

This is why I think Embedded iPaaS vendors should resist the pressure to force AI into the centre of their product narrative.

There is already a highly valuable role to play.

As AI adoption grows, more SaaS companies will need secure ways to connect models, applications, data stores, internal services, and customer environments. They will need orchestration across multi-tenant systems. They will need governance, observability, and repeatable workflows. They will need a way to connect AI capabilities to real business systems without creating chaos.

That is a major opportunity.

The winners will not just be the companies building the most visible AI features. They will also be the companies enabling those features to function in the real world.

Final thought

So yes, we are very happy to be the picks and shovels of the AI gold rush.

That is not a compromise. It is a strategy.

AI needs infrastructure. It needs secure connectivity. It needs reliable orchestration. It needs systems that make data usable, portable, and governed across products and tenants.

That is where Embedded iPaaS shines.

And unless a genuinely useful internal AI use case emerges for our customers, I would rather keep building the platform that enables the AI world than add AI for the sake of saying we did.

You may also enjoy these…