Designing an agent that resolves ambiguity

WHAT THIS TESTS The interviewer wants a reasoning loop that separates information gathering from irreversible action, and that knows when to ask the user versus resolve automatically.

A GOOD ANSWER COVERS First, decompose the request into slots: attendee, date or time, and intent to create a calendar event. Detect that attendee Alex is ambiguous and that next week is relative. Resolve what you can deterministically: relative dates should be computed in code from the current date and the user's timezone, not guessed by the model. For the attendee, call the contact lookup API; if it returns exactly one Alex, proceed, but if it returns several, that is genuine ambiguity. Only then ask the user a targeted clarifying question listing the candidates, rather than asking open-ended questions or things the tools already answer. Read-only tools like contact lookup can run freely; the booking call mutates external state, so present the fully resolved plan, who, when, and how long, and get explicit confirmation before executing. Throughout, keep the loop observable so each tool result feeds the next decision.

COMMON WRONG ANSWERS Letting the model hallucinate a specific date or silently pick the first Alex and book immediately. Booking is irreversible and notifies others, so guessing is costly. The opposite error is over-asking, bothering the user with questions the contact API or a date calculation could resolve.

LIKELY FOLLOW-UPS Expect questions on confirmation UX, on handling zero contact matches, on timezone edge cases, on retry and rollback if booking fails, and on logging the resolution chain.

ONE CONCRETE EXAMPLE The agent computes next week as a concrete date range, calls contact lookup, finds Alex Chen and Alex Rivera, and replies, I found two contacts named Alex, Chen and Rivera, which one. After the user picks Rivera, the agent proposes a specific slot, gets a yes, and only then calls the calendar API to create the event.