Drill: fix the board

Finding 1 — the box labelled “AI Agent”

Every question the room has is inside that rectangle. Where is the loop? What decides the next step? What is the stopping condition? How many tools, and which ones write? One box has absorbed the entire subject of the review.

Fix: expand it into sketch 1 — build context, model call, dispatch, tools, and the stop condition written above it. If you draw one thing, draw the loop.

Finding 2 — every arrow is bidirectional

Four double-headed arrows say “these communicate” and nothing about direction, sequence, or ownership. A board with no directed arrows has stated no control flow, which means it cannot answer where the run stops or what happens on failure — and often reveals, when you try to redraw it, that nobody had decided.

Fix: one direction per arrow, chosen deliberately. Where something genuinely flows both ways, that is two arrows with two different payloads.

Finding 3 — “Postgres” is a product, not a store

Which of the four stores is it? Almost certainly three of them at once: run state, case memory, and possibly the audit record, in one database with no stated lifetimes. That conflation is how a fact ends up in the wrong place — and how “we cannot prove what was approved” happens.

Fix: replace it with the stores that actually exist, each labelled with a lifetime: # run state / 1 run, survives suspend #, # case memory / forever, expires 18mo #. The product name can go underneath in small letters if anyone cares.

Finding 4 — a framework is on the board as a peer of a database

LangGraph names a library, not a behaviour. It tells the room nothing about who owns control — which is the one thing a framework choice does determine, and therefore exactly what should have been drawn instead of named. This is abstraction debt made visible: the box exists because the author never had to decide what it does.

Fix: delete the box. Draw the control flow it implements, and mention the library in a sentence if the room needs it.

Finding 5 — Salesforce is reached by an arrow with no mark

Does the agent read from it or write to it? If it creates cases, updates opportunities, or mails contacts, that is an irreversible effect with no ! and no failure arrow — the single highest-value omission on this board, because it is where the blast radius lives.

Fix: < sf_create_case ! > with a failure arrow, and a note of what compensation exists. If it is read-only, say so explicitly: a plain arrow that has been confirmed read-only is a different fact from an unmarked one.

Finding 6 — no boundary, and no numbers

Where does untrusted text enter? Presumably through the frontend, and possibly from Salesforce case comments too — both unmarked. There is no dashed enclosure, so “inside” is undefined, and no crossing is distinguished from an internal call.

And there is not a single number: no turn cap, no spend cap, no approval threshold, no volume. A board with no numbers reads as designed but never operated, and reviewers register that even when they cannot name it.

Fix: one dashed enclosure with the mechanism named, double arrows on every crossing, and four numbers — a cap, a deadline, a threshold, a volume.