What an AI agent may write in an ERP
Which ERP records an agent may change. A catering agent we shipped only reads. October rollouts show three different checks before a post.
Write access defines an AI agent’s blast radius. It determines which ERP records the agent can create or change without approval, and how much damage a mistake can cause before anyone catches it. Reading is cheap. Our default is cautious: let most agents write beside the ERP, into reports or proposals, then earn direct access one narrow record type at a time.
The engagement we shipped
A Spanish industrial catering company serves hundreds of B2B accounts, from restaurants and corporate canteens to institutional kitchens, while processing over 10,000 orders a month through a MongoDB-based ERP. The boundary is simple. Our agent reads the system weekly but can’t create or modify orders.
The agent gets a single generic mongodb_query tool, writes its own queries, chooses what deserves attention, then posts named recommendations for each account to Slack every Monday morning. Nobody triggers it. Python and the Claude Agent SDK run the analysis, while MongoDB and the Slack API connect the workflow on a VPS through a weekly cron.
The Monday report is its only output, yet the published results tied to that work were +23% cross-sell revenue in the first 4 months and 12+ at-risk accounts flagged before the sales team noticed. That’s time back. The team also stopped spending 9 hours a week on manual exploration. Each run works through about 400 MB of operational data and produces 15 to 25 recommendations. The catering engagement has the full write-up.
Failure stays visible. A bad query can weaken Monday’s report, but a bad ERP write could corrupt an order a kitchen is waiting for and remain hidden until the wrong delivery arrives.
What others shipped in October
cbs published its work with SFS Group on 12 October 2026 (Heidelberg dateline 13 October), describing AI that extracts incoming customer orders while employees complete final validation before the SAP post, cutting processing time per order from about seven minutes to under two. A person still validates each order.
Microsoft’s Asurion story, dated 8 October 2026, says its agent resolves invoice exceptions before they reach Dynamics 365 Finance, helping touchless processing for North and South America move from under 20% to more than 70%. That distinction matters. Touchless processing is the result, so a person isn’t reviewing every invoice.
ERP Today reported on ITOCHU on 8 October 2026, and ERP Leaders wrote it up a day later: about 3,000 custom modifications had to be addressed before the AI work could begin. Staff remain in control. The AI proposes accounting entries from uploaded documents, and ITOCHU staff review those proposals rather than allowing unchecked posting.
What we’d watch for
The safer path is a ladder. Start read-only, move into a staging area where a person approves drafts, then permit direct writes for one record type only after those drafts have been boringly reliable for a long stretch.
Cleanup comes first. If an ERP carries years of custom fields and poorly documented status codes, an agent with write access may learn those quirks by breaking records, leaving the team to spend its savings on reconciliation. ITOCHU’s 3,000 modifications are the warning.
This is a guess. We’d try a short do-not-investigate list that the sales lead can edit, so the Monday agent stops re-flagging accounts the team has already decided to leave alone. It isn’t a published result from this engagement. Repeated recommendations train people to skim, while this small boundary would let humans tell the agent where further analysis has no value.
Email contact@unlockmanagement.com with the system the agent would read, and whether it should be allowed to write. We’d rather see one real collection or table name than a transformation slide, because the write question usually answers itself once we know what the agent would touch. We reply within 24 business hours. There is no public rate card.