Case Study: A Refund Assistant

From canvas to production

A hypothetical shop builds a refund assistant. Start node: message, customer ID and locale from the app. Guardrail node: mask card numbers, block injection phrases. Classifier agent (small model, structured output): category, amount, urgent. If/else: refunds over 100 go to a user approval step; others to the refund agent, which has read-only order lookup and a refund tool behind approval. Every path ends in the same output contract. They test with 150 saved inputs, measure routing accuracy and refund correctness, publish version 1, embed it with a chat component, and watch traces and cost per run. The details are illustrative; your policies and numbers will differ.

The workflow sketch

Read top to bottom.

start (input_as_text, customer_id, locale)
 -> guardrail (mask PII, block injection) --blocked--> end(status=blocked)
 -> classifier agent [small model, schema: category, amount, urgent]
 -> if category == refund && amount > 100 -> user approval --reject/timeout--> end(rejected/escalated)
 -> refund agent [tools: get_order (read), issue_refund (approval)]
 -> end(status=answered, reply)

Launch narrow

Start with one request type and a human fallback, then widen once the evaluation and traces look good.

Quick check: In the case study, where are refunds above 100 sent?

• To the guardrail only
• Directly to issue_refund without checks
• To a human approval step before the refund agent acts
• To the end node immediately