A business is a network of commitments. Draw yours, and see it flow.

A plan looks fine on the page. What it actually asks of people — who waits on whom, who cannot say no, what gets finished and never accepted — you find out by living through it, once, at everybody's expense. The moves are the ones you already make: asking, agreeing, declining, countering, reporting it done, and saying yes, that was what I needed. Those are built in. What you design is how they connect — which act sets off which conversation, and what reports back to whom.

Draw a process as promises between named people

4-loop is a free browser tool for drawing the few conversations a piece of work turns on as promises between named people, and then running them. It is not a tracker: nothing here follows real work or keeps a record of it, and drawing all of it would be a worse tool rather than a fuller one. The acts arrive one at a time, and a work inbox shows whose day it is: what is on each person's plate, who they are waiting on, and the day each thing has to be done by. A process is designed from above and lived from below, and this is the view from below.

Or train people on it, one part at a time

It will also write a network out as a training session, so a chatbot can facilitate it one moment at a time while one trainee takes a part — written in your browser, shown to you, and sent nowhere unless you paste it. There is a runner built for that text on claude.ai, and it receives nothing until you do.

Every commitment is a loop with four moments

Every commitment is one loop with four moments — the request, the agreement, the report that it is done, and the customer declaring themselves satisfied — and a loop is finished only when it gets back to where it started. The notation comes from the language/action perspective and the conversation for action described by Terry Winograd and Fernando Flores. What a run shows that a board of tasks cannot: who is waiting on whom, which promises were never actually asked for, which moments no person stands behind, and where a date comes from.

An instrument for designing systems, not for running them

It is an instrument for designing systems rather than for running them: you draw how the coordination is meant to go, run it, and take what the design asks of people into the design and into the conversation. Everything around the work already records what happened and agents will record far more, but almost none of that machinery has a theory of what people are doing when they speak — it can tell you a message was sent, not that somebody was asked. This is where the account of what was supposed to happen lives. Nothing you draw leaves your browser, and an annotated example network opens in a click.

The writing

• Only a person can promise — A machine can do the doing. Asking, being free to refuse, and saying yes, that was it are the parts that stay with people — and they are what holds a business together.
• Run it before anybody lives in it — A drawing is read once. Running it shows whose day it is, who is waiting on whom, and what the design quietly asks of the people in it.
• Where a promise comes apart — The vague request, the agreement nobody actually made, the silence in the middle, and the closure that never comes — one failure for each quarter of the loop.
• Two people agreed to different things — Marketing heard we'll deliver these features. Development meant we'll try if technically feasible. What a map can hold of that, and what it cannot.
• When the only answer is yes — A yes is only a commitment if no was available. The moves that keep an agreement honest, and how they quietly disappear.
• What it costs and what it buys — Fewer stalls, clearer ownership, less rework — and the honest account of what goes wrong when this is imposed rather than offered.
• Business runs on commitments — Hiring, offers, roadmaps and support are all promises between people — and most of them are never said out loud.
• Language is how commitments get made — Speech acts, conditions of satisfaction, and the conversation for action — where this comes from, and the objection worth taking seriously.
• The vocabulary — Thirty-six terms, defined the way this notation uses them: request, offer, decline, revoke, conditions of satisfaction, breakdown.
• What a process diagram leaves out — BPMN says what happens and in what order. It is silent about who asked, who was free to refuse, and who says it was what they wanted.
• What it does to software — Data models track payloads; commitment models track who owes what to whom. The Coordinator, ActionWorkflow, agent protocols, and what changes in a schema.
• The drawing says what to build — Every moment is somebody's affordance or a delegation — and that partition is a specification.

All of the writing