Design an AI system that answers open-ended research questions ("compare the 5 main vendors in our market on pricing, security certifications and customer reviews") by searching the web and internal documents, and returns a cited report.

Use an orchestrator with parallel workers. A lead agent plans the research, splits it into independent parts, and starts several subagents that each search one part with their own fresh context and return condensed, cited findings; the lead agent then combines them into the report and checks the citations. It is faster and more thorough than one agent for broad questions, at many times the token cost, so scale the number of subagents to the question and do not use the pattern where the parts depend on each other.

1. Is multi-agent the right call?

• Yes for breadth: 5 vendors × 3 topics are independent searches that can run at once, and each subagent can read many pages without filling the lead agent's context.
• No when every step needs the previous one's result, or all agents must share the same context: most coding work, for example. A single agent is simpler and cheaper there.
• Cost: in Anthropic's own system, multi-agent runs used about 15 times the tokens of a chat. The question must be worth it.

2. Architecture

user question
  ──▶ lead agent: clarify scope, plan, decide how many subagents
        ├─▶ subagent: vendor A (pricing, certifications, reviews)
        ├─▶ subagent: vendor B ...         (in parallel, each with search tools)
        └─▶ subagent: vendor E
  ◀── condensed findings with sources (written to shared storage)
  ──▶ lead agent: compare, find gaps, maybe one more round
  ──▶ citation check ──▶ report

3. Design decisions that matter

• Precise delegation. Each task names the objective, the output format, the sources to prefer and the boundaries ("vendor B only, pricing pages and public trust centres"). Vague tasks make subagents repeat each other.
• Effort rules. Simple fact: 1 agent, a few searches. Comparison: a few subagents. Broad research: more. Without rules, agents overinvest in easy questions.
• Parallel everywhere. Subagents run at the same time and call tools in parallel; this is where most of the speed comes from.
• Results to storage, references to the lead. Subagents write full findings to files or a store and return short summaries, so detail is not lost in retelling.
• Citations as data. Every claim carries its source URL and quote; a final pass checks that each citation supports its sentence.

4. Reliability

• Agents are stateful and errors compound, so save state at checkpoints and resume from there instead of restarting a long run.
• Limits per run: maximum subagents, tool calls and tokens, and a time budget.
• Treat web pages as untrusted: search results can carry instructions, so subagents have read-only tools.

5. Evaluation and release

• Start early with about 20 real questions; changes in this kind of system have large effects, visible even in small samples.
• An LLM judge with a rubric (factual accuracy, citation accuracy, completeness, source quality), checked against human review.
• Trace every run (plans, delegations, tool calls) to see why a report went wrong.
• Roll out new versions gradually, keeping old and new running, so long-running research is not cut off mid-way.

What interviewers want: when multi-agent is worth its cost and when it is not, the orchestrator-worker structure, precise delegation and effort scaling, parallelism, storage instead of telephone, citation checks, checkpoints and limits, and small, early, rubric-based evaluation.