Every large enterprise runs on an ERP that was built before AI existed. These systems have been running for a decade or more, customised heavily over time, and are deeply embedded in how the business operates day to day. They are not going anywhere. The investment in them is too large, the operational dependency too deep, and the migration risk too high.
So the question is never whether to replace them. The question is how to make AI work alongside them, reading from them, acting on what they contain, and feeding decisions back into them, without destabilising the foundation the business already runs on.
That question has a specific answer. This piece covers it.
Why ERP Integration Is Where Most AI Projects Stall
An AI system is only as useful as the data it can access and the actions it can trigger. In a manufacturing enterprise, the data that matters — purchase orders, production schedules, inventory positions, supplier performance records, customer transactions — lives inside the ERP. And the actions that matter — raising a purchase order, updating a delivery status, triggering a workflow approval — have to be written back into the ERP to have any operational effect.
This sounds straightforward until you are actually inside the system.
Enterprise ERPs that have been live for a decade or more are rarely the clean, well-documented systems their original architecture diagrams suggest. They accumulate customisations, workarounds, and data structures that were added to solve specific problems at specific points in time, documented somewhere that nobody can find, and depended upon by processes that nobody has fully mapped.
An AI system that connects to this environment through a generic API and assumes the data it receives is clean, consistent, and complete will fail in ways that are difficult to diagnose and expensive to fix. Not because the AI is wrong, but because the environment it is reading from is more complicated than any external team can understand without being inside it.
This is precisely why forward deployed engineers working inside the client's actual ERP environment consistently outperform remote teams building against API documentation. The customisations, the data quality gaps, and the undocumented dependencies surface in the first two weeks of an embedded engagement. They surface in month four of a remote one.
The Three-Layer Architecture That Actually Works
The architecture that reliably allows AI to work with legacy ERP without replacing or destabilising it has three distinct layers, each with a specific job.
Layer 1 — The system of record
This is the ERP. It holds the transactions, the master data, the history. It is not going anywhere and it does not need to. Its job is to remain the authoritative source of operational truth.
The key principle here is that the AI layer should never write directly to the ERP without a governed interface. Every action the AI takes that needs to be reflected in the ERP — a purchase order raised, an inventory adjustment made, a workflow triggered — goes through a defined, audited pathway. Not a direct connection that bypasses the business logic the ERP was configured to enforce.
Layer 2 — The data and orchestration layer
This is the layer that most enterprises either underinvest in or skip entirely, and it is where most AI deployments fail at the integration boundary.
The data and orchestration layer sits between the ERP and the AI. Its job is to extract data from the ERP in the form the AI can use, clean and contextualise it, enrich it with data from other operational systems — manufacturing execution, field service, logistics platforms, dealer management systems — and make it available to AI agents in real time rather than in batch.
This layer also carries the business rules, approval hierarchies, and operational constraints that define how the enterprise actually works. An AI agent deciding whether to approve a purchase order needs to know the current budget position, the approval threshold for this category of spend, and whether the supplier is on the approved vendor list. That context does not live in the ERP in a form the AI can easily consume. The orchestration layer structures it and makes it available.
Without this layer, AI is operating on incomplete context. With it, AI is operating on a real-time picture of the business that is richer than what any human analyst could assemble manually.
Layer 3 — The AI layer
This is where the reasoning happens. AI agents monitor signals from the data layer, reason through situations using the business context the orchestration layer provides, decide what to do, and act either by triggering an action in an operational system or by surfacing a recommendation to a human decision-maker.
The AI layer is what most enterprise AI discussions focus on. It is actually the least complex part of the architecture to get right in 2026, because model capability is strong across the board. The complexity is in the two layers beneath it.
What This Looks Like in a Manufacturing Context
Take a supply chain disruption scenario in an automotive manufacturing environment.
A tier-two supplier's on-time delivery rate drops. In a traditional setup, this surfaces in a weekly report that a procurement analyst reviews, escalates to a category manager, who schedules a supplier review meeting, which happens ten days later.
In an AI-integrated environment with the three-layer architecture in place, the data layer is monitoring supplier performance signals continuously, pulling delivery data from the ERP and logistics platforms in real time. When the threshold is breached, an AI agent retrieves the supplier's contract terms from the document repository, checks the approved vendor list for alternatives, models the inventory impact of a potential switch, and surfaces a decision-ready recommendation to the procurement manager — before the weekly report has been generated.
The ERP is not replaced. The procurement manager is not replaced. The AI has done the monitoring, the data retrieval, the analysis, and the recommendation generation that would otherwise have taken days of manual work. The human makes the decision. The action gets written back to the ERP through the governed interface.
This is what AI layered on top of legacy ERP actually looks like in supply chain operations. Not a new system replacing an old one. An intelligence layer that makes the existing system faster, more responsive, and more capable of acting on what it already knows.
ERP-Specific Considerations Every Enterprise Needs to Address
A few factors come up consistently across ERP integrations in large manufacturing environments, regardless of which platform is in use.
The ERP's own AI capabilities are real but limited in scope. Most major ERP vendors have been embedding AI features across their product suites, and some of these are genuinely useful for specific, well-contained use cases within the ERP environment. Their limitation is that they operate within the ERP's own data and workflow boundaries. They do not extend to the broader operational data that lives outside the ERP — in manufacturing execution systems, dealer platforms, field service tools, and logistics networks — which is precisely where the most valuable cross-functional AI use cases sit.
The integration layer requires domain expertise, not just technical skill. Enterprise ERPs expose data through APIs and integration frameworks that allow external systems to read and write to the core system. These work well for teams that understand how the ERP data is structured, where the customisations live, and which integration patterns are reliable versus which ones create performance problems under load. Teams that lack this expertise routinely underestimate the integration complexity until they are already inside it.
Master data quality is the most common constraint. Vendor master data, material master data, and customer master data in most enterprise ERP implementations have accumulated inconsistencies over years of manual entry, system migrations, and organisational changes. AI systems that operate on this data produce unreliable outputs until the master data quality issues are resolved. Resolving them is unglamorous work. It is also the prerequisite for almost every AI use case that depends on ERP data.
What to Prioritise Before the AI Build Starts
Three preparation steps consistently shorten the path from AI initiative to production deployment in ERP-dependent environments.
Map the data flows you actually depend on, not the ones in the architecture diagram. Every enterprise has an official data architecture and an actual one. The actual one has workarounds, manual steps, and informal data sources that the official diagram does not show. The AI system needs to work with the actual one.
Identify the write-back requirements early. Knowing which AI actions need to be reflected in the ERP, and through which integration pathway, before the build starts prevents the most expensive category of late-stage rework. An AI agent that generates a purchase order recommendation but cannot write it back to the ERP in the right format has only done half the job.
Decide on the master data remediation scope upfront. Not all master data problems need to be fixed before AI deployment. Some can be worked around in the orchestration layer. Others are blockers that will prevent reliable AI outputs regardless of model quality. Knowing which is which before the engagement starts is more valuable than discovering it at week eight.
AI works with legacy ERP by sitting above it, not replacing it. The architecture that makes this reliable — a governed integration layer, a data and orchestration layer that contextualises what the ERP contains, and an AI layer that reasons and acts on that context — is well understood and deployable today.
What makes it work in practice is the depth of integration expertise applied during deployment. The ERP customisations, the data quality gaps, and the write-back requirements that only become visible inside the actual environment are exactly what forward deployed engineers embedded in the client's systems are structured to discover and solve. Remote teams building against API documentation discover them later, at greater cost, with greater disruption to the deployment timeline.
The architecture is not the hard part. Understanding the specific environment you are deploying into is.
Vishleshan AI layers AI on top of existing ERP and legacy systems without replacing them. Our forward deployed engineers work inside your environment until it is genuinely in production. Book a Consultation