Kronehoefstraat 85
5612 HL Eindhoven
BTW NL863902509B01
From Moving Data Around to Owning an AI Layer
qw
vc
mshm
.svg)
An AI layer of your own doesn't come from wiring even more systems together, it comes from giving an AI agent direct access to your source data the moment it needs it. That works best when your company has the ambition to build AI as a capability of its own. Without that ambition, off-the-shelf platform AI is often the smarter choice.
Your business probably runs on five to ten systems: accounting, CRM, project management, email, and maybe an industry tool for real estate, construction, or staffing. None of them talk to each other on their own.
The result is familiar territory. Someone looks up an address in the CRM and retypes it into the accounting software. A project status gets tracked in three tools, and when in doubt, whichever system was updated last wins. For fifteen years, the answer to this problem stayed the same: sync everything into one central platform.
That answer wasn't wrong. Sync exists to save people time on retyping and looking things up, never as a goal in itself. The problem starts the moment a company turns the sync itself into the goal, instead of the underlying issue: people losing time on work a system should handle on its own.
The numbers show how widespread this pattern is. The average organization manages 897 applications, of which only 29% are actually connected (MuleSoft Connectivity Benchmark Report, Salesforce, 2025). For an SME with five to ten systems, that ratio is often even more lopsided: there’s no IT department methodically wiring everything together.
At the same time, AI adoption in Dutch business is growing fast. In 2024, 22.7% of companies with ten or more employees used at least one AI technology, up almost nine percentage points from 2023 (CBS, AI Monitor 2024). That growth is fundamentally changing the business case behind syncing.
That’s also why the reflex of “we just need to integrate everything” often asks the wrong question. The real question isn’t how you wire everything together, it’s which part of your data needs a fixed home and which part can stay right where it is until someone, or something, asks for it.
Sync was always a means to make people more efficient, never the goal itself. Once an AI agent can pull data on its own the moment it needs it, most of the reason to gather everything in one place beforehand disappears.
What this reflex also hides is the price of the connections themselves. Every direct link between two systems needs maintenance the moment either one gets an update, a field name changes, or a vendor ships a new API version. With two systems, that’s manageable. With six, the number of possible connections grows faster than most SME teams realize, and maintenance nobody explicitly budgeted for quietly becomes the biggest cost in your system landscape.
If you want your systems to work together better, there are in practice three routes. They aren’t equal options side by side: it’s more of a funnel, from the familiar but expensive route, through a heavier middle step, to the route we recommend for most SMEs, provided the downsides are consciously covered.
This is the route most companies know, because software vendors actively recommend it. Every new connection costs fresh build and maintenance time, and you lock yourself into whichever vendor happens to have “AI” on its feature list.
A data warehouse is the professional solution for companies that already know exactly which questions they want to ask their data structurally. For an SME still figuring out which process costs the most time, this is rarely the first move. It’s step three, not step one. IBM describes this kind of middle layer as a way to decouple systems so they can change independently of each other (IBM, 2025), exactly the role Route B plays.
In this route, an agentic AI system gets access to your source systems directly, and pulls the requested data at the moment of the question via tool calling. That usually happens through the Model Context Protocol (MCP), an open standard for connecting AI systems to external tools and data sources, now housed at the Linux Foundation so no single vendor owns the standard (Anthropic, 2025).
For an SME, that last point isn’t a footnote. An open standard means a connection you build this year on one AI model keeps working with a different model next year, without having to renegotiate the terms of that connection with a single vendor.
That’s why our SaaS integration approach starts by exploring exactly this route, because it usually delivers a working first result fastest. That doesn’t mean it’s without downsides.
AI agents that decide which tool to call based on a language model are, by definition, not fully predictable. An AI agent that calls tools on its own is, at its core, a language model acting repeatedly based on feedback from its environment (Anthropic, 2024), and that calls for deliberately designed boundaries instead of blind trust.
Say an agent checks inventory, scheduling, and the CRM live for every customer question, and combines the answers: that’s the kind of scale advantage Route C is aiming for, not as a replacement for people but as a multiplier on access to information. The moment an agent combines several sources at once into one coherent answer, we call that orchestration. That only works reliably with a human-in-the-loop step at the point where an answer touches a decision with real consequences, not as a loose suggestion after the fact.
Not every sync is a mistake. There are at least three situations where Route A or Route B remains the right choice, even if you’re already using AI agents elsewhere.
First: high-frequency or high-volume workloads, like a webshop processing thousands of orders an hour. Pulling live from the source adds latency and per-call costs that a pre-synced data flow doesn’t have.
Second: data ownership and continuity. Do you need to guarantee historical data stays intact, even if a vendor shuts down or an API contract changes? Then you want your own copy of that data, not just a live connection to a system you don’t control.
Third: proven, stable data flows that have run trouble-free for years. Replacing a connection that works, purely because a newer approach exists, is risk without reward.
Meanwhile, the integration platform (iPaaS) market keeps growing undiminished: global market size was estimated at 15.63 billion dollars in 2025, with expected annual growth of 24.2% through 2034 (Fortune Business Insights, 2025). Companies are still investing heavily in classic integration, alongside agentic AI, not instead of it.
Sync isn’t disappearing, it’s becoming a deliberate choice instead of a reflex. The question is no longer “do we sync”, but “which part of our data deserves a fixed copy, and which part can be pulled live”.
Once you want to put AI to work alongside your existing systems, there’s a second choice separate from the three routes above: do you rent AI as part of your existing platform, or build your own AI layer?
The cost structure differs too. Platform AI is usually billed per user per month, a fixed amount that scales with headcount regardless of how much that AI actually gets used. Your own AI layer is billed per task completed or per process, which often works out cheaper for a small team once you’re past the build cost.
This choice isn’t just technical, it’s strategic. Research from MIT’s NANDA initiative, cited by Fortune, shows that working with specialized AI partners succeeds roughly twice as often as a fully in-house build (Fortune, August 2025). That’s not an argument against owning your AI layer, it’s an argument against reinventing the wheel on your own.
Want to understand why platform AI structurally stalls the moment you step outside the vendor’s own ecosystem? Read our analysis of the fundamental limits of AI agents inside legacy SaaS.
Platform AI is fast, but ends where the platform ends. Your own AI layer costs more upfront, but doesn’t end anywhere.
Your own AI layer isn’t an upgrade that makes sense for every company. It’s only the right choice under one condition: you have the ambition to build AI as a capability of your own inside your organization, not as a bolt-on extra on top of existing software.
If you don’t have that ambition, platform AI is often simply the smarter answer. There’s nothing wrong with Microsoft 365 Copilot or Agentforce if you mainly want AI to do existing tasks faster, without building a team of your own to maintain that layer.
Not sure whether your system landscape is even ready for an integration project, separate from the AI choice? First read when you need systems integration consulting (and when you don’t), that decision framework stands apart from everything above.
Does the ERP-specific pain point sound more familiar, retyping between an industry platform and the rest of your systems? Then ERP integration without copy-paste is the more specific entry point for that one process.
We call a fully connected system landscape an AI agent can rely on an AI business brain: not a goal in itself, but the foundation the next step, whether that’s a digital worker or a new process, can keep standing on.
The right question isn’t “can we build this”, it’s “do we want to own AI as a capability, or would we rather rent what someone else has already built”. Both answers are valid, as long as you choose deliberately instead of drifting into a route by accident.
Because it was the only practical way to make data from multiple systems usable in one place. Sync saved people time they’d otherwise lose to retyping and looking things up. The problem isn’t sync itself, it’s that for many companies it became the goal instead of the means.
With syncing, you copy data to a central place in advance, so it’s always ready but can also go stale. An AI agent that pulls live from the source only requests the data the moment it needs it, via tool calling. That saves on maintenance, but it does make you dependent on the source’s own availability.
Upfront, usually yes: you’re building connections and governance that an off-the-shelf platform already includes. Long-term, it depends on how many systems you want to connect and how much ownership and independence matter to you. Platform AI is cheaper to start, your own AI layer is cheaper to scale. For your own AI layer, also count the time it takes to set up governance and oversight: that’s part of the build cost, not a separate line item added later.
With high-frequency or high-volume workloads where latency and per-call costs start to bite, with data you want to keep permanently under your own control, and with data flows that have run stable and proven for years. In those three cases, a fixed connection is still the smartest choice.
The result is non-deterministic: the same question can get a slightly different answer each time. Freshness depends entirely on the source itself, every run costs money, and you need to think about governance and oversight from day one, not only once something goes wrong. That’s why Route C works best on processes where a slightly differently worded answer does no harm, and less well on processes where one wrong number immediately hits an invoice or a contract.
MCP stands for Model Context Protocol, an open standard for connecting AI systems to external tools and data sources. Because the standard is now housed at the Linux Foundation, no single software vendor owns it alone. That means a connection you build today keeps working with a different AI model tomorrow.
Usually faster than Route A or B, because you don’t have to set up sync before you can test anything. A first working example on one process is achievable within a few weeks. Scaling up to multiple processes and systems does then call for deliberate governance.
For companies without the ambition to build and maintain AI as a capability of their own. If you mainly want AI to do existing tasks faster, without putting a team on it, platform AI like Copilot or Agentforce is usually the smarter and faster route.
Your own AI layer isn’t a big bang and isn’t a vendor gamble. Start with one process, prove it in weeks, and build further on a foundation that holds.
See Business Apps & Integrations
.svg){kind=icon}