AI agents with ERP and CRM: three safe patterns

Why integration is the hard part

A model that drafts a good reply or classifies an invoice is the easy half. The hard half is where the result goes. Your ERP and CRM hold the records the business runs on, and an agent that can write to them can also damage them quickly and at volume. The reflex answer is to replace the old system with something built for AI. That is slow, expensive and rarely necessary. A better question is how little access the agent needs to be useful, and how you widen it safely. The three patterns below answer that question in order of increasing access. They are engineering practice from our own delivery work. They are not a standard, and we make no claim here about what any particular ERP or CRM product can or cannot do: check that against your own system and its documentation.

Three patterns at a glance

The table compares them on what the agent needs, how each fails and how you undo it. Each pattern builds on the one before, and a workflow can stay at the first or second for as long as it needs.

Pattern 1: the read-only mirror

The agent never touches the live system. A scheduled export or a read-only account copies the records it needs into a separate store, and the agent reads only from there. This is the lowest-risk way to start. The agent can summarise open orders, find duplicate contacts, answer questions about a customer or prepare a report, and the worst outcome is a wrong answer that a person reads. Two things deserve care. First, copy only the fields the task needs, so personal data is not duplicated without a reason. Second, show the age of the data next to every answer, because a mirror is always slightly behind.

Pattern 2: the proposal queue

Here the agent may suggest a change but may not make it. It writes each proposal to a queue, with the record it concerns, the change it wants, its reasons and the data it relied on. A person reviews the proposal and applies it, or rejects it with a reason. This gives you the benefit of an agent that does the preparation work while a person keeps the final decision. It also produces the most useful evidence you will have: every approval and rejection tells you how often the agent is right. The common failure is rubber-stamping, where reviewers click through. Counter it by showing the reasoning next to the proposed change, by sampling approved items and by tracking rejection rates over time. Our article on human approval patterns describes the variations.

Pattern 3: scoped write-back

Some proposals are so routine and so reversible that a person adds little by approving each one. For those, you can let the agent write directly, but only inside a boundary you define. Give it its own service account, never a person's login. Limit that account to named record types, named fields and named actions, and set a ceiling on how many writes it may make per hour. Write every change to a log with the before and after values and a link to the proposal or trigger. Keep a pause switch that stops the write path without touching the rest of the system. The failure to design for is a write that is valid but wrong, repeated across many records. The ceiling and the log exist to keep that failure small and findable.

What the law asks of you here

Two provisions bear directly on this work, and neither is specific to ERP or CRM. According to the European Commission's AI Act Service Desk, Article 26 of the AI Act sets obligations for deployers of high-risk AI systems, including assigning human oversight to competent people, monitoring operation, suspending use where a risk appears and keeping automatically generated logs for at least six months. It applies to high-risk systems only, so check with your adviser whether your use case is one. Article 32 of the GDPR requires controllers and processors to put in place technical and organisational measures appropriate to the risk, and its text names measures such as pseudonymisation, encryption, the ability to restore availability and regular testing. Narrow access, separate accounts and action logs are ways of meeting that kind of duty. They do not prove compliance on their own. This is general information from an engineering team, not legal advice.

An ordered go-live checklist

Work through these in order, and do not start a step until the one before is done. Each of them is cheap before launch and expensive after.

1. Name the single workflow, the records it touches and the person who owns the outcome.
2. List the exact fields the agent needs, and drop everything else from the mirror.
3. Create a dedicated read-only account or export, and confirm in a test that it cannot write.
4. Run the agent against the mirror alone for a trial period, and have people compare its answers with the real records.
5. Add the proposal queue, with the reasoning shown beside each proposed change and a reason required for each rejection.
6. Write down the rollback for each pattern in use, and rehearse it once on test data.
7. Only if proposals are routinely approved unchanged, create the scoped write account with a per-hour ceiling, a full action log and a pause switch.
8. Agree who reads the logs, how often and what triggers a stop, then set a date to review the access.

What this article does not cover

It does not describe the interface, limits or permission model of any specific ERP or CRM, because those differ between products and change between versions. Your supplier's documentation is the source for that, and a short technical test in a sandbox is the way to confirm it. It does not claim results from any client project, and it gives no estimate of cost or savings. It also cannot tell you whether your use case is high-risk under the AI Act or needs a data protection impact assessment. Those are legal judgements for your data protection officer or lawyer. What it offers is a way to keep the access of an agent small, visible and reversible while you find out whether it earns more.