Your ERP isn't going anywhere. Put the agent in front of it.
The software that holds your orders, invoices and stock is getting an AI layer whether its vendor ships one or not. The useful move is to build that layer yourself, in front of the system you already trust.
What happened
IT Jungle's Alex Woodie asked this summer whether AI marks the end of the ERP era. The question has money behind it. Early in 2026 a sell-off the press called the "SaaSpocalypse" took hundreds of billions of dollars off business software makers, on the fear that companies would start building their own software with AI coding tools.
Woodie works through a McKinsey analysis of five ways AI could hit the ERP market. In the extreme version, agents replace ERP outright. The version McKinsey and Woodie both find more plausible keeps the ERP as the place where business rules are enforced and records are kept, and changes who touches it. In McKinsey's words, "users won't directly interact with them." People set intent, check outcomes and deal with exceptions. Agents handle the transactions.
Why this matters to your business
Watch your support team for an hour and a lot of what they do is ERP work in disguise. Where is my order. Why was I charged twice. When does my refund land. Is this in stock at the other warehouse. Each answer sits in the ERP, and the person on the call gets it by opening a second screen, searching, reading a status code and turning it into a sentence.
That translation is where the time and the mistakes go. Every lookup adds handle time, and a new hire needs weeks to learn which of three date fields is the one a customer means. Waiting for your ERP vendor to fix it puts you on their roadmap, their pricing and their idea of what your customers ask. Replacing the ERP, the extreme scenario, is a multi-year bet that most businesses cannot afford to lose.
Why this is a CX-Builder use case
The plausible future McKinsey describes can be built today without touching the ERP. An agent sits in front of the system of record. It reads through the same interfaces your other software already uses, answers the customer from the actual record, and leaves the business rules where they live. The ERP stays the authority, and the agent is the part that talks.
Changes are where you slow down. A credit, a reshipment, an address change after dispatch: the agent can prepare each one, and a human-in-the-loop step holds it for a person to approve before it reaches the ERP. The ERP's own validation still runs on anything that gets through, so every change passes two checks, one for judgement and one for rules.
The McKinsey piece also describes a "semantic layer" holding business context that the database schema leaves out. In plain terms that is what your senior people carry in their heads: that status 40 means packed but not collected, or that the promise date matters more than the ship date when a customer asks. Write it down once and put it in a document store the agent retrieves from. Every conversation then uses it, and your new hires can read the same page.
What this looks like if you build it
It is one agentflow with tools pointed at the ERP's read endpoints, through an HTTP tool, a custom tool, or an MCP server that fronts the system. A retrieval step pulls from the glossary of field meanings and policies. Any proposed change comes out as structured output, so a condition can route it: small and routine goes straight through, anything above a threshold waits at an approval node. It runs self-hosted, so the ERP credentials stay inside your network.
Start read-only. An agent that answers "where is my order" correctly and never changes a thing is already worth running, and its logs tell you which changes are worth adding next.
The takeaway
For one week, have your support team tag every ticket they answer by looking something up in the ERP. The five most common tags are your first agent's job description. Build it read-only, measure handle time on those tickets, and add changes behind an approval gate only once the answers are right.