Your agent is fine: your system of record is the project

There is a point where almost every agent project slows down, and it is always the same one: the moment the agent has to write into the ERP the business actually runs on. Up to there, everything looks fine. The agent reads a report, cross-references an export, produces a sensible answer, and the demo lands. Then comes the request that closes the loop — post the document, open the case, update the order — and the project stops being an AI project and becomes an integration project.

Reading is the easy half

Reading has no consequences. A view, a nightly export, a read-only query: if the agent gets it wrong, it got it wrong to itself. That is the half you build quickly, the half you can show, and usually the half that got funded.

Writing is a different animal. The ERP is the source of truth and the agent, at best, is a guest. It has referential integrity the agent knows nothing about and does not own. It has validation that fires server-side, after the call has already left. It has documents that cannot be amended once posted — you reverse them with another entry, which is itself an accounting event. And it has batch windows where writes queue instead of failing, which is worse than an error, because an error is something you can see.

The expensive case is the retry. In the agent's code, retrying looks harmless — it is the correct thing to do when a call times out. Downstream, if the endpoint is not idempotent and there is no correlation key the ERP actually honours, that retry is a second order. Nobody notices until the goods arrive twice.

The agent needs an identity

Then there is a question that only looks technical: who posted that entry? If the agent goes through the shared service user — the one that has existed for years, can do everything, and whose password sits in three config files — the answer is "the integration". That is not an acceptable answer for an auditor, and it is not an acceptable answer for whoever has to reconstruct what happened six months later.

The agent needs its own account, with narrow permissions on only the documents it touches, and a trail that ties each write back to the decision that produced it. Regimes like the EU AI Act ask for the same thing in different words for high-risk systems: logged events and reconstructable accountability. It is a requirement that is far cheaper to design in than to retrofit onto an integration already in production.

The sandbox is not production

The last obstacle is the one that moves the dates. Most ERP test environments do not mirror production master data: the customers are invented, the chart of accounts is trimmed, the item codes are clean. The agent passes there, goes live, and on day one meets the real customers, the duplicate records and the half-migrated codes from a previous system nobody finished cleaning up.

None of this is model work. It is integration engineering: mappings, idempotency, permissions, error handling, reconciliation. It is the work that does not show up in the demo and does show up on the invoice, and it is most of the budget. The good news is that it is ordinary engineering — as long as it was in the estimate.

When you scoped your last agent project, how much of the estimate was the ERP?