Integrating AI with an ERP: 4 patterns that work in production

The AI demo runs beautifully in the presentation. Then comes the time to connect it to the company's ERP — Totvs, SAP, or that in-house system from 2011 — and the project stalls. This is where most enterprise AI initiatives die: not in the AI, but in the integration with the system that actually runs the business. These are four patterns that survive production.

Pattern 1: API as a contract (read-only first)

The safest path starts with reading, not writing. You expose the ERP data through an API — REST when it already has one, or an adaptation layer you build on top — and the AI consumes that API as a tool. The agent reads orders, checks stock, fetches customer history. It writes nothing yet.

Why start read-only? Because a wrong read is harmless; a wrong write moves money. You gain value early (querying, classifying, suggesting) and build confidence in the agent's behavior before giving it the power to change data. When writing comes in, it comes surrounded by validation.

Pattern 2: an event queue for decoupling

Old ERPs do not like synchronous load coming from outside. Bombarding the system with real-time calls during a peak is a recipe for taking it down. The pattern that works is decoupling via a queue: the ERP (or the agent) publishes events to a queue — RabbitMQ, Kafka — and the other side consumes at its own pace.

The AI processes the event, decides, and publishes the result back to another queue, which the ERP consumes when it can. This protects the critical system from spikes, gives natural retry on failures, and creates an auditable event trail. It is the most robust integration pattern we know for legacy systems that cannot go down.

Pattern 3: human-in-the-loop for high-impact actions

Not every decision should be automatic. For high-impact actions — approving credit, canceling a large order, adjusting a price outside the range — the right pattern is for the agent to prepare the action and a human to confirm. The AI does the heavy lifting (gathers context, calculates, recommends); the person gives the go-ahead with a click.

This is not "AI done halfway." It is honest architecture: you automate 90% of the effort (the gathering and analysis) and keep human control over the 10% that carries the risk. As confidence grows and the accuracy data accumulates, you can selectively move certain actions to automatic — based on evidence, not faith.

Pattern 4: an anti-corruption layer over the legacy

When the ERP is old, poorly documented, and full of hidden rules, connecting the AI directly to it couples the whole new system to the old one's quirks. The anti-corruption layer pattern (from DDD) solves this: you build an intermediate layer that translates the ERP's messy model into a clean model that the AI and the new systems consume.

The AI talks to a coherent model; the layer absorbs the complexity of talking to the legacy. When the ERP is modernized in the future, you swap the layer's implementation without touching the AI. It is risk isolation in the form of architecture.

What to avoid

Three antipatterns show up every time. Direct writing without validation — giving the agent write access to the ERP on day 1, with no fallback or audit, is an invitation to data corruption. Synchronous calls at volume — coupling the AI's latency to the ERP's takes both down under load. And integration without observability — if you do not log every interaction between the AI and the ERP, the first production bug becomes a blind hunt.

The common thread

The four patterns share one principle: the AI is the easy part; reliable integration with the system that runs the business is the hard part, and it is where the value lives. Start read-only, decouple via a queue, keep the human in the risky actions, and isolate the legacy behind a clean layer. Do that and the AI stops being a pretty demo and becomes part of the operation — which is the only place it pays for itself.