Integrating AI Agents With Your ERP and MES

To integrate an AI agent with your ERP and MES, put a thin integration layer between the agent and your systems, start with read-only access against the ERP, and route every write through schema validation, a scoped service account, and a human approval step before commit. Treat your ERP and MES as transactional systems of record, not data sources you point a model at. Read access ships in weeks and can't corrupt anything; write access is a separate maturity level you earn one transaction type at a time.

I ran this at a $250M furniture manufacturer. The model was never the hard part. The hard part is wiring an agent into the system that runs your business and the MES that runs your floor without it making a mess you can't undo.

Why most agent-ERP projects die

Most AI agent ERP projects die in the same place. The demo works against a spreadsheet export, then someone asks how it writes a production order back into the system, and the room goes quiet.

That gap is the whole game. MIT's NANDA initiative studied 300 public deployments and found that about 95% of enterprise generative AI pilots deliver no measurable P&L impact (MIT, 2025). McKinsey puts a finer point on it for our world: nearly two-thirds of industrial companies stay stuck in pilot mode and only about one-third scale AI across the enterprise (McKinsey, 2025). The barrier is almost never the model. It's the integration and governance around it.

Your ERP and MES are not flat data. They have locking, audit trails, and downstream consequences. An agent that reads a stale work order is annoying; an agent that releases the wrong work order to the floor costs real money.

Start with read-only. Always.

The single most common mistake is wiring write access on day one because the demo is more impressive. Don't. Most of the value in the first 90 days comes from read-only agents that answer questions humans currently chase through screens, emails, and reports.

Read-only agents you can ship fast

• Order-status and exception lookup. "Which jobs scheduled this week are short on material?" answered against live ERP data instead of a Tuesday-morning report.
• Supplier and PO intelligence. Lead times, open POs, and receipt history pulled into one answer.
• Ops-review prep. The agent reads ERP plus your BI layer and drafts the weekly exception list: late jobs, margin slips, at-risk orders.

None of these can corrupt your system of record. The worst case is a wrong answer a human catches, not a bad transaction. That asymmetry is the entire reason to start here.

When you do move to write access, you're crossing a real line. Earn it. Prove the agent is reliable on reads, then add write capability one transaction type at a time, each gated by a human approval step before commit. This is the same logic behind human-in-the-loop controls for operations — keep a person on the commit until the data says you don't need one.

The four integration paths, ranked by sanity

There's no single way to connect an agent to an ERP. There are four, and the right one depends on your ERP's age and your appetite for risk.

Path	Best for	Latency	Risk	Effort
Vendor REST/OData API	Modern ERP (S/4HANA, NetSuite, recent Epicor/Infor)	Real-time	Low	Low
Middleware / iPaaS	Multiple systems, existing integration layer	Near real-time	Low–med	Medium
Direct DB read replica	Older ERP, no clean API, read-only use	Real-time read	Med	Medium
RPA / screen automation	Legacy with no API and no DB access	Slow	High	High

When the API path works

The API path is the obvious first choice when it exists. Modern ERPs expose clean, documented endpoints — SAP, for instance, publishes its full S/4HANA OData API catalog on the SAP Business Accelerator Hub (SAP, 2025), and OData is a RESTful standard your agent layer can call directly.

The trap is assuming your ERP's API covers the transaction you need. Many cover master data and orders well, but the specific write you want — rescheduling an operation, adjusting an allocation — isn't exposed. Confirm the exact endpoint exists before you scope the agent, not after.

When to use a read replica

For reads against an older ERP, a read replica of the database beats fighting a thin API. A read replica is a read-only copy that asynchronously mirrors the primary (AWS, 2025), so it gives you full data access in real time with zero write risk by construction.

We ran several read-only agents off a replica precisely because it removed the "what if it writes something wrong" question entirely. The replica physically cannot accept a write.

When you're stuck with RPA

Reserve RPA for the case where there's genuinely no other door. It's brittle, it breaks on UI changes, and it's the integration equivalent of duct tape. Useful duct tape, sometimes. Still duct tape. If most of your stack predates clean APIs, read the deeper playbook on connecting agents to legacy manufacturing systems before you commit.

MES is a different animal

ERP integration is mostly about transactions. MES integration is about timing. Your MES sits closer to the machines, the data moves faster, and a wrong action has a shorter fuse. A bad ERP write you can usually reverse with a correcting entry; a bad MES action can scrap a part before anyone reads the screen.

Three rules for agents touching the MES

• Read MES, act through ERP. Let the agent read production status, downtime, and quality data from the MES, but route any action — reschedule, hold, reallocate — back through ERP or a human, where the controls already live. Don't let an agent command the floor directly in v1.
• Latency is a feature, not a bug. A planning or status agent doesn't need sub-second MES data. A 5-minute read cadence is fine and far safer than a live write loop.
• Respect the ISA-95 boundary. Keep the agent at Levels 3–4 (operations and planning). It has no business issuing Level 1–2 control commands.

Why ISA-95 matters here

ANSI/ISA-95, published internationally as IEC 62264 (ISA, 2025), defines the hierarchy that separates business planning from process control. It builds on the Purdue Reference Model and exists to keep a clean boundary between the systems that decide what to make and the systems that physically make it.

That line predates AI by decades, and it predates it for safety reasons. An agent reasoning over a stale prompt has no place sending a setpoint to a PLC. Keep it on the planning side of the boundary and you inherit every control already built into your DCS and MES.

The integration architecture that holds up

The agents that survive production share a shape. Put a thin integration layer between the agent and your systems — not the agent calling ERP and MES directly. That layer does four jobs.

What the integration layer enforces

• Scopes access. A service account with read-only or narrowly-scoped write permissions, never an admin credential. The agent can only touch what the layer allows.
• Validates writes. Every write passes a schema and business-rule check before it reaches the ERP. Wrong config, impossible date, missing field — caught here, not on the floor.
• Logs everything. Every read and especially every write gets an audit entry: which agent, what, when, with what inputs. When finance asks how a transaction happened, you have the answer.
• Enforces human-in-the-loop. High-stakes writes queue for a one-click approval. The human owns the commit; the agent does the 90% of work that leads up to it.

This is also your security boundary

Scoping permissions isn't optional hygiene — it's the named failure mode. The OWASP Gen AI project ranks Excessive Agency as LLM06 in its 2025 Top 10 for LLM applications (OWASP, 2025), driven by excessive functionality, excessive permissions, and excessive autonomy. The fix it recommends is exactly this layer: minimum necessary tools, least-privilege credentials, and authorization enforced in the downstream system rather than trusted to the model.

If you want the full threat model, the deep dive on AI agent security risks manufacturers must manage maps each OWASP category to a shop-floor scenario. The short version: never hand an agent a credential you wouldn't hand a new contractor on day one.

Prove reliability before you turn on writes

This layer is also where your reliability lives. Before any write-capable agent touches production, run it against real historical cases — actual orders, actual exceptions — and measure accuracy. Evals on your data, not toy prompts.

If it can't hit the bar on last quarter's orders, it isn't ready for this quarter's. Governance frameworks like the NIST AI Risk Management Framework's Measure and Manage functions (NIST, 2023) exist to make this measurement a repeatable discipline rather than a vibe check.

Run it like production, not a demo

Shipping the agent is the start, not the finish. Once it's live and writing, you need the same observability you'd put on any other production service: latency, error rate, approval-override rate, and drift in output quality over time.

Treat a misbehaving agent like a failing service — alert, roll back, fix. The discipline of watching agents in production has a name now; AgentOps monitoring for AI agents covers the metrics and tooling that keep a fleet of them healthy past month one.

What to ship first

Don't boil the ocean. Pick one read-only agent against your ERP — order-status exception lookup is the usual winner — and get it live and used within 30 days. Wire it through the integration layer so the path to write-capable agents is already built.

Measure hours saved or errors caught, then add the next. The full sequencing for the first quarter lives in the 90-day AI agent implementation playbook.

The sequence that works:

1. Read before write. Reads can't corrupt the system of record.
2. ERP before MES. Transactions are reversible; floor actions often aren't.
3. One transaction type at a time. Earn each write with evals on real history.
4. Human-in-the-loop on anything that touches the floor or the books.

Frequently asked questions

Should an AI agent write directly to my ERP?

Not on day one, and not without a layer in between. Start read-only to capture most of the early value with zero risk to your system of record, then add write access one transaction type at a time. Every write should pass schema and business-rule validation and a human approval step before it commits, using a scoped service account rather than admin credentials.

What's the safest way to connect an agent to an old ERP with no good API?

Use a read replica of the database for read-only use cases. A replica is a read-only copy that mirrors the primary, so the agent gets full, real-time data access and physically cannot write anything wrong. Reserve RPA or screen automation for the rare case where there's no API and no database access at all, because it's brittle and breaks on UI changes.

How is integrating an agent with MES different from ERP?

ERP integration is about transactions; MES integration is about timing and physical consequences. A bad ERP write can usually be reversed with a correcting entry, but a bad MES action can scrap a part before anyone reacts. The safe pattern is to let the agent read from the MES but route any action back through ERP or a human, and keep it at ISA-95 Levels 3–4 so it never issues control commands.

What is the ISA-95 boundary and why does it matter for AI agents?

ISA-95, published internationally as IEC 62264, defines a hierarchy that separates business planning (Levels 3–4) from process control (Levels 1–2). Keeping an AI agent on the planning side means it can inform decisions without ever sending a setpoint to a controller. That boundary exists for safety reasons that long predate AI, and respecting it lets the agent inherit every control already built into your MES and DCS.

How do I keep an AI agent from doing something destructive in production?

Constrain it at the integration layer, not in the prompt. Give it the minimum necessary tools and least-privilege credentials, validate every write against your business rules, log everything for audit, and require human approval on high-stakes actions. This directly counters OWASP's "Excessive Agency" risk, and pairing it with evals on real historical data before go-live is how you prove the agent is ready to write.