Article · Implementation
How to Integrate AI Agents With Your ERP, Step by Step
Integrating an AI agent with your ERP isn’t a matter of plugging the model into the system and letting it loose. It’s about giving an agent the same kind of access an operator has —read where the case lives, write where it belongs— but with limits per operation, the ability to undo, and somewhere to test before touching production. Order matters. You first teach the agent to read and propose, and only when that’s reliable do you let it write. Here’s the sequence I follow, and what to do when the ERP is old or exposes no API.
I say “an ERP” generically because the pattern is the same with any of them. What changes from one to another is how much ceremony each step takes, not the logic.
Read first, write later
The first integration of any agent should be read-only. Let it look up the order, the invoice, the stock level, and propose what it would do —without executing it. During that period a person reviews the proposals and you check against real cases whether the agent’s judgement matches what a good operator would apply.
This phase looks like a detour and is the opposite. It’s what prevents the disaster. An agent that only reads can’t break anything, so you can let it run over the real operation without risk while you gather evidence of its quality. When the data shows it gets things right, it earns write access for that specific operation, not for everything. Write access is earned operation by operation, not handed over all at once.
Permissions per operation, not per system
The classic mistake is giving the agent an ERP credential with power-user permissions and trusting it to “only do what it should”. An agent shouldn’t have user access, but task access.
In practice that means defining the permission at the level of the specific operation: this agent can read invoices and create a reconciliation entry within a tolerance, but it cannot modify master data, approve payments, or touch anything outside that verb. Each capability is granted explicitly and can be withdrawn without dismantling the rest. This permission design is a governance piece in its own right, and I cover it in more depth in AI agent permissions and controls.
| Access level | What it enables | Risk if over-granted |
|---|---|---|
| Read | Look up the case and its context | Low; keep it here at first |
| Scoped write | Create or update a record within rules | Medium; demands idempotency and audit trail |
| Sensitive write | Payments, master data, closings | High; usually stays in human escalation |
Idempotency and reversibility
Two technical properties that aren’t optional once an agent writes to the ERP.
Idempotency: running the same action twice produces the same result as running it once. Agents retry, processes cross, networks fail halfway. If the agent creates an order and gets no confirmation, it can’t afford to create a duplicate second order on retry. You solve it with operation keys the ERP recognises as “I already did this”, so the retry doesn’t duplicate.
Reversibility: every action has a defined way to be undone or compensated. Not everything can be deleted in an ERP —a journal entry is corrected with a reversing entry, not a delete— so “reversible” means there’s a known path back to how things were. Before allowing a write, I insist on knowing how it’s reversed. If there’s no way to undo it, that operation stays on the list a human confirms.
Somewhere to test without fear
No agent touches production without first working against a test environment with representative data. That’s where you run the evaluations —cases with known answers— and where you watch how the agent behaves at the edges: the badly scanned invoice, the duplicated supplier, the half-closed order.
If your ERP has a test or staging environment, that’s the place. If it doesn’t, you build a scoped one: a data copy or a synthetic set that reproduces the cases that matter. Building that measurement is the difference between deploying with judgement and deploying on faith. How it’s done is in AI agent evaluation. Skipping this step is one of the reasons so many pilots don’t survive first contact with reality, something I analyse in why enterprise AI pilots fail.
When the ERP is old or has no API
A good share of the ERP estate in mid-market companies exposes no modern API, or exposes a partial one. It isn’t an insurmountable obstacle, but a decision about which connection mechanism to use, from cleanest to most handcrafted.
- Native API or connectors. If they exist, that’s the preferred route: explicit contract, granular permissions, predictable behaviour. A protocol like the one I describe in MCP, the Model Context Protocol standardises how an agent connects to tools and systems, cutting the bespoke work.
- File exports and imports. Many old ERPs speak well in batches: the agent reads a scheduled export and drops its results into an import the system picks up. Less immediate, but robust and easy to audit.
- Intermediate queues. A messaging layer between the agent and the ERP decouples the two tempos, absorbs peaks, and gives a natural point to log each operation and retry safely.
- The user interface as a last resort. When there’s no other door, an agent can drive the ERP’s own screen as a person would. It works, but it’s the most fragile, since any interface change breaks it. I reserve it for scoped operations and always under close watch.
The rule I apply: the more handcrafted the channel, the narrower the mandate and the more audit trail required. An agent driving the screen deserves less autonomous trust than one with a contractual API behind it.
Where this integration sits in the whole
Connecting the ERP is one piece of a broader architecture —memory, orchestration, controls— described in AI agent architecture. Two topics are deliberately out of scope here because they’re their own: what data the agent needs before you integrate it, in what data an AI agent needs; and what happens with cases the integration can’t resolve alone, in exception handling and human escalation. And since any connection to a critical system opens risk surface, read it alongside AI agent security. The broader frame is AI agents for business.
Frequently Asked Questions
Can an AI agent write directly into the ERP?
Yes, but it’s earned in phases. The first integration is read-only: the agent proposes and a person reviews. When evaluations show its judgement is reliable, it earns write access for that specific operation, with idempotency and a defined way to reverse. Sensitive writes —payments, master data, closings— usually stay under human confirmation.
How do I integrate an agent if my ERP has no API?
Through other channels. File exports and imports work well with old ERPs, an intermediate queue decouples tempos and gives an audit trail, and as a last resort the agent can drive the user interface itself. The more handcrafted the channel, the narrower the mandate should be and the more oversight it requires.
What is idempotency and why does it matter for ERP integration?
It’s the property that running an action twice produces the same result as running it once. Because agents retry and networks fail halfway, without idempotency a retry would create duplicate orders or entries. You solve it with operation keys the ERP recognises as already executed.
Do I need a test environment to connect an agent to the ERP?
Yes. No agent should touch production without first working against a test environment with representative data, where you run the evaluations and watch its behaviour on edge cases. If the ERP has no staging, you build a scoped environment with a data copy or a synthetic set.