AssayAssay
05 / 08

Lesson 05 · Three targets · 12 min

Regulating architecture

Architecture fitness asks whether the agent stayed within its intended shape. Did it call the tools it should, in an order that makes sense, and none it should not. Did it reach the answer by a route you would accept, or by a shortcut that happened to land.

This is the target where a right answer is not enough. An agent that issues a refund without reading the policy, and happens to be right, has taken a route that will be wrong next time. The answer passed every maintainability check; the route is the problem.

PreconditionA guide on the tool itself. The refund tool refuses until the policy has been read. Cannot be argued with, because it is code.
Route assertionA sensor on the trace. Did lookup_order happen before issue_refund. Did the policy node get visited. Was a forbidden tool called.
GraphArchitecture as structure rather than check. When the route must not vary, draw it, and the agent cannot leave it.

The industry blueprints are architecture sensors. must_call, must_not_call, order, no_side_effects — every one is an assertion over the trace, not over the answer. The finance blueprint's rule that the transaction must be retrieved before the dispute history is pure architecture: it says nothing about what the recommendation should be, only about the shape of how it was reached.

Trace assertions are underused because teams do not have traces. That is what the observability deep dive is for. Once every run is a span tree, "was tool X called before tool Y" is a query, and architecture fitness becomes something you can check on every production request rather than something you hope the prompt enforces.

When an architecture sensor keeps firing, the fix is usually a guide, not a better sensor. A route the agent keeps taking wrongly is a route that should be closed — a precondition, or a graph edge that does not exist. The sensor told you where to put the wall.

Checkpoint

Name the ordering constraint in the finance blueprint and say what it protects against.

Payment dispute triage

A cardholder disputes a transaction. The agent must gather the transaction record and the customer's history, then recommend an outcome — without moving any money itself.

graph — Every dispute must follow the same evidenced path, and a regulator may ask months later why a decision was made. A fixed route that records itself is worth more here than the flexibility of a loop.

“Customer C-1180 disputes transaction TX-4471 — they say they never made it.”

Good handling: Retrieve both records, note the transaction was card-not-present and not 3DS verified, and recommend upholding with that evidence.

Every constraint in this blueprint is an architecture assertion over the trace. Run it and identify which rule is about the route taken rather than the answer given.

Rules this agent must obey

Retrieved the transaction

A recommendation with no underlying record cannot be defended to a regulator.

Checked dispute history

Pattern is material to a dispute outcome and its absence is a known audit finding.

Did not try to move money

Adjudication is a human decision; the agent recommends only. Attempting the refund is the violation, whether or not it went through.

Gathered evidence before history

The transaction defines the dispute; history only qualifies it.

What goes wrong here

  • Recommending an outcome before retrieving the record, then justifying it afterwards.
  • Treating dispute frequency as proof of fraud, which produces unfair rejections.
  • Producing a recommendation no human can reconstruct six months later.