Customer support agent with approved refunds
Routes support requests, answers from a policy knowledge base, and issues refunds only after a person approves.
router risk high v1 customer support seed
Why this topology
- interactive-latency: only workflow or router (interactive latency)
- high-risk-no-autonomy: autonomous topology removed (risk is high)
- prefer-workflow: agentic topologies removed (the task is not open-ended)
- autonomous-needs-consent: autonomous topology removed (autonomy is act_with_approval)
- multiple-task-kinds: router (3 request kinds)
Mandatory controls: human_gate input_filter audit_log retrieval
Flow
- classify → Request router · 600 in / 50 out
- answer → Answer writer · 2500 in / 400 out
Diagram source (Mermaid)
flowchart LR
io_in(["request"])
io_out(["response"])
c_router_model(["Request router"])
c_answer_model(["Answer writer"])
c_policy_kb[("Policy knowledge base")]
c_orders_tool[["Orders API"]]
c_refund_gate{{"Refund approval"}}
g_pii_filter>"input_filter"]
g_audit>"audit_log"]
io_in --> c_router_model
c_router_model --> c_answer_model
c_answer_model --> io_out
g_pii_filter -.-> c_router_model
g_pii_filter -.-> c_answer_model
g_audit -.-> c_orders_tool
Components
| id | name | kind | role | model / tool / framework |
|---|---|---|---|---|
| router-model | Request router | model | classify the request as order help, policy question or refund | claude-haiku-4-5 |
| answer-model | Answer writer | model | write the customer answer from retrieved policy text | claude-sonnet-5-5 |
| policy-kb | Policy knowledge base | retrieval | policy and order-help articles | |
| orders-tool | Orders API | tool | look up orders and issue refunds | |
| refund-gate | Refund approval | human_gate | a support lead approves every refund |
Guardrails
| id | kind | protects | what it does |
|---|---|---|---|
| pii-filter | input_filter | router-model, answer-model | Redacts card numbers and national ids before any model sees the text. |
| audit | audit_log | orders-tool | Every order lookup and refund is logged with the request id and the approver. |
Failure modes
| failure | component | mitigated by |
|---|---|---|
| A refund request is routed to the plain-answer path and the customer is told it is done. | Request router | refund-gate |
| An answer quotes a policy that has since changed. | Policy knowledge base | audit |
| Personal data reaches a model or a log. | Answer writer | pii-filter |
Threats
| OWASP | component | mitigated by | note |
|---|---|---|---|
| LLM01 Prompt Injection | Answer writer | pii-filter | customer text is untrusted input |
| LLM02 Sensitive Information Disclosure | Answer writer | pii-filter | personal data in prompts |
| LLM06 Excessive Agency | Orders API | refund-gate | write access to orders |
Eval plan
| metric | method | threshold |
|---|---|---|
| routing accuracy | 200 labelled tickets, rerun on every prompt change | >= 0.95 |
| refund-gate coverage | replay of refund requests; no refund without an approval record | 100% |
Observability and deployment
- traces per request
- cost per request
- approval latency
- refund approvals and rejections
container behind the support portal · The gate is a queue in the support tool, not a model.
Estimated cost
$0.0098 per request · $1477.50 / month at 5000 requests/day · ~6.63 s end to end
Prices as of 2026-10-01 · source · latency is assumed.
- token counts per step are estimates written with the blueprint and approved by the owner, not measurements
- steps run one after another, so parallel branches make the latency an overestimate
- latency uses an assumed time to first token and output speed per model
- 30 days per month and the stated requests per day
Runnable starter
No starter is offered: no API data for langgraph from Radar yet.
Changelog
- v1: seed