An anti-corruption layer to connect AI to a legacy ERP

Connecting an AI application directly to a legacy ERP is a common temptation and a recurring architecture mistake. The ERP has its own data model, its own implicit rules, and often capacity limits that were never designed for the high-frequency read traffic generated by agents. The engineering answer is the anti-corruption layer (ACL): an intermediate layer that translates, protects, and governs access, keeping the legacy system's mental model — or its operational fragility — from leaking into the AI application.

What the ACL needs to solve

An anti-corruption layer between ERP and AI has five concrete responsibilities, not just "acting as a proxy":

1. 1.Data model translation — expose stable business entities (order, customer, inventory) instead of internal ERP tables, which change with upgrades and patches.
2. 2.Load isolation — prevent AI queries from saturating the source transactional system.
3. 3.Consistency and idempotency — ensure reprocessing (common in AI pipelines) doesn't duplicate effects.
4. 4.Identity and permission propagation — ensure the AI agent operates with the correct authorization context, not a generic service credential.
5. 5.Reconciliation — detect and correct divergences between what the layer exposes and the ERP's actual state.

API contracts: what to expose, what to hide

The ACL's contract should be modeled from the business domain, not the ERP schema. That means versioning contracts independently from the legacy system's internal versions:

GET /v1/orders/{order_id}
{
  "order_id": "string",
  "status": "enum(open, fulfilled, cancelled)",
  "customer_ref": "string",
  "line_items": [...],
  "source_system_version": "string",
  "as_of": "datetime"
}

Note the ${'as_of'} field: any response coming from a legacy ERP via replication or cache has a staleness window, and the AI application needs to know that to decide whether the information is fresh enough for the decision at hand (e.g., confirming inventory availability before promising a delivery date).

Contract mistakes to avoid: exposing internal ERP codes without translation (the AI model will learn to handle "status = 7," which means different things across modules), and omitting provenance metadata that would let you audit where each piece of data came from.

CDC vs. batch

The choice between Change Data Capture and batch replication depends on the AI usage pattern, not architectural preference:

For AI agents answering real-time operational questions (order status, availability), CDC is usually necessary. For RAG over documentation and policies that change rarely, daily batch is enough and simpler to operate.

Idempotency

AI pipelines reprocess frequently — from failure retries, agent re-runs, or fixing a retrieval error. The ACL must ensure that any write-back operation to the ERP (e.g., an agent creating a ticket or updating a status) is idempotent by construction:

POST /v1/tickets
Idempotency-Key: {agent_run_id}-{action_id}

Without this key, every agent re-run can duplicate the effect on the source system — a silent, expensive-to-debug problem, because it only shows up as duplicate data in the ERP, not as a visible error in the AI application.

Identity propagation

The most common mistake in ERP-AI integrations is using a single service credential for all AI application traffic. This breaks the ERP's permission model and creates a silent data leak: a user without access to financial data could, through an agent, obtain answers derived from that data.

The ACL must propagate the end user's (or business process's) identity context on every call, applying the same authorization controls the ERP would apply to direct access. This typically means carrying a federated identity token (OAuth2/OIDC) from the AI application through to the ACL, and mapping that context to the ERP's native authorization rules — not simply trusting the AI application to filter afterward.

Load limits and caching

Legacy ERPs are frequently undersized for the access pattern of AI agents, which can generate query bursts when decomposing a task into multiple steps. The ACL should implement:

• Per-consumer rate limiting, not just a global one, to isolate the impact of an agent with anomalous behavior.
• Caching with a TTL aligned to the data's real volatility (inventory changes fast; supplier records rarely do) — always exposing the ${'as_of'} field mentioned above.
• A circuit breaker that degrades the response (cached data, flagged as potentially stale) instead of propagating an ERP timeout to the agent.

Reconciliation

Every caching or replication layer introduces divergence risk. A periodic reconciliation job, comparing samples from the ACL against the source ERP, is the practical way to detect drift before it affects an automated business decision. Treat found divergences as an incident, not statistical noise — the AI will act on whatever the ACL says, right or wrong.

What to do on Monday

1. 1.Map every point where the AI application today accesses the ERP directly or through a generic credential — that's your risk list to prioritize.
2. 2.Define the domain contract (not the ERP schema) for the first AI use case, and include ${'as_of'} and provenance from the first version.
3. 3.Decide CDC vs. batch based on the actual latency the use case requires, not on infrastructure that's already available.
4. 4.Implement idempotency on any write-back operation before enabling automatic agent re-runs.

Further reading

Executive track:

• Your ERP is 20 years old and AI needs to talk to it — the business view of this same topic.