Connecting ERP, AI agents and operational workflows
Keep the ERP as the system of record. Put decisions in a layer above it that reads first and writes back only through the ERP, after a named person approves.
Every manufacturer and distributor that brings AI into operations reaches the same question sooner or later: what is the new system allowed to touch? The ERP holds orders, stock, purchase orders and financial postings, along with the validations and approvals that auditors rely on. A tool that writes around those controls creates a second version of the truth. A tool that can only talk cannot help get anything done. A clear division of roles resolves the tension.
System of record and system of decision
The ERP, the warehouse management system and the transport management system are systems of record. They own the master data, the transactions and the postings, and they enforce the rules: credit limits, price tolerances, period locks. A system of decision sits above them. It reads their data, predicts what is coming, lays out options with evidence, collects approval, and then asks the system of record to carry out the result through its own interfaces.
| Concern | System of record (ERP, WMS, TMS) | System of decision |
|---|---|---|
| Item, customer and supplier master data | Owns and maintains it | Reads it, and flags gaps or conflicts to the data owner |
| Orders, purchase orders, transfers, invoices | Creates and posts them | Proposes them, then submits drafts or requests through the ERP's interfaces after approval |
| Business rules and validations | Enforces them | Respects them and never bypasses them |
| Predictions, options and evidence | Not held | Owns them |
| Approvals | Keeps existing policy approvals, such as purchase order release | Records who approved each recommendation, and on what evidence |
| History | Transaction history | The full decision record, from signal to measured outcome |
The split has a practical benefit beyond control. The ERP can be upgraded on its own schedule and the decision layer can change quickly, without either breaking the other, as long as the interface between them is stable and documented.
Read first
Start read-only. It carries no risk to live transactions, it simplifies the security review, and it shows the real state of the data before anyone acts on it. It also makes shadow running possible: the system recommends, people decide as usual, and the two can be compared.
- Use the ERP's supported interfaces, standard extracts or reporting views. Avoid reading raw tables where a supported route exists.
- Agree a refresh frequency per data type. Stock positions may need hourly updates. Supplier lead times may need weekly ones.
- Publish exactly what is read, from which system and how often, and give the list to IT and to the data owners.
Write back through the ERP, with approval
When a decision type is ready to write, the write goes through the ERP's own transaction interface, so its validations, numbering, authorizations and audit trail all apply. Writing directly into database tables skips every one of those controls, and it should be ruled out from the start.
Three properties matter for every write:
- Approval. A named person with authority for that value approves before the write. The person who requested an action should not approve it, and neither should the agent that proposed it.
- Idempotency. Sending the same request twice must not create two purchase orders. Every write carries a unique key that the receiving side checks.
- Reversal. Every action has a documented reverse step, such as canceling the purchase order or reversing the stock transfer, and that step has been tested.
Many teams start by writing drafts: a planned order or a draft purchase order that a buyer then releases inside the ERP. That keeps the existing release controls intact while the decision layer earns trust.
Put approvals where the work happens
Approval is a workflow step, and it fails in familiar ways. Requests sit in an inbox while the option expires. The approver is traveling and nobody else can sign. The evidence lives in three attachments and a spreadsheet. Design the approval workflow as carefully as the integration:
- One view per decision. The recommendation, the options, the evidence and the deadline on a single screen that is readable on a phone.
- Authority by value. Route each request to the person whose limit covers it, using the delegation-of-authority rules finance already has.
- Delegation and escalation. A named deputy when the approver is away, and automatic escalation as the deadline approaches.
- Reasons on rejection. A rejected recommendation with a reason is evidence the system can learn from. A silent rejection teaches nothing.
Master data is the real integration project
Connecting to an ERP is usually the easier part. The harder part is the data inside it. Units of measure that differ between purchasing and inventory. Lead times set years ago and never updated. The same supplier set up three times. Inactive items still being planned. Pack size and shelf-life fields left blank. A model fed bad master data produces confident, wrong answers.
Master data does not need to be perfect before you start. It needs to be right for the first decision. List the fields that decision depends on, check how complete and current they are, and name an owner for each fix. When the decision layer finds a suspect value, such as a lead time that never matches actual receipts, it should flag it to that owner. Quietly correcting it inside the decision layer hides the problem from the people who maintain the record.
Agents need guardrails, evidence and rollback
AI agents can read documents, draft messages and call tools. In operations, each agent needs a written specification of what it may do before it goes live:
- Allowed tools. An explicit list of what it can call, with read and write separated.
- Limits. Value, quantity, counterparties and time windows.
- Evidence. Every proposal cites the data it used, with timestamps. When data is missing or stale, the agent stops and escalates.
- Calculated numbers. Quantities, prices and dates come from calculations and solvers that can be checked. The language model explains, summarizes and drafts.
- Approval. Writes wait for a named person until the decision type has earned more autonomy.
- Rollback. Every action has a reverse path, tested before go-live.
- Full logging. Every step is recorded, so an auditor can replay why something happened.
None of this is specific to one vendor or one model. It is the same control discipline a CFO already expects of any person who can raise a purchase order, applied to software.
Questions for your IT and operations leads
- What exactly will be read, from which systems and how often?
- What will be written, through which interface, and who approves each type of write?
- What happens if the same write is sent twice?
- How is a written action reversed, and when was that last tested?
- Which master-data fields does the first decision depend on, and who owns them?
- Where can an auditor see the full record of any decision?
FLX4 follows this pattern. It reads first and writes back only after approval, through your own system of record, with ERP connectors configured per deployment. In FLX4 products, quantities, prices and dates come from calculations, and the language model explains them. SourceNest stops its supplier-award workflow for a sourcing approver before any write, and escalates awards above a value ceiling instead of writing them.