"Design a customer-support agent for us." The weak answer starts drawing boxes. The strong answer starts by asking whether it should be an agent at all — and then walks a structure that makes every later decision look deliberate. This final lesson is that structure: six steps that turn everything in this course into a forty-minute answer, plus the two closing sentences that make you sound like someone who has shipped one.
The structure that carries any agent design round
| # | Step | The question you're answering |
|---|---|---|
| 1 | Agent or workflow? | is the path genuinely unknown in advance? |
| 2 | Goal, scope, tools | what outcome, within what boundaries, using what? |
| 3 | Autonomy & safety | what may it do alone, and what must a human approve? |
| 4 | Control flow & context | how does it loop, remember and stay bounded? |
| 5 | Quality & operations | how do you know it works — and keep knowing? |
| 6 | Cost, scale, rollout | what does it cost, what breaks at 10×, what ships first? |
1 · Does it need an agent at all?
Open here. It takes thirty seconds and immediately separates you from the candidates who start with frameworks. If the steps are the same every time, say so and propose a workflow with LLM calls inside.
In most real briefs the honest answer is both: route the predictable majority (FAQ-style questions) through a cheap fixed pipeline, and send only genuinely open-ended cases to the agent. Naming that split early makes every cost discussion later much easier.
2 · Goal, scope and tools
Goal: an outcome, not a question — "resolve the ticket", not "answer politely". Scope: say what's explicitly out of it (legal disputes, pricing negotiation, anything regulated) — an agent without boundaries will cheerfully attempt them. Tools: the minimum set, each with a description that says when to use it and what it is not for. Include the tool everyone forgets: escalate_to_human(summary).
3 · Autonomy and safety
Present the ladder explicitly (lesson 10): reads free; writes within code-enforced limits; high-impact actions proposed for human approval; catastrophic actions not given as tools at all. Then say the sentence that lands: limits live in the tool code, not the prompt — ownership checks, amount caps, rate limits, plus a kill switch and audit logging.
Add one line on indirect prompt injection: tool output and user content are untrusted data, and least privilege is what makes a successful injection harmless.
4 · Control flow and context
Pattern: ReAct for open-ended cases; Plan-and-Execute if the human should approve a plan first. Bounds: step limit, cost budget, escalation carrying the trace. Persistence: checkpoints if runs must survive restarts or pause for approval. Context: goal verbatim, recent observations verbatim, older trajectory compacted with ids preserved; long-term facts stored externally and retrieved when relevant.
5 · Quality and operations
Test set of real tasks with mocked tools, asserting outcome and trajectory — right tools, bounded steps, no unsafe calls — including failure cases (tool down, empty result, out-of-scope, ambiguous input). Tracing from day one. Production metrics: success rate, steps per task, intervention rate, cost per task, unsafe-action rate — with alerts on the leading indicators, because an agent struggles before it fails. Every real failure goes back into the test set.
6 · Cost, scale and rollout
Cost: agents multiply LLM calls, so quote cost per task and name the levers — route simple work away, bound steps, compact context, use a cheaper model for sub-tasks, cache repeated tool results. Scale: what breaks at 10× — LLM rate limits, tool backends, checkpoint storage, human approval throughput (approval fatigue is a scaling limit, not a detail). Rollout: suggestion-only first (human sends), then autonomous reads, then small autonomous writes — autonomy earned from measurements, not assumed at launch.
Selection-round radar: agent design rounds are graded on four things: did you question whether an agent is needed, did you define the autonomy ladder, did you say how you'd test a non-deterministic system, and did you name your trade-offs. A beautiful diagram missing any one of those scores mid.
A worked example, compressed
"Design an agent that resolves IT helpdesk tickets." — Agent or workflow: both; password resets and known-issue lookups are workflows, genuine troubleshooting is agentic. Goal & scope: resolve or triage a ticket; out of scope: procurement, HR issues, anything needing physical access. Tools: search runbooks (RAG with citations), check ticket history, query device status, reset password (own account only, code-enforced), install software (approved allow-list, requires approval), escalate to human. No account deletion — file a ticket instead. Autonomy: reads free; password reset autonomous with ownership check; installs need approval; nothing irreversible. Control flow: ReAct graph, tools cycle, interrupt before install, 8-step limit, budget per ticket, escalation with the trace attached. Context: ticket text and user's device profile injected; prior tickets for that user retrieved as long-term memory. Quality: 30 real tickets with mocked tools; assert resolution, tool correctness, ≤6 steps, no unsafe calls; failure cases included. Ops: tracing, resolution rate, steps per ticket, escalation rate, cost per ticket, weekly human audit. Rollout: suggest-to-technician for a month, then autonomous on the top three ticket types.
Common mistakes
- Starting with a framework instead of with the requirement.
- No autonomy ladder — treating the agent as uniformly autonomous.
- No answer for "how would you test this?" — fatal for a non-deterministic system.
- Only the happy path; no tool failures, no escalation, no budget.
- Multi-agent by default, when one well-scoped agent would do.
- No MVP-vs-later split, so the design sounds like a year of work.
Quick recap
| Step | Say this |
|---|---|
| 1 Agent? | fixed path → workflow; route simple traffic away from the agent |
| 2 Scope | goal as an outcome, explicit out-of-scope, minimum tools + escalation |
| 3 Safety | autonomy ladder by reversibility; limits in tool code; audit + kill switch |
| 4 Flow | ReAct, step limit, budget, checkpoints, compacted context, goal verbatim |
| 5 Quality | mocked-tool tests on outcome AND trajectory; tracing; leading-indicator alerts |
| 6 Close | cost per task, what breaks at 10×, MVP now vs later, autonomy earned |
Practice Zone — PYQs from real selection rounds
Six MCQs and two heavyweight tasks — the full e-commerce support agent design, and a postmortem for an agent that refunded ₹40,000 in an hour.
What should you establish first in an agent design interview?
Asked in
Which requirement most reshapes an agent's architecture?
Asked in
How should an agent design handle a tool that is slow (30s) or unreliable?
Asked in
What's a sensible MVP for an agent product?
Asked in
How do you control agent cost in production?
Asked in
How should you close an agent design answer?
Asked in
Design tasks:
"Design a customer-support agent for an e-commerce company." Give the complete structured answer.
Asked in
Incident: your agent refunded ₹40,000 across 22 orders in one hour after a customer pasted a message containing hidden instructions. Write the root cause and the prevention plan.
Asked in
FAQ
What if I've never built an agent professionally?
Build one small one — two tools, a bounded loop, a mocked-tool test — and speak from it. "My agent kept calling the wrong tool until I rewrote the descriptions to say what each was NOT for" is worth more than any framework list, and it's a weekend of work.
How long should a design answer be?
Cover all six steps in about ten minutes, then go deep wherever the interviewer pushes. Spending twenty minutes on tool schemas and never reaching safety or evaluation reads as narrow.
I've finished all 12 lessons. What now?
Drill the company-wise agent PYQ pages like mock interviews, then take the MCP course — the protocol layer underneath most of what you'll build next.
Course complete. Now prove it — Company-wise agent PYQs: start with TCS →