From Software That Records Work to Software That Does the Work

A system of record has a simple contract. A person makes a decision in the world, then opens the software and tells it what happened. The software's job is to store that faithfully, keep it consistent, and give it back on request. CRMs, ERPs, ticketing systems, practice management, accounting — nearly all of business software is this, and it is a genuinely hard thing to do well.

It also has a ceiling that is easy to miss because it is baked into the shape of the product: the software is downstream of the work. However good it gets, the job is still done by a person, and the software's contribution is that the record is accurate afterwards.

The shift worth paying attention to is not that software is getting smarter. It is that software is moving upstream — participating in the decision and sometimes completing the task, so that the record is a by-product of the work rather than a separate act of data entry.

Three positions, not two

The jump from recording to doing is not one step, and treating it as one is how projects end up trying to build the last position first.

Most of the value that is actually being captured right now sits in the middle row, and most of the disappointment comes from teams who skipped it. Propose is cheap, reversible and measurable — and it produces the single most useful number in this whole area, which is the share of proposals a person accepts unchanged. Until that number is high on a specific task, moving that task to the third row is guesswork.

What changes in the architecture

Writes become the product

A system of record is optimised for reads. The writes are few, human-paced, and each one has a person standing behind it who can be asked what they meant. Move to the third row and writes become frequent, machine-paced, and authored by something that cannot be asked anything afterwards.

The practical consequences are the ones any queue-based system faces, and they arrive all at once: operations need to be idempotent because a retry must not double-charge anyone; partial completion needs a defined state because a five-step task can fail at step three; and every write needs to carry who or what authored it, because updated_by holding a service account name is the point at which the audit trail stops answering questions.

Permissions move from roles to actions

Role-based access answers what a person may see. That is the right question when a person is doing the work, because a human who can see a record and should not change it usually just does not.

Software has no such restraint, so the question becomes narrower: may this actor take this action, on this record, with these arguments, right now? That is a different model and it belongs in the system that owns the data — not in the layer that decides what to do.

// A system of record asks: can this user see this?
can(user, "read", invoice);

// A system that acts has to ask something narrower, and the
// answer has to hold even when the caller is confidently wrong.
authorize({
  actor:  "billing-agent",
  action: "issue_refund",
  target: invoice.id,
  args:   { amount: 4_200, currency: "PKR" },
  limits: { maxAmount: 5_000, perDay: 20 },   // enforced here, not upstream
});

The distinction that matters is where limits is enforced. A limit that lives in the calling code is a convention; a limit enforced by the system holding the money is a constraint. Only the second one survives a caller that has misunderstood its instructions.

The audit log becomes a product surface

When people do the work, the record of why is distributed across memory, email and the fact that a named person signed it off. When software does the work, the only account of why is what the system wrote down at the time.

That turns the log from an operational artefact into something a user reads: what was proposed, what was actually done, on what basis, and what a person changed afterwards. Built well, it is also how the system earns scope — the argument for widening an automated boundary is a log that has been uninteresting for three months, and no team can make that argument from a log they only look at during incidents.

Undo stops being a nice-to-have

Every action the software can take needs a defined answer to what happens if this was wrong, decided at design time rather than discovered during one. Some actions are cleanly reversible. Some are compensable — a refund reverses a charge without deleting it. Some are neither, and those should be the ones that stop for a person.

Why bolting AI onto a system of record disappoints

The common version of this shift is a feature added to an existing product: a summary, a suggested reply, a drafted description. These are real improvements and they are cheap to ship, which is why they are everywhere.

They also tend to stall, for a structural reason. The feature can read but not write, so its output is a suggestion that a person must transfer into the system by hand. The work saved is the composing; the work remaining is the doing, and the doing was the expensive part. The result is a feature that demonstrates well and quietly stops being used.

Getting past that means giving the system a way to complete the action — which brings back every requirement above. That is the actual project, and it is mostly ordinary engineering: an action model, a permission surface, a reversal path, a log. The model is one component among several, and rarely the one that decides whether the thing works. That is the same conclusion the chatbot-versus-agent distinction arrives at from the other direction.

The measurement to hold it to

There is one number that tells you whether a system has genuinely moved position, and it is not adoption, satisfaction, or time saved as estimated by the people who were saved the time.

For a system of record, the answer is zero by definition — opening it is the work. For a proposing system it stays near zero, and that is fine, because the value shows up in acceptance rate instead. For a system that acts, the number should be climbing, task by task, with a log that explains every case where it did not.

This is also why the sequence matters more than the ambition. Systems get to the third position one narrow, reversible, well-logged task at a time — and the process mapping that identifies which task to start with is worth doing before any of it. Software that does the work is not a category of product. It is a position a system reaches on a specific job, and it has to be earned separately for each one.