A system of record cannot act

Enterprise software has been built around one idea for forty years: hold a correct account of what the business did. Orders placed, stock moved, invoices raised, staff paid. The record is authoritative, auditable and reconcilable, and an enormous amount of engineering has gone into making it trustworthy.

It is also, structurally, incapable of doing anything. Every action in it originates outside it, with a person who decided something and then told the system about it afterwards. That is not a gap in the products. It is the design.

What follows from the design

Latency is human. The record is current only as often as somebody updates it. Between updates it is a historical document being read as a present-tense one, and every decision taken from it is taken from stale information.

Throughput is human. The organisation can process exactly as many transactions as its people can enter. Adding capacity means adding staff, which is why administrative headcount tracks revenue almost everywhere.

Judgement is not captured. The reason a decision was made lives in an email, a conversation or somebody’s memory. The system stores the outcome and loses the reasoning, which is why the same question gets re-litigated every year.

Exceptions escape. The documented path covers the standard case. Everything else is handled by experienced people through channels the record never sees, so the record describes a tidier company than the one that exists.

What acting instead means

A system of action starts from the same data and runs the other way. The job closes, so the invoice is drafted. Stock crosses a threshold, so the replenishment is prepared. A machine goes down, so the schedule is rebuilt and the affected customers are identified. The system produces the next step and asks whether to proceed.

The distinction is not automation in the old sense. Rule-based automation has existed for decades and it breaks on the exceptions, which is why it stayed at the edges. What changed is that a system can now read an unstructured email, understand an unusual situation, and produce a sensible draft for a case nobody wrote a rule for.

Why this needs one record, not integration

An acting system needs the whole picture. To draft an invoice it needs the order, the delivery, the pricing agreement, the customer’s payment history and whether there is an open complaint. Those live in four products, and getting them into one place at the moment of the decision is the work that integration never quite finishes.

This is why the answer is one record rather than better connectors. Not because integration is technically hard, but because an action requires a consistent view at a single instant, and synchronised systems are consistent only in the gaps between changes.

The part that has to come with it

An acting system is wrong sometimes, and the cost of being wrong is now paid at machine speed rather than human speed. So the useful version arrives with three things attached, and none of them is optional.

Bounds — what each agent may touch and to what value. A decision log — what it saw, concluded and did, readable by a person months later. And approval on anything irreversible, because a wrong draft costs a minute and a wrong payment costs considerably more.

Get those three right and the autonomy is defensible. Skip them and you have built something impressive that no company can be accountable for, which is the same thing as having built nothing.