Why this build, here
Support in Zambia happens on WhatsApp, and customers expect the business to remember them. An agent that can act (log a ticket) must also know what it may not do alone (give money back). That line is the design.
The build, step by step
List what it may do, ask about, and never do
Three columns. May: answer from manuals, check ticket status, log a new fault. Ask a person first: refunds, replacements, anything over a set value. Never: change prices, promise dates. This list becomes code, not just prompt text.
Give it memory with limits
Store per-customer facts (system installed, open tickets, language preference) separately from the conversation. Load only what this conversation needs, and let customers ask what is stored.
Build the tools and the approval step
log_ticket and ticket_status run directly. request_refund does not run: it creates a pending approval with the agent’s reasoning, and a person approves or rejects it in a simple queue.
Hand over cleanly
When the agent is unsure, or the customer asks for a person, pass the conversation with a two-line summary so nobody has to ask the customer to repeat themselves.
Run ten hard conversations
An angry customer, a refund request dressed up as a question, a customer who changes language halfway, one who asks what you know about them. Record what the agent did in each.
Finished when
- Refunds and replacements can only happen after a person approves
- A handed-over conversation arrives with a summary
- Ten hard conversations are recorded with what the agent did
Read and run
Interview practice
Questions on this topic from AI Engineering Interview Questions, company-wise, with the companies it lists. Write your answer the way you would say it; Jev scores it and DeepSeek tells you what to add.