You do not need to replace your ERP to use AI agents. You need the agents to talk to it. Two open standards now make that possible - and this is what they are, in plain terms, and how to use them without opening a hole in your business.
Across this series we have described agents doing real work: pulling stock across brands, matching invoices, reconciling the ledger, coordinating a disruption. Two practical questions have been sitting underneath all of it. How does an agent reach into SAP or your data warehouse to do any of that? And how do several agents work together without someone hand-wiring every connection?
For most of the last few years there was no standard answer, so every connection was a bespoke, brittle integration. In 2026 there are two open standards that answer those questions directly. If you have heard “MCP” mentioned in a vendor conversation - or raised by your own architects - this is the plain-English version.
The problem they solve
Picture an agent that needs to read an order from SAP, check stock in your warehouse system, and post an update back. Without a standard, each of those links is a custom piece of integration, built and maintained by hand. Multiply that by dozens of agents and dozens of systems and you have a tangle of one-off connections that no one can secure or keep track of.
The two standards below turn that tangle into something closer to a set of standard sockets.
MCP: how an agent reaches into a system
The Model Context Protocol - MCP - is the standard for how an AI agent connects to a tool, a data source or a system. It has been nicknamed “the USB-C of AI”, and the analogy is a fair one: instead of a different custom cable for every device, one standard connector fits them all.
In practice, a small piece of software called an MCP server sits in front of a system - your ERP, a database, a document store - and exposes, in a standard way, what an agent is allowed to do with it: read this, look up that, post the other. The agent needs no bespoke code for each system; it speaks MCP, and the server translates.
MCP was introduced by Anthropic and has since been adopted by every major AI provider, including OpenAI, Google and Microsoft. That matters: when the whole industry agrees on one connector, it stops being a bet on a single vendor and becomes infrastructure. It is already among the most widely used standards of its kind.
A2A: how agents work together
MCP handles an agent reaching down into a system. It does not handle agents talking to each other - and the workflows earlier in this series needed exactly that: an availability agent, a credit agent and a logistics agent coordinating on the same order.
That is what the Agent-to-Agent protocol - A2A - is for. Each agent publishes a short description of what it can do (an “Agent Card”), and other agents can discover it and hand it a task. A2A came from Google and has been placed under the Linux Foundation, which means that, like MCP, it is an open standard rather than one company’s property. It works across vendors, so an agent built on Google Cloud and one built in SAP can cooperate without custom glue.
MCP is how an agent reaches into a system. A2A is how agents reach each other. Neither replaces anything you already run.
The simplest way to hold the two apart:

Why this matters for a business on SAP and Google Cloud
Here is the part that matters for an estate like yours. Both SAP and Google Cloud now support these standards. That is precisely what makes “build around the ERP, don’t replace it” a real option rather than a slogan: an agent reaches into SAP through MCP, agents coordinate through A2A, and nothing gets ripped out or migrated.
It also protects you from lock-in. Because the protocols are open and cross-vendor, you are not committing your whole agent strategy to a single supplier’s roadmap. You can use SAP’s agents where they fit, Google’s where they fit, and your own where neither does - and have them work together. As always, confirm which specific capabilities are generally available and which are still in preview before you plan around them.
The question your IT director will ask: is it safe?
It is the right question, and the honest answer is that it can be, if it is done properly - and it is a real risk if it is not.
The early versions of these connections were loose about authentication. The current standards are not: they use proper, token-based authentication and scoped, least-privilege access, so an agent can be given permission to do exactly one thing and nothing more. The known attack patterns are understood - for example, tricking an agent through a poisoned tool description, or slipping instructions into data the agent reads - and so are the defences.
In practice the sensible pattern is: read-only access by default, permissions scoped tightly to the job, every action validated, and an MCP gateway placed in front of your systems to enforce those rules centrally and log everything. That gateway is, in effect, the same control plane we described in the last article - the single point where the digital workforce is governed.
Human confirmation is part of the plumbing
One reassuring detail. Keeping a human in the loop is not something you have to bolt on afterwards; it is built into the protocol. An MCP server can pause and ask a person to confirm before a high-risk step - approve this payment, commit this change - exactly the checkpoints the function articles in this series relied on. The standard is designed to keep a human in the loop where it matters.
The groundwork that makes the rest real
MCP and A2A are not the interesting part of an AI programme. The redesigned processes are. But they are the plumbing that makes those redesigns buildable on the systems you already own - safely, and without tying you to one vendor.
Getting the interfaces and the guardrails right around your ERP is unglamorous groundwork. It is also what turns the ideas in this series into something that runs in production rather than a slide. If that is the layer you are working through now, it is exactly where we would help you start.


.png)
.png)
.png)



