What it does to software

Almost every business system ever built models the same thing: records and the transitions between them. An order exists, its status changes, a timestamp is written. What is missing from that picture is not detail. It is the pair of people the record was standing in for.

Status is a person with the name taken off

Open any workflow table and read the status column as speech. "Pending approval" means somebody has been asked and has not answered. "In progress" means somebody promised. "Done" means somebody said it was done, which is not the same as anybody having accepted it. "Blocked" means a promise is waiting on a promise nobody has drawn.

Every one of those states is a commitment between two named people, recorded with the names dropped. That is why status reports feel thin and why "who owns this" is a question a schema full of statuses cannot answer: the field records the position in the loop and throws away both ends of it.

The change is smaller than it sounds. A commitment-shaped record carries a customer and a performer, both people rather than teams; what would count as satisfied, in words, agreed at the time it was made; the act that opened it and the act that closed it; and — where it matters most — which other commitment it was made in service of. That last field is the one nobody has, and it is the one that turns a list of work into a network you can trace a delay through.

It has been tried, and how it went

The Coordinator, from Action Technologies in the mid-1980s, was the first product built directly on this. It was email where every message was typed — a request, a promise, a declaration of completion — and it kept track of what was open. Commercially it did not take, and it earned a reputation for making people feel policed. The lesson usually drawn is that the theory failed. The more useful lesson is that asking people to classify every sentence they say, in the tool they cannot avoid using, is a different proposition from letting a team look at how a piece of work is coordinated.

ActionWorkflow followed, in the early 1990s, and put the loop on the screen as a picture: four quarters, two roles, one conversation, nested so that a promise could be made of other promises. The notation outlived the company. This editor draws the same loop for the same reasons.

DEMO, developed by Jan Dietz from the 1990s onwards, is the most thorough version and is still taught. Its move is a hard separation between the acts that coordinate — request, promise, state, accept — and the acts that actually produce something. A transaction is one of each, always between two actor roles, and a business process is those transactions nested. Read a company that way and a great deal of what an org chart shows turns out to be filing.

Agents make it urgent again

When software components only called each other, request-and-reply was enough, and the vocabulary of promises would have been decoration. That stopped being true twice.

The first time was multi-agent systems, where FIPA's agent communication language — and KQML before it — took its message types straight from speech act theory: request, inform, agree, refuse, propose. Not an aesthetic choice. Once a component can decline, the protocol has to have somewhere to put the declining, and a status enum does not.

The second time is now. A model handed a tool and a goal is a party in a conversation for action, and every hard question about it is a commitment question. What exactly was it asked for? What did it undertake — and was it in a position to refuse? When it reports done, who accepts? The answer to the last one had better be a person, because the alternative is a system that both performs and judges its own performance, which is precisely the arrangement the loop exists to prevent.

The line no system crosses

A system can route a request, and cannot make one. It can record an agreement, and cannot agree. It can mark an item complete, and cannot be the person who says this is what I needed — or, more valuably, this is not. A rule can approve. Only a person can promise, and only a person can be disappointed.

This is why automating on top of a broken commitment layer makes the breakage faster rather than smaller. The same unaccountable work moves between the same queues, with better reporting on how long it sat. And it is why an automatic step is worth drawing differently from a human one: not because automation is bad — it is usually right — but because somebody should be able to see, at a glance, which moments of the business have nobody behind them.

Logs are about to be abundant, and the model is not

The old worry about drawing any of this down was that it amounted to surveillance: in the 1980s a tool that asked you to classify what you had promised felt like being watched, and The Coordinator earned its reputation for exactly that. Whatever force the worry had, it has lost. The systems around the work already record it, and agents will record far more: every request, every hand-off, every completion, in more detail than anybody asked for and at a cost approaching nothing.

Which makes the design more valuable rather than less. A record of what happened is only worth something against a statement of what was supposed to happen — otherwise it is a very long list of events with no claim to test it against. Logs are about to be abundant. The model is what is scarce: an explicit account of who is meant to ask whom, what would count as done, and who accepts. That is the thing to hold separately, and to keep worth reading.

And it is worth saying why it is scarce. Everything being built to watch work — activity feeds, telemetry, project tools, and now the traces agents leave behind — records events. A message was sent. A field changed. A tool was called. None of it carries an account of what people are doing when they speak to each other. So none of it can tell a question from a request, or somebody saying a thing is done from somebody agreeing that it is. Enormous sums are going into the recording. What is missing is a theory of what is being recorded.

Such a theory exists and is forty years old. It is the one Winograd and Flores set out. Language is how commitments get made; a small number of acts do all the coordinating; the unit is two people and a promise rather than a task and a status. Every category in this editor comes from it. That is why the drawing is worth keeping separately from the logs — not because the logs are dangerous, but because they have no way of saying what any of it meant.

So the division is not secrecy, it is function. Operational systems hold what happened. This holds what the arrangement is, and stays small and honest enough to be argued with. Keeping them apart is precisely what lets you put one against the other and find out where the design and the reality have come loose.

If you are designing something

Three questions get most of the value without adopting anything. For each state in your workflow: which moment of which loop is this, and who is waiting? For each notification: is this reporting a fact, or is it making a request of somebody, and if it is a request, does the design let them decline it? And for the one that stings: can a piece of work in this system be closed by the person who did it?

What it costs and what it buys is the same argument from the point of view of the team rather than the schema.