Four sketches worth knowing from memory

1 · The loop

  STOP: model returns text   ·   CAPS: 12 turns / $0.40 / 30s

  user ==> [ build context ] ---> ( model ) ---> [ dispatch ]
                  ^                                   |
                  |                                   +---> text ---> reply
                  |                                   |
                  +------- result <--- < tool > <-----+
                                         |
                                         !  2 of 11 tools write

  # transcript / this run #  - - ->  [ build context ]

Draw this if you draw nothing else. In eight lines it states who decides (the round box proposes, the square box dispatches), when it ends (two ways: model returns text, or a cap trips), what it can reach (eleven tools, two of them irreversible), and where the working state lives.

What a reviewer takes from it: the loop is bounded, the bounds are in code, and the blast radius is two tools rather than eleven. What they will ask next: what happens when the write tool fails? — which is your cue to add the failure arrow you left off deliberately, because answering with the marker is stronger than having pre-drawn it.

2 · Supervisor + workers

  CAPS: 4 workers max · 8s wall · 30k tok TOTAL (not per worker)

  request ==> [ route ] ---> ( supervisor )
                                  |
                brief: refs + the exact question, not prose
                    |                          |
                    v                          v
             ( worker: stock )          ( worker: contract )
                    |                          |
               < erp x3 >                  < doc search >
                    |                          |
                    +--------> [ merge ] <-----+
                                  |  coverage 2/3 · wh-2 TIMEOUT
                                  |  precedence: entitlement > availability
                                  v
                          ( propose remedy )
                                  |
                                  v
                       [ gate: cost > $250 ? ]

Three details do all the work here, and each one pre-empts a hard question.

“30k tok TOTAL (not per worker)” — the fan-out budget question, answered before it is asked. Per-worker budgets multiply your spend by the worker count, which is the commonest costing mistake in multi-agent designs.

“brief: refs + the exact question, not prose” — states that the boundary payload is designed rather than “we pass the conversation”. That one phrase is the difference between a brief and a telephone game.

“coverage 2/3” and “precedence” written on the merge box — the merge is doing real work with a stated rule, not concatenating. Reviewers who have been burned by fan-in look for exactly this.

3 · State machine + human gate

  [ resolved ] --> [ proposed ] --> [ approved ] --> [ executed ] --> [ closed ]
       |                |                ^               |
       |         cost > $250             |               !  reship + credit
       |                v                |               |
       |          { approver } ~~~~~~~~~~+               +--> [ compensate ]
       |                |   3h 51m later, edited 4 -> 6       ^
       |                |                                     |
       +--> { escalate }+--> [ closed: declined ]             +-- partial failure

  # run state / 1 run, survives suspend #   <=== the checkpoint is here
  # system of record / forever, audited #   <--- credit memo, shipment, approver

The squiggly arrow is the whole reason to draw this one. It says: the run stops here and may resume hours later, on a different process — so state must be durable, and the resumed run re-validates rather than replaying, because prices and stock moved while it waited.

Two more things a good version of this sketch always shows. The approver edited the parameters (4 → 6), so the executed action is not the proposed action — which is why approvals belong in the audit record and not just the run state. And the two stores are drawn with their lifetimes, making it obvious that the financial fact lives in the business’s ledger and the agent holds the checkpoint.

4 · The trust-boundary overlay

  ,- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -,
  | INSIDE: our identity · our VPC · no general outbound internet |
  |                                                               |
  |  [ build context ] ---> ( model ) ---> [ dispatch ]           |
  |         ^                                   |                 |
  |         |                                   v                 |
  |  # case memory /      < erp >   < doc read >   < mail ! >      |
  |    forever #             |          |             |           |
  '- - - - - - - - - - - - - + - - - - -+- - - - - - -+- - - - - -'
                             |          |             |
   customer mail ============+          |             +=======> customer
   UNTRUSTED                            |                       EGRESS
                                        |
              supplier PDFs ============+
              UNTRUSTED

  LEGS: private data (ERP + case memory)
      + untrusted content (mail, PDFs)
      + external comms (mail out)          = all three

This is the same system with one dashed line added, and it is the first move of a threat model. The dashed enclosure says what holds the boundary — identity, network, sandbox — because “inside” is meaningless without naming the mechanism.

Then every double arrow is a crossing, and the label under the box names the three trifecta legs. Drawing it forces the count, and the count is the finding: all three legs present means the design needs a stated containment answer, not a promise to be careful. In a review, arriving with this overlay already drawn changes your role from defendant to co-investigator.