The gap between a working demo and a working business process

A demonstration is a system performing under conditions someone chose. A process is a system performing under conditions nobody chose, repeatedly, while the people who built it are doing something else.

Everything hard is in the second description.

What a demo omits

The input that is malformed in a way nobody anticipated. The case that falls outside the categories. The week the source system changed its schema without telling anyone. The person who used the tool differently from how it was designed, and was not wrong to.

A demo omits these because it has to. The problem is that a business process consists substantially of them, and a system that has only been tested on the clean path has not been tested on the work.

The four additions

Between a working demo and a working process, four things have to be added, and none of them are model capability.

A boundary. What the system is permitted to do, enforced where the action happens rather than requested in an instruction. Without this, scope is whatever the model decides it is on a given run.

An owner. A named person responsible for it continuing to work. Systems without one degrade silently, because nobody is watching for degradation.

A definition of correct. Written down, specific enough to score automatically. Without this, quality is whatever a busy person notices, which is a declining function of how many systems they are notionally overseeing.

A cost that is attributed. Otherwise the process has an unbounded claim on a shared budget, and the first review will be about AI rather than about this process.

Why the order matters

Teams generally add these in the order of perceived sophistication, which is backwards. Evaluation gets attention because it sounds advanced; ownership gets skipped because it sounds administrative.

But an evaluation that nobody owns produces scores nobody acts on. A boundary without attribution produces a safe system of unknown cost. The administrative pieces are what make the technical ones functional.

The honest assessment of value

Agents do remove work, and the removal is real. They also add a new category of work that did not exist before: operating them, which is ongoing rather than one-off.

Any business case that counts the first and not the second is describing a pilot. The programmes that succeed budget for both, which makes them look less impressive on a slide and considerably more likely to exist in a year.

Where to start

Pick one process that is well-specified, currently expensive, and where being wrong is recoverable. Give it an owner before building. Write down what good output looks like. Set a budget that blocks. Then build.

That sequence is slower than the demo suggests and it is the only one we have watched produce something still running twelve months later.

Next

The Agent Orchestration System pages cover boundaries, ownership, evaluation and attribution as one system. The Use Cases pages cover where other organisations have started.