Connecting AI Agents to Legacy Manufacturing Systems
How to connect AI agents to legacy systems — green-screen ERP, no API, dirty data. A plant operator's playbook for getting value without a rip-and-replace.
You connect AI agents to legacy manufacturing systems by wrapping them, not replacing them. Give the agent a clean way to read the old system — a read-only database connection, the files the system already exports, or a standards-based protocol like MTConnect or OPC UA — then stage that data in a modern layer the agent queries instead of hitting the legacy box directly. You do not need to modernize your ERP first, and waiting until you do is the most common way these projects die.
Every vendor demo assumes you're running something modern with a clean REST API. Your plant isn't. You're running a 1990s ERP with a green-screen front end, a homegrown scheduling tool a guy named Dave wrote in 2008, and an MES that exports to CSV when it feels like it.
I ran AI at a $250M furniture manufacturer with exactly this stack. The good news: you don't need to replace any of it to get value. You need to meet it where it is.
Why "modernize first" is the wrong order
The instinct from IT is usually "we can't do AI until we modernize the ERP." That's a five-year, seven-figure project. And it's backwards.
The scale of the legacy problem is real. McKinsey reports that 70% of the software running Fortune 500 companies was built 20 or more years ago (2024), and rip-and-replace modernization can take hundreds of engineers and multiple years. If AI value waits on that, operations sees nothing for years.
There's a sharper warning underneath this. An MIT NANDA study found that 95% of enterprise generative AI pilots deliver no measurable P&L impact (2025), and the root cause wasn't model quality — it was flawed enterprise integration. The systems-connection problem is the project. I dig into the broader version of this in the AI pilot-to-production gap.
Agents can wrap legacy systems today. The only real questions are which wrapping method fits your constraint, and how you handle the data that comes out the other side.
Find your access door first
Before you scope a single agent, answer one question: how can software read this system without a human typing? There are four doors, and most legacy environments have at least one open.
| Access door | What it needs | Reliability | Use when |
|---|---|---|---|
| Database read access | Read credentials to the underlying DB | High | The ERP sits on SQL Server/Oracle/DB2 you can query |
| File/EDI exports | Scheduled CSV, flat-file, or EDI drops | High | The system already exports on a schedule |
| Standards protocol | MTConnect / OPC UA endpoint | Medium-High | Shop-floor machines or a modernized MES expose it |
| Legacy API / SOAP | An old but real web service | Medium | Vendor shipped SOAP/XML endpoints |
| Screen scraping / RPA | Terminal or UI automation | Low | None of the above exists |
The database is usually already there
Most "impossible" legacy ERPs are sitting on a perfectly queryable database. The green screen is just a front end. If your IT team can hand you read-only DB credentials, you're 80% of the way to a working agent, no modernization required.
We ran several agents this way. The front end stayed exactly as ancient as before, and the agent read straight from the tables underneath. Read-only is the rule — the agent observes, it never writes back to the system of record.
Files and EDI are boring and bulletproof
If the database is locked down, fall back to whatever the system already exports. Manufacturing systems are export machines — nightly batch files, EDI 856 advance ship notices, scheduled reports.
An agent that ingests the same file your accounting team already gets is boring, reliable, and ships in a week. Nobody has to touch the legacy system at all.
Standards protocols when the data is on the floor
For shop-floor equipment, there are real interoperability standards worth knowing. MTConnect, paired with the OPC UA Companion Specification (2024), gives machine data a structured, non-proprietary vocabulary, and NIST has tested the bridge between the two (2020).
At the enterprise-to-control layer, ISA-95 / IEC 62264 (2024) defines how ERP and MES are supposed to exchange information. If your stack already speaks any of these, the agent has a documented door instead of a custom hack. More on the broader picture in integrating AI agents with your ERP and MES.
The data lake pattern beats live integration
For legacy systems specifically, don't make the agent query the old system in real time. Stage the data instead.
The pattern: pull from the legacy system on a schedule into a modern staging layer — a cloud database, a data warehouse, even a well-organized set of tables. The agent reads the staging layer, never the legacy system directly.
This buys you three things:
- You don't load the old box. A 20-year-old ERP doesn't appreciate an agent hammering it with queries. The staging layer absorbs that.
- You clean once, read many. Transformation and cleanup happen in the pipeline, so the agent sees consistent data instead of legacy quirks.
- You decouple the agent from the source. When you eventually modernize, you swap what feeds the staging layer and the agent never notices. You re-point one pipe.
What about latency?
Latency is the trade. A nightly or hourly refresh means the agent isn't truly live.
For 90% of legacy use cases — supplier-doc lookup, order-status Q&A, planning questions, ops-review prep — yesterday's data or last-hour's data is completely fine. Reserve real-time integration for the rare case that genuinely needs it, like an agent reacting to a line stoppage as it happens.
Your data is dirty. Plan for it.
The real obstacle with legacy systems isn't access. It's data quality.
This is not a soft concern. Gartner reports that poor data quality and the lack of AI-ready data put the majority of AI projects at risk, and predicts organizations will abandon 60% of AI projects unsupported by AI-ready data through 2026 (2025). McKinsey's survey of high performers found that 70% report difficulties with data — governance, integration, and quality (2024).
Legacy systems accumulate decades of inconsistency: three spellings of the same supplier, units that switch between each and case mid-table, part numbers with trailing spaces, free-text fields where structure should be. An agent fed this data confidently produces wrong answers. That kills trust faster than anything — one bad answer in front of a skeptical plant manager can end the whole initiative.
Fix it in the pipeline, not the prompt
- Normalize entities. Map the three spellings of "Acme Steel" to one. Standardize units, dates, and part formats in the staging layer.
- Flag low-confidence data. When a field is ambiguous, the agent says so — "I found two records that might match, here are both" — instead of guessing.
- Scope to the clean subset first. Don't try to cover every record. Pick the cleanest domain — active suppliers, current open orders — and build the first agent there. Expand as you clean.
Messy data isn't a reason not to start. It's a reason to start narrow. Run a data readiness check for AI before you scope, and you'll know exactly which domain is safe to ship against.
Match the agent to the legacy constraint
Not every agent fits every legacy stack. Match the use case to what your access door supports.
| Access door | Agents that fit | Why |
|---|---|---|
| DB read access, decent data | Order-status exception lookup, supplier-doc intelligence, demand/inventory Q&A | High-frequency lookups that replace screen-chasing |
| File/EDI exports only | Ops-review prep, exception reporting | Batch-tolerant, runs off data you already export |
| Standards protocol (MTConnect/OPC UA) | Machine-status summaries, downtime analysis | Structured shop-floor data with a real schema |
| Screen scraping only | One narrow read-only lookup, human-verified | RPA on a legacy UI is fragile; keep it tiny |
The mistake is building something mission-critical on the fragile door. Don't run a production-scheduling agent off screen scraping. Save the brittle access path for low-stakes, read-only convenience and put the real workload on the database or file feed.
Build in governance from day one
An agent reading your ERP touches sensitive operational and supplier data. Wire the guardrails in at the start, not after a near-miss.
The NIST AI Risk Management Framework (2023) gives a sector-neutral structure — Govern, Map, Measure, Manage — that fits this cleanly. In practice for a legacy wrap that means: read-only credentials scoped to specific tables, an audit log of every query the agent runs, and human-in-the-loop verification on anything that informs a real decision.
Keep the agent's access surface as small as the use case allows. A supplier-doc agent has no business reading payroll tables. More on the threat side in AI agent security risks manufacturers must manage.
Why this beats waiting for modernization
The modernization-first path has a hidden cost: you spend two years and a lot of money before anyone in operations sees a single benefit. By then the AI landscape has moved, the budget is exhausted, and the agents are still hypothetical.
Wrapping legacy systems flips the order:
- Ship a working agent in 30 days against the stack you have.
- Put a number on the board — hours saved, errors caught.
- Fund the next one with proof instead of a promise.
When modernization eventually happens, your agents are already built against a staging layer that doesn't care what's underneath. You re-point one pipe and move on. That's the same sequencing logic behind AI agent implementation in 90 days.
The legacy system isn't the blocker everyone treats it as. It's a constraint to design around, and the design is well-understood.
Frequently asked questions
Do I need to replace my legacy ERP before deploying AI agents?
No. AI agents can wrap a legacy ERP today by reading from its underlying database, ingesting the files it already exports, or using a standards protocol like OPC UA. Modernization is a multi-year, seven-figure project, and waiting on it means operations sees no AI value for years while the budget and momentum drain away.
What's the most reliable way to connect an agent to an old system?
Read-only database access is the most reliable door when it's available, because the green-screen front end usually sits on a perfectly queryable SQL Server, Oracle, or DB2 database. If the database is locked down, the next most reliable option is ingesting scheduled file or EDI exports the system already produces. Screen scraping is the last resort and should only be used for tiny, read-only, human-verified lookups.
Should the agent query the legacy system in real time?
Usually not. The recommended pattern is to pull legacy data on a schedule into a modern staging layer and have the agent read that layer instead, which protects the old system from query load and lets you clean data once. For most use cases — order-status Q&A, supplier-doc lookup, ops-review prep — hourly or nightly data is completely adequate, so reserve real-time integration for the rare case that truly needs it.
How do I handle dirty data in a legacy system?
Fix it in the data pipeline, not in the prompt. Normalize entity names and units in the staging layer, have the agent flag low-confidence or ambiguous records instead of guessing, and scope your first agent to the cleanest data domain you have, such as active suppliers or current open orders. Gartner attributes most at-risk AI projects to poor or non-AI-ready data, so this step is what keeps the project alive.
What manufacturing standards help connect AI agents to plant systems?
MTConnect and OPC UA, joined by the OPC UA Companion Specification, give shop-floor machine data a structured, non-proprietary vocabulary, and NIST has published testing for that bridge. At the enterprise-to-control layer, ISA-95 / IEC 62264 defines how ERP and MES systems should exchange information. If your stack already speaks any of these, the agent gets a documented, standards-based door instead of a custom integration.
Let's see what's worth building first.
A 15-minute call: tell me where your AI or planning is stuck, and I'll tell you the one thing worth building first — and whether it's worth doing at all.