The order you draw it in

Lesson 3 of 6 in Whiteboarding Agent Systems: Drawing the Thing You Built.

Notation is the easy half. The reason most boards fail is order: people start with the components they built most recently, and the drawing accretes rather than explains. Six steps, always the same, and the property that makes it work is this — each step answers one more question a reviewer will actually ask, so if you are interrupted after any step you still have a coherent board.

The six-step draw order

1 — The request and the reply
Two marks at opposite edges of the board, and the sentence “this system is done when ___” written above the reply. Everything else lives between them. Boards that start with boxes in the middle never recover a beginning.
2 — The loop, and who owns it
The round box, the code box that decides what happens next, and the arrow back. Write the stop condition and the caps ON the board immediately — turns, spend, wall-clock. This is the step that separates a drawing of an agent from a drawing of a pipeline.
3 — Tools, with ! on the irreversible ones
Angle boxes hanging off the dispatch box. Now the board shows the blast radius, and the room can see that of eleven tools, two move money and one sends mail to customers.
4 — Stores, each with a lifetime
Model context, run state, case memory, system of record — whichever exist. The lifetime label is the whole point: it answers “what survives a crash” and “what does this remember about me next month” without anyone asking.
5 — The trust boundary
One dashed enclosure, and a note of what holds it: identity, network, sandbox. Then upgrade every crossing arrow to a double arrow — untrusted content coming in, your data going out. The security review has now started, on your terms.
6 — The failure arrows
One leaving every ! and every fan-out. Where does it go: retry, compensate, degrade, escalate? A board without this step describes a demo, and everyone in the room knows it.
Stop. Do not add more.
The next mark you are tempted to make is usually a component name that adds no decision. Leave whitespace — you will need it for the questions, which you answer with the marker.

Four boards that fail, and the step each one skipped

The cloud-logo board. Vendor icons wired together with plain arrows. It communicates procurement, not behaviour — and it cannot show who decides anything, because a logo has no control semantics. Skipped: step 2.

The box labelled “Agent”. One rectangle containing the entire interesting part of the system. Every question the room has is inside that box. Skipped: step 2, decisively. If you draw only one thing, draw the loop.

The everything-arrow board. Bidirectional arrows between every pair of boxes. Bidirectional arrows are a confession: they mean “these talk” and nothing about control flow, so a board full of them has stated nothing. Skipped: step 2, again — this is what happens when you draw components before deciding who decides.

The happy path. Correct, elegant, and describing a system that has never met a timeout. Skipped: step 6. This is the most common failure among people who genuinely understand their system, which is why the failure arrows are their own step rather than a detail of the others.

One more discipline, and it is the hardest: numbers on the board. Not many — four is plenty, and they do more for your credibility than another five boxes. A cap (“12 turns, $0.40”), a deadline (“8s p95”), a threshold (“approval over $250”), a volume (“3k runs/day”). Numbers are what distinguish a system someone has operated from a system someone has designed, and a reviewer registers their absence even when they cannot say why the board felt thin.

Key terms: blast radius, lethal trifecta, graceful degradation, max turns

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.