Worked Example — A Refund Agent Without Giving the Model a Wallet
Evidence boundary: This is a synthetic architecture demonstration. It is not a deployment report, benchmark, model evaluation, security assessment, or claim of measured improvement. No model or payment-processor calls were made. The evidence here is traceability from canon principle to proposed control and deterministic acceptance case.
The Synthetic Brief
Northstar Outfitters wants an AI-assisted support workflow for ordinary refund requests. Its synthetic policy says:
- returns are normally eligible within 30 days;
- the authenticated customer must own the order;
- a local refund threshold of $50.00 USD may use customer confirmation instead of staff review;
- policy exceptions require human review; and
- a refund is complete only after authoritative processor readback.
The $50.00 threshold is illustrative, not a recommendation. Real thresholds belong to the organization’s approved policy, risk model, permissions, and jurisdiction.
The Tempting Demo
Give the model the customer message, order record, refund policy, and a refund tool.
Let it decide eligibility, select the order and amount, call the tool, retry failures,
and reassure the customer that the refund is complete.
It is wonderfully short. It has also quietly assigned policy enforcement, authorization, transaction control, recovery, and truth itself to autocomplete. Splendid demo; terrible cashier.
What the Demo Fails to Control
| Defect | Consequence |
|---|---|
| Policy interpretation and money movement occur in one probabilistic step. | A plausible reading becomes an irreversible action without an independent policy gate. |
| Customer text and retrieved content share the model’s instruction surface. | Untrusted text can influence tool selection or arguments. |
| The model selects customer ID, order ID, currency, and amount. | Cross-account or wrong-amount refunds can be proposed even when the prose sounds correct. |
| A timeout invites the model to retry the mutation. | One request can become two refunds. |
| Tool acknowledgment is treated as completion. | The assistant can announce success before settlement exists in the system of record. |
| No per-case or aggregate budget is enforced. | A loop, attack, or policy error can become a denial-of-wallet event. |
| No durable proposal, approval, execution, and reconciliation ledger exists. | Reviewers cannot reconstruct what was authorized, attempted, or verified. |
Canon-Guided Review
| Canon handle | Design consequence in this example |
|---|---|
| Least-Autonomy Decision Ladder | Use the model for intent classification and explanation, not for controls that deterministic policy code can own. |
| Authority Rule | Customer text and retrieved documents are data, not authorization. Identity and permissions come from the authenticated session and system of record. |
| Tool and Action Contract Model | Define preconditions, typed inputs, approval state, budgets, idempotency, postconditions, and breach behavior before exposing a mutation. |
| Approval Flow Matrix | Route routine, bounded cases to exact customer confirmation and exceptions or higher-value cases to human review. |
| Confirmation Gates | Confirmation must show the exact order, amount, currency, destination, and policy basis immediately before execution. |
| Post-Execution Truth and Payments and Refunds | A processor response is evidence of an attempt; authoritative readback and reconciliation determine the user-facing state. |
| Transactional Tool-Use Evaluation Model | Test authorization, payload integrity, duplicate handling, timeout recovery, and verified final state separately from response fluency. |
Revised Architecture
flowchart TD
A[Untrusted customer message] --> B[Authenticated support session]
B --> C[Model: classify intent and draft explanation]
B --> D[Scoped order read]
E[Versioned refund policy] --> F[Deterministic eligibility engine]
C --> F
D --> F
F --> G[Typed refund proposal]
G --> H{Pre-action gate}
H -->|Routine and within local threshold| I[Exact customer confirmation]
H -->|Exception, higher risk, or policy ambiguity| J[Human review]
I --> K[Deterministic refund wrapper]
J --> K
K --> L[Payment processor]
L --> M[Authoritative status readback]
M -->|Reconciled| N[Ledger + verified success message]
M -->|Pending or unknown| O[Reconcile, wait, or escalate]
In plain language, the model may recognize the request and explain the result. Authenticated systems supply identity and order scope. Deterministic code decides ordinary eligibility, constructs the only executable payload, applies the budget and idempotency rules, and verifies final state. A person owns exceptions. The customer sees “complete” only after the source of record agrees.
The Contract Surface
| Contract element | Synthetic requirement |
|---|---|
| Preconditions | Authenticated session; customer owns order; order exists; payment is refundable; policy version is active. |
| Authorization | Order and customer identifiers come from the scoped session and system of record, never from free text. |
| Approval | Exact payload hash is confirmed by the customer for amounts within the illustrative threshold or approved by an authorized reviewer. |
| Idempotency | One stable key binds case, order, amount, currency, policy version, and approval hash. |
| Budget | Per-case amount, daily aggregate, retry count, and tool-call ceilings are enforced outside the model. |
| Postcondition | Processor and order ledger agree on refund ID, amount, currency, and final status. |
| Breach behavior | Fail closed on identity, policy, payload, approval, or budget mismatch; reconcile rather than blindly retry on unknown execution state. |
Synthetic Expected Trace
The following hand-authored trace shows the evidence shape for a routine case. It is an expected artifact, not observed production telemetry.
{
"case_id": "case_778",
"authenticated_customer_id": "cust_44",
"order_id": "ord_1042",
"days_since_purchase": 12,
"proposal": {
"amount": "38.00",
"currency": "USD",
"policy_version": "refund-policy-2026-08",
"approval_route": "exact_customer_confirmation"
},
"controls": {
"ownership_check": "pass",
"eligibility_check": "pass",
"budget_check": "pass",
"payload_hash_confirmed": true,
"idempotency_key_bound": true
},
"execution": {
"attempt_count": 1,
"processor_refund_id": "rf_8831",
"processor_readback": "succeeded",
"ledger_reconciled": true
},
"user_facing_state": "refund_verified_complete"
}
Acceptance Evidence Without Paid Model Calls
The architecture can earn useful evidence before anyone rents a frontier model. Hand-authored JSON fixtures and a stub payment processor are enough for these deterministic cases:
| Case | Expected evidence |
|---|---|
| Cross-account order ID appears in customer text. | Scoped order lookup rejects it before proposal construction. |
| Customer message contains hostile tool instructions. | Message remains data; no authorization or payload field changes. |
| Request needs a policy exception. | Deterministic engine returns human_review_required; no mutation is available. |
| Confirmed payload changes before execution. | Hash mismatch invalidates confirmation and requires a new gate. |
| Same request arrives twice. | Stable idempotency key produces one processor mutation and one reconciled result. |
| Processor times out after accepting the request. | Workflow enters unknown_pending_reconciliation; it does not issue a blind retry. |
| Processor and ledger both confirm the refund. | User-facing state may advance to verified completion. |
| Amount or aggregate ceiling is exceeded. | Budget gate blocks execution outside the model. |
These fixtures do not show that a model will classify refund intent correctly, write a useful reply, resist every attack, improve customer satisfaction, or outperform another system. Those are separate claims requiring separate evidence.
Result
Applying the canon changes the architecture before it changes the prose. The model still contributes flexible language understanding and explanation, but identity, policy, approval, money movement, retry behavior, budgets, and completion truth move to explicit controls.
That is the point of the Guide: not to make an agent sound more certain, but to make certainty unnecessary at the boundaries where mistakes become real.