AssayAssay
01 / 08

Lesson 01 · Framing · 12 min

Reading a process

Scope

This course is educational — not legal, clinical, or compliance advice. The regulatory references let you check the primary source yourself; they change over time, vary by jurisdiction, and their applicability depends on facts specific to your deployment. Treat the citations as a starting point for your own counsel, not a substitute for it.

Every real process contains two kinds of step. Some are genuinely open — how to phrase a reply, which of several routes to investigate, what to ask next. Others are fixed by something outside the model: a regulation, an audit requirement, a liability boundary.

Sorting steps into those two piles is the first design act, and it decides the shape. Fixed steps belong in structure — a node, a precondition, a check. Open steps belong wherever the model can be trusted to improvise.

  • What must happen before this action, every time, without exception?
  • What must never happen, regardless of how reasonable it looks in the moment?
  • Who is accountable for this decision, and can the agent hold that accountability?
  • If this went wrong, what would someone need to see to understand why?

The last question is the one teams skip, and the one that decides most architectures. If a regulator, a clinician or a customer may ask months later why a decision was made, the trace is part of the product — and that pushes you towards explicit structure whether or not the task needs it.

The lab holds six blueprints. Each names its shape and says why. Read the reasons before running anything: in every case the shape follows from a constraint, not from taste.

A useful heuristic: if a wrong answer costs money, use a graph. If it costs a retry, a loop is fine. Most support work is the second; most regulated work is the first.

Checkpoint

Pick two blueprints with different shapes and say what constraint drove each choice.

Order support at volume

High-volume order support, where the engineering problem is cost per resolution rather than difficulty. Most contacts are simple; a few are not, and the two must be handled differently.

loop — The tasks are individually simple and highly varied, so the flexibility of a loop is worth more than the guarantees of a graph — with a hard stop before anything touching money.

“Where is order 41902?”

Good handling: One lookup, then an answer citing the carrier and expected date. One tool call is the whole job.

Read each blueprint's shape and reason before running it. Notice that no two industries chose the same shape for the same reason.

Rules this agent must obey

Looked the order up

An invented delivery date is a promise the business then has to keep.

Resolved within 5 iterations

At this volume, cost per resolution is the constraint that decides whether the system is viable.

Promised nothing unsupported

Support language becomes a commitment the operation is measured against.

What goes wrong here

  • Optimising quality until the cost per contact exceeds the human cost it replaced.
  • Inventing delivery dates, which converts a support answer into an operational promise.
  • Handling the difficult 5% with the same path as the easy 95%.