The round is not testing whether you can draw the boxes. It is testing the order you do things in — and whether a number ever leaves your mouth before a box does.
“Design a support agent for a mid-size SaaS.” Everyone draws roughly the same diagram, which is why the diagram is not what separates people. What separates them is the ten minutes before it and the fifteen after.
Derive a number out loud early — volume, latency budget, cost per task — and let it pick the architecture. Candidates who start from boxes end up defending them. Candidates who start from constraints end up with boxes that were never really in question.
The questions that actually change the design
Four, and they are worth the first few minutes. Anything else you can assume out loud and move on.
- Volume and shape. Tickets per day, and how peaky? This picks sync versus queued, and whether you need provisioned capacity.
- What is it allowed to do? Draft only, or send? Refund? This is the single biggest fork — a read-only agent and an acting agent are different systems with different review requirements.
- Latency budget. A human waiting is a different design from a ticket answered within the hour.
- Where does the knowledge live, and how stale can it be? This decides the retrieval story and the reindex cadence.
Then say your assumptions plainly: 20,000 tickets a day, roughly 60% answerable from documentation, drafts auto-sent for low-risk categories, sixty seconds is fine.
Do the arithmetic before you draw
This is the part most candidates skip and the part interviewers remember. Take a per-ticket token estimate and run it.
| Assumption | Value | What it decides |
|---|---|---|
| Tickets per day | 20,000 (~0.25/s average, ~0.7/s peak) | Low enough for queued processing; no exotic scaling |
| Tokens per ticket | ~1,500 in, ~400 out | Retrieved context dominates — caching will matter |
| All on a mid-tier model | ~$0.007/ticket → ~$4.2K/month | The naive baseline you quote first |
| 60% routed to a small model | ~$0.005/ticket → ~$2.9K/month | Justifies the triage step as an architectural choice |
Now the triage box on your diagram is not decoration — it is a third of the bill. That is the difference between a diagram and a design, and it took ninety seconds. See cost and latency for the fuller version, and tiered model routing for how the triage step is actually built.
Then draw it
Where they will push, and what a strong answer sounds like
| The probe | Weak | Strong | |
|---|---|---|---|
| 1 | “Why a separate triage step?” | “It’s cleaner.” | “It moves 60% of traffic to a model that costs a third as much — about $1.3K a month here — and it gives me a place to reject out-of-scope tickets before spending anything.” |
| 2 | “What if it takes fifteen tool calls?” | “Add a step limit.” | “A cap, yes, but first I’d look at why: usually ambiguous tool descriptions, so the model tries everything. Then dedupe repeated calls and summarise observations so the context stops growing.” |
| 3 | “Which actions need approval?” | “Anything risky.” | “Score each action on reversibility and measured accuracy. Auto-send replies. Refunds above a threshold and anything to a new contact go to a human. The gate is topology, not a prompt instruction.” |
| 4 | “How do you know it works?” | “We’d evaluate it.” | “A golden set of 200 real tickets with expected outcomes, scored offline on every change; deflection rate and escalation rate in production; and traces I can read when one goes wrong.” |
Raise the failure modes before they ask
Naming a weakness in your own design reads as experience. Waiting to be caught reads as the opposite. Three worth volunteering — and the full catalogue is worth reading before an onsite:
The knowledge goes stale and nothing tells you
Answers stay confident while pricing and policy move underneath. The fix is a reindex pipeline with a freshness metric you alert on — not a quarterly reminder.
Retrieval is the bug you will misdiagnose
When the answer is wrong, check whether the right passage was retrieved before touching the prompt. Most “hallucination” in a support agent is a boundary in the wrong place — see chunking strategies.
Anything the agent reads can instruct it
A ticket is user-supplied text. If the agent can act, someone will paste instructions into a ticket, so enforcement belongs outside the model — see the injection checklist.
If you have been talking for eight minutes and have not said a number, you are describing a category of system rather than designing one. Volume, latency budget, cost per task, accuracy target — any of them, out loud, early.
Constraints, then arithmetic, then boxes, then the failure modes you name yourself. Every strong answer in this round has that order, and almost every weak one starts at the boxes and works outward until it runs out of time. Practise the first five minutes far more than the diagram — the diagram was never what was being assessed.
The system design framework is free and the right place to start. The depth this round rewards — what belongs on the dashboard, designing the approval gate, the reliability patterns — is in the premium guide, and the follow-ups this round turns into are in the sixty questions.