1 · The problem
Resolve cases safely.
The agent must inspect customer state, retrieve order details, decide whether a refund is allowed, and escalate when the policy boundary is reached. The page leads with business intent so candidates understand why each architecture choice exists.
Definition of done
Verified customer, correct order context, bounded refund tool, logged action, and clear escalation path.
2 · Component diagram
What each system part does
Component diagramCustomer support agent
User
Claude Agent
Tool Registry
Ticket / Order DB
Escalation Queue
Cards below the diagram explain each component, the Claude-specific configuration, and the relevant task statements.
PreToolUse hook
Blocks refund calls until customer verification and order lookup are complete.
Case-facts block
Carries stable facts across turns without re-reading the full conversation.
3 · Data flow
One concrete user turn
01
User asks for refund. The system loads account state and conversation facts.
02
Claude requests verification tool. The harness validates arguments and logs tool_use.
03
Order lookup returns result. The response is appended as a tool_result.
04
Policy hook checks refund amount. If over threshold, the flow escalates.
4 · Failure modes
What breaks in production
When it goes wrong.The four most common breakages.
Prompt-only refund limitProbabilistic policy where a deterministic hook is required.
Tool proliferationToo many tools degrade selection and confuse routing.
Missing stop_reason checkThe loop keeps running after the model is done.
Stale case factsThe agent responds using outdated customer state.
5 · Implementation checklist
Stand-up checklist
- Define customer, order, refund, and escalation tools.
- Add PreToolUse guard for verification and thresholds.
- Persist a case-facts block after each state change.
- Log stop_reason, tool latency, and escalation reason.
- Drill common failure modes from the question bank.