An agent that writes to the ERP: the line between read and write

A purchasing team runs a pilot. An agent reads open demand, stock and supplier lead times, and for three weeks it does what everyone hoped: it proposes orders, the buyers check them, the buyers key them into the ERP. Then somebody asks the obvious question. Why are we retyping what the agent already prepared? Give it write access.

On a Monday morning the ERP shows two purchase orders for the same supplier, same lines, two minutes apart. One has a confirmation from the supplier attached. The other is empty below the header. The connector had timed out on the first attempt and retried; the ERP accepted both halves of the story. The supplier has already started picking against one of them, and nobody in the room can say which.

Nothing about the agent’s reasoning was wrong. What failed was the write, and the write is where every integration has failed for twenty years. Reading from a system of record is a solved and nearly risk-free problem: a read can be repeated, cached, compared and thrown away. A write changes the record that the rest of the company treats as the truth, and the record has no way of knowing whether the change was meant once or twice.

Why writing back is a different problem

A read is repeatable; a write is not. If a read fails halfway, you read again. If a write fails halfway, you have a document that is partly there, and the next attempt either duplicates the part that landed or skips the part that did not. Every reconciliation job that runs at month end exists because of this asymmetry.

A partial write is worse than no write. A purchase order with a header and no lines passes the ERP’s own validation. It also blocks the supplier’s number, appears in open commitments and gets picked up by the next report. The failure is invisible exactly where it matters.

There is no undo in a system of record. Accounting software is designed so that nothing is deleted. A wrong posting is corrected by a reversal, a wrong invoice by a credit note. Each correction is a new document with its own number and its own audit trail, so a mistake made at machine speed leaves machine-speed debris that a person has to clean by hand.

A timeout turns one intention into two actions. The connector does not know whether the system received the request and was slow to answer, or never received it. Without a way to say “this is the same request as before”, the safe choice and the correct choice point in opposite directions.

The write bypasses the meaning. The ERP checks that fields are filled and codes exist. It does not know that this customer is on a credit hold agreed in a meeting, or that this supplier may only be used for one plant. Those rules live in people, and a direct write walks straight past them.

Nobody can say who wrote it. The integration user that created the order is a technical account shared by every job that runs through it. The question “who decided this” has no answer in the record, which is the subject of one identity for people and agents.

What has to exist before an agent writes

Idempotent proposals. Every intended change carries one identifier, created before the first attempt. Sending it twice must produce one result, and the receiving side must be able to say “already done” rather than doing it again. If the target system cannot honour that, the layer in front of it has to, by checking before it sends and recording what it sent.

A sign-off step that a person owns. Not a notification, a decision: the proposal, the evidence behind it and the risk it carries, approved, changed or rejected by someone whose name goes into the record. Which writes need this is not a matter of taste; it is written down per action, and money leaving or a commitment made is always on the list.

A replayable log. What the agent saw, what it concluded, what was proposed, who approved it, what was sent, what came back. Written so that months later a person can follow the chain, and structured so that the chain can be replayed against a copy of the system when something has to be reconstructed.

A boundary the ontology makes explicit. The actions that exist on each business object, the states each object may be in, the rules a change must satisfy and which actions count as critical. An agent that acts only in those terms cannot write something the model does not allow, and a person reading the model can see exactly what the agent is permitted to do.

Reconciliation after the write. Read back what landed and compare it with what was sent. Most duplicate postings are found by the supplier or the auditor; they should be found by the system that made them, within minutes.

A test you can run today

Take the newest integration that writes into your ERP or accounting program. It does not have to involve an agent; a webshop connector or a spreadsheet upload will do. Ask the people who built it three questions and write the answers down.

What happens if the same message arrives twice? What happens if the transfer fails after the third line of seven? Where is it recorded who approved the document that was written, and on what evidence?

Then, if you have a test environment, try the first two and count the corrections it takes to get the record back to the truth.

If any answer is “we would find out from the supplier” or “we would see it at month end”, the integration is not ready for an agent, whatever the agent can read. The gap is not in the model; it is in the write path, and it is the same gap for a person and for software.

Hurukan draws its own line here. Agents prepare, draft and propose inside written limits, and they act only in the terms the ontology defines. What leaves for the accounting program, or for an existing system kept running alongside, goes after a person has approved it, through a connector, with the proposal, the decision and the outcome in one log. Critical operations wait for a person under every configuration. The reason a system of record cannot be trusted to act on its own is argued in a system of record cannot act; the write path is where Hurukan starts.