Make a refund-issuing support agent reliable

agents, reliability, idempotency

Prompt

Design a customer support agent for a fintech that can issue refunds up to $500 autonomously, talking to real customers over chat, handling thousands of tickets a day. Focus on making it reliable and correct, not just secure.

Interviewer's answers to clarifying questionsopen after you have asked your own

Volume? ~5,000 tickets/day; the refund tool is invoked on ~15% of tickets.
Grounding? Refund policy lives in a versioned internal doc store; the agent must cite the specific policy clause it used.
Ambiguous cases? Any ticket where the agent's confidence is below an internal threshold must escalate to a human, not guess.
Infra? The agent runs as a multi-turn conversation that can span minutes; the LLM provider has occasional multi-minute latency spikes or short outages.
Audit need? Finance wants every refund tied to a ticket ID, policy citation, and full tool-call trace.
Known related failure? A different company's support bot once fabricated a refund policy it never had, and the company was held to it.

Follow-upsafter your high-level design

Two refund requests for the same ticket arrive within a second of each other, a user double-click or a retry. How does your design prevent a double refund?
How do you detect, in production, that the agent is systematically over-refunding one customer segment, before finance notices on the monthly report?
The LLM provider has an outage mid-conversation. What happens to a customer who is halfway through a refund flow?
The policy document changes mid-rollout (a new return window). What's your plan for in-flight conversations that started under the old policy?

Answer first: out loud, on paper, or with the interview prompt above. Then compare with the rubric.