Designing a System That Has a Model In It

• Interpret — the only step that needs a model. Free text to a closed set of intents, which is a judgement with no crisp rule.
• Plan — sequencing over a fixed tool set with a step budget. Note that plenty of features do not need this at all: one interpretation and one call is a complete design and usually the right one (Single Agent and When Not to Use Multi-Agent in the agentic domain make the same argument from the other side).
• Tool interface — the trust boundary. Everything upstream is input; everything downstream is your system (Designing a Tool Interface).
• Domain service — the policy, deterministic and pure, testable without a model and readable by the people who own the rule (Domain Services).
• Escalation — a first-class path, not an error handler. It will carry more traffic than anyone estimates (Approval Gates and Risk Classes in the agentic domain owns the mechanics).

1// what the model produces — a request, never an authorization
2type RefundIntent = {
3  kind: 'full' | 'partial' | 'shipping_only'
4  orderId: string
5  amount: Money
6  statedReason: string        // free text, for the human, never parsed for rules
7  confidence: number
8}
9 
10// what the domain produces — the only thing billing accepts
11type RefundDecision =
12  | { allowed: true; amount: Money; rule: 'within_cap' | 'goodwill_approved' }
13  | { allowed: false; reason: 'over_cap' | 'window_expired' | 'method_ineligible' }
14 
15// pure. no model, no network, no I/O. this is what finance reads.
16function evaluate(order: Order, intent: RefundIntent, now: Date): RefundDecision {
17  if (intent.amount.gt(POLICY.cap)) return { allowed: false, reason: 'over_cap' }
18  if (daysSince(order.paidAt, now) > POLICY.windowDays) return { allowed: false, reason: 'window_expired' }
19  if (!POLICY.refundableMethods.has(order.method)) return { allowed: false, reason: 'method_ineligible' }
20  return { allowed: true, amount: intent.amount, rule: 'within_cap' }
21}

The named rule on the allowed branch is what makes the audit query writable — the reason is an enum the database can group by, not a paragraph. And statedReason is deliberately never read by evaluate: the moment a rule branches on model-generated prose, the prose is business logic (Business Logic Hiding in a Prompt).