4-loop The agreements work runs on

Reading

What it does to software

A status column, read as speech Four familiar ticket statuses on the left — pending approval, in progress, done, and blocked — each pointing to what it actually means in a commitment: somebody has been asked and has not answered, somebody promised, somebody said it was done which is not the same as anybody accepting it, and a promise is waiting on a promise nobody drew. what the system says what was actually said, and by whom Pending approval In progress Done Blocked Somebody has been asked Somebody promised Somebody said it was done A promise is waiting on a promise and has not answered — the agreement which is not the same as anybody accepting it that nobody drew Every one of them has a name taken off it.

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.

This has been built before

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. It asked a great deal: name what you are doing with every sentence, in the tool you cannot avoid using, all day. That is a heavy thing to ask of anybody, and it is a different proposition from a team sitting down to look at how one piece of work is coordinated. The idea was sound; the demand it made was too large, and made in the wrong place.

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.

An obligation is not a fact about a record

The reminder, the digest, the ticket a rule assigned at 3am, the dashboard going amber: every one of them rests on the same assumption. Something already knows who needs to do what, and by when.

Almost nothing does. A system can see that a field changed, that a threshold was crossed, that a message has gone unread for six days. From that it infers an obligation and puts it in front of a person. But an obligation is not a property of a record. It is something two people arrived at, in words, and no amount of activity data reconstructs it — which is why so much of it is ignorable, and why everybody has become expert at ignoring it.

What that costs, and what the same delay reads like when the alert has two names in it instead of an instance number, is in what a process diagram leaves out.

Agents make it urgent again

A model handed a tool and a goal is a party in a conversation for action, whether or not the design admits it. Every hard question anybody asks about one turns out to be a commitment question in other clothes: what was it asked for, in words; was it in a position to refuse; and who accepts what it produces. The protocols worked this out before the models did — only a person can promise has that history and the argument at length.

The last of the three is the one a schema settles. A record that carries a status and not a customer has nowhere to put an acceptance, so a completion flows onward as a fact, and there was never a moment at which somebody could have said no, that is not it.

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.

Which is why an automatic step is worth a different mark on a drawing from a human one. Not because automation is suspect — it is usually right — but because somebody should be able to see at a glance which moments of the business run by rule, and which person each rule is acting for. Nobody performs them; somebody is still answerable for them, and those are different facts.

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

The old worry about writing 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 model more valuable rather than less. Everything built to watch work 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, and the one every category here comes from is forty years old.

So the division is not secrecy, it is function. A record of what happened is worth something only against a statement of what was supposed to happen: operational systems hold the first, and this holds the second. Keeping them apart is precisely what lets you put one against the other and find 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.

Does this match how work goes where you are? Tell me where it does not.

Run a process map One already drawn, running act by act, with the work inbox beside it. No account, nothing to install.