1. Multi-agent architectures

You have just sketched one agent. Then the interviewer asks: "Would you split this across several agents, and how do they coordinate without losing information?" A multi-agent architecture answers that by handing one task to several LLM agents, each with its own instructions, tools, and context window, plus a rule for who is in charge and how results travel back.

Our running example is a deep research assistant asked how the five largest cloud providers changed GPU pricing and capacity over the last 12 months. A lead agent starts five search agents, one per provider, and each returns a short summary. The principle: split only where the pieces can run without seeing each other's details. Each agent works in a clean context and hands back a short result, so the system covers more ground than one context could hold. The price is more total tokens and new ways to lose information.

Splitting fits when the task fans out into independent pieces (five providers), when raw material such as fetched pages would overflow one context, or when phases need different tools or permissions. It does not fit when steps depend tightly on each other, when the task fits in one context, or when you only want a different prompt for one step. Then one agent is cheaper and easier to debug.

This question comes up in most agent design rounds, usually for 5-10 minutes of a 45-minute round and longer when the prompt is a research agent. A mid-level candidate names the reasons to split and the main patterns. A senior candidate quantifies the token cost, says who owns control and state, and designs what passes between agents. The chapters follow the order the interview does.