AI Integration: Connecting AI to the Systems You Own
TL;DR: AI integration is not a model problem. Every serious deployment ends up at the same four connection surfaces — MCP, direct API, an integration platform, or a browser/RPA step on the screen itself — and the choice between them is decided by what the target system exposes, not by what your AI vendor prefers. The work that actually consumes the project is credential scoping, error handling and reconciliation. Budget for that and integrations get boring, which is the goal.
The failure is at the seam
Gartner expects 40 percent of enterprise applications to ship task-specific AI agents by the end of 2026, up from under 5 percent in 2025. The same analysts expect over 40 percent of agentic projects to be cancelled by 2027.
Both numbers can be true because they describe different things. Agents are easy to demo and hard to connect. A pilot that summarises pasted text needs no integration at all; the moment it has to read the actual purchase order, write to the actual ERP and not do it twice, you are building an integration project with an AI component rather than an AI project.
That is the honest reframing. Nearly every "our AI pilot stalled" story is an integration story wearing a different hat — the same pattern we broke down in why AI agent pilots die before production.
The four surfaces, and nothing else
Strip away vendor naming and there are exactly four ways software reaches another system. AI does not add a fifth.
| Surface | What it is | Best when | Real cost |
|---|---|---|---|
| MCP server | A standard tool interface the agent discovers at runtime | Multiple agents need multiple systems | Auth setup; server may not exist yet |
| Direct API | Code you write against a documented endpoint | One system, one well-defined job, high volume | You own auth refresh, retries, schema drift forever |
| Integration platform | A hosted connector library (n8n, Zapier, Make, iPaaS) | Connector already exists and the flow is linear | Per-run pricing; brittle when logic branches |
| Browser / RPA step | Software operating the screen a human would | No API exists, and none is coming | Breaks on UI change; slowest and most fragile |
Most real deployments use three of the four at once. A modern CRM over MCP, a legacy ERP over nightly export plus a screen-entry step, an internal service over its own API. Anyone telling you a single surface covers the whole estate has not seen the estate.
Why MCP changed the arithmetic
Before MCP, integration cost scaled by multiplication. Five systems and three agents meant fifteen integrations, each with its own auth, its own error handling and its own owner. Add a fourth agent and you write five more.
MCP turns that into addition. Each system exposes one server; each agent runs one client. Five plus three is eight, and the fourth agent costs one client, not five integrations. That is the entire argument, and it is a strong one at any scale beyond a single pilot.
It is also no longer a bet on one vendor. Anthropic donated MCP to the Agentic AI Foundation in December 2025 — a directed fund under the Linux Foundation, co-founded with Block and OpenAI, with support from Google, Microsoft, AWS and Cloudflare. Monthly SDK downloads went from around 2 million at launch to over 97 million by March 2026, with more than 10,000 servers published. OpenAI deprecated its proprietary Assistants API in favour of the standard.
The practical consequence for a buyer: an integration you build as an MCP server outlives your current model choice, and probably your current platform choice. If you want the mechanics rather than the market context, start with what MCP is in plain English.
The honest limit: MCP describes how to expose a tool, not whether someone has. For your 2011 on-premise ERP, nobody has. Which brings us to the part the "complete guide to AI integration" posts skip.
When the system has no API
This is the question that actually decides project scope, and it has a settled answer. Four bridges, in descending order of preference:
- Database read access. Usually available, usually low-risk, immediately useful. Reads answer most questions.
- Scheduled file export/import. The oldest integration in the building and often the most reliable. Fine when the process is already batch-shaped.
- A supported write channel. An import routine, an EDI endpoint, a vendor utility. Slower than writing to tables directly, and it keeps the application's business logic intact.
- Screen automation for the last mile. The agent does the reading and judgment; a scripted step performs the final entry.
Writing straight to a legacy database bypasses validation the application depends on and is where these projects get expensive. The full breakdown, including what each bridge costs, is in your 2009 ERP can still talk to AI.
Worth being precise about the fourth bridge, because it is where AI integration is most often oversold. A screen-driving step is RPA, and it has RPA's failure mode: it breaks when the UI moves. The difference in 2026 is that the fragile part is now a thin last mile rather than the whole workflow, because the understanding happens upstream. That distinction is the whole of AI agents vs RPA, and it matters for how you staff the maintenance.
The work nobody quotes for
Connecting is a day. The following is the project.
Credential scope. The default path is one service account with broad rights, because that is what makes the demo work on Friday. It then ships. Every agent action now runs with those rights, and your audit log says "integration user" for all of it. Scope per tool, not per system: an agent that reads invoices does not need write access to the vendor master.
Idempotency. Agents retry. Networks time out after the write succeeded. Without an idempotency key or a pre-write existence check, "the invoice was posted twice" is not an edge case, it is a Tuesday.
Rate limits and cost. An agent that decides to enumerate a 40,000-row table because it seemed relevant will find your API quota and your token budget in the same minute. Bound the tools, not just the prompt.
Schema drift. Someone adds a required field to the CRM. The integration built against last quarter's schema fails silently, or worse, writes a default. Fail loudly.
Reconciliation. When two systems disagree, which one is right, and who finds out? Answer this before go-live, not during month-end.
Each of these has a standard fix, and together they are the guardrail set that turns an agent with write access into something an auditor can approve. Anything irreversible or outbound — a payment, an email to a customer — keeps a human on the gate, because the cost asymmetry never changes.
Choosing the surface: a short decision path
Run this per system, not per project.
- Does an MCP server already exist for it? Use it. Check the scopes it requests before you connect it.
- Does it have a documented API? Wrap it as an MCP server rather than calling it directly from agent code — you write the auth once and every future agent inherits it.
- Does an integration platform already have a connector, and is the flow linear? Use the connector. This is where n8n, Zapier and Make genuinely win: known systems, predictable steps, no judgment in the middle.
- Is there a database or an export file? Read from it. Write through a supported channel.
- None of the above? Screen automation, scoped to the last mile, with a human checkpoint on the write.
If step 3 is where most of your systems land but the flows keep growing branches for exceptions, that is the signal you have outgrown a connector tool — the comparison in n8n vs OIDO Studio is about exactly that boundary.
How this works in Oido
Concretely, so you can judge the claim rather than take it.
Oido runs an MCP client with per-organisation server registration, OAuth token storage and runtime tool discovery, so connecting a system means registering a server rather than shipping code. Servers already in use across deployments include Postgres, Slack, GitHub, Notion, Google Drive and Stripe.
Where no server exists, the same tool interface is reachable three other ways: an extension that wraps a bespoke API, document parsing and OCR for the export-file path, and a browser agent for the last-mile screen entry — with the controls that make browser access defensible rather than terrifying.
Two properties matter more than the connector count. Every tool call is scoped per agent and written to an audit log, so "what did it touch" is a query and not an investigation. And because tool access sits at the platform layer rather than inside a model integration, switching or mixing model providers does not require rebuilding a single connection. That separation is the practical form of the argument for treating AI as platform infrastructure rather than a pile of point tools.
The takeaway
Pick systems, not projects. For each one, find the highest surface on the list it actually supports, wrap it once so every future agent reuses it, scope the credential to the job rather than the system, and decide the reconciliation rule before anything writes.
Do that and integration stops being the reason the pilot stalled. It becomes the boring layer underneath, which is exactly what infrastructure is supposed to be.
Want to see which of the four surfaces your stack actually needs? That is the first conversation we have — see how the platform connects.
Frequently asked questions
What does AI integration actually mean?
Connecting an AI model to the systems that hold your work — ERP, CRM, inbox, file storage, ticketing — so it can read real records and take real actions, not just answer questions from memory. The model is the easy part; the integration is the project.
What is the difference between MCP and an API integration?
An API integration is code you write for one system, with the calls decided at build time. MCP is a standard interface a system exposes once, which any agent can discover and call at runtime. With five systems and three agents, direct APIs mean fifteen integrations; MCP means eight — five servers and three clients.
Do I need an API to integrate AI with my ERP?
No. Four surfaces work: MCP, a documented API, an integration platform connector, or a browser or RPA step that operates the screen a person would. Systems with no API are reachable through the last two, plus scheduled file exports for reads.
How long does AI integration take?
For a system with a documented API or an existing MCP server, days. For a legacy system reachable only by file export or screen automation, weeks — and the time goes into permissions, error handling and reconciliation, not into the AI.
What is the biggest risk in AI integration?
Credential scope. Integrations are usually built with one powerful service account because that is the fastest way to get a demo working, and it never gets narrowed. The agent then inherits every permission that account has, with no per-action audit trail.
Should I build integrations myself or use a platform?
Build when the system is genuinely proprietary and the logic is your competitive edge. Use a platform for everything else. The cost of a self-built integration is not the first version, it is the auth refresh, the schema change, the rate limit and the on-call rotation for the next three years.
Is MCP a real standard or a vendor protocol?
It is a real standard now. Anthropic donated MCP to the Agentic AI Foundation, a Linux Foundation directed fund, in December 2025, co-founded with Block and OpenAI and supported by Google, Microsoft, AWS and Cloudflare. SDK downloads went from roughly 2 million a month at launch to over 97 million by March 2026.