Part 4 of 6 · 6 min read
Interview questions and limits
Covers: Interview questions, with the follow-ups; Common mistakes; What the example does not do.
Interview questions, with the follow-ups
When would you use multiple agents instead of one?
"When the work splits into independent branches that can run in parallel, when one agent's context or tool list is too large to work reliably, or when different parts need different tools or models. I would not use them for tightly coupled work, because the latency gain disappears and every dependency becomes a handoff that can lose information. In my model, independent sub-tasks ran at 0.23 of the single agent's latency, and a dependent chain ran at 1.46." Follow-up: "How do you decide?" I count the levels and edges of the task graph, estimate the shared background, and then measure tokens, latency and accuracy against a single-agent baseline on real tasks.
Why can a multi-agent system cost more tokens?
"Each worker pays for its own system prompt and a copy of the shared background, may repeat work because it does not see the whole picture, and the orchestrator pays for briefs and results. Anthropic reported about 15 times the tokens of chat for its research system. Against a single agent it depends on caching: without one, short worker contexts are cheaper, and with one, the single agent's long context is cheap and the split costs more for small tasks or a large shared background; in my model the ratio crossed 1.0 at about 10,000 tokens of shared background." Follow-up: "What do you do about it?" Pass pointers instead of copies, return typed results, share a cached prefix across workers, and spend the extra tokens only where the task is valuable enough.
Why is coding harder to parallelise than research?
"Research sub-tasks (search a source, summarise it) mostly do not depend on each other; coding sub-tasks (change an interface, update its callers, fix the tests) share state and depend on each other's output. In graph terms, coding has long dependency chains, so there are few levels to parallelise and many edges to hand over. Anthropic's write-up makes the same point." Follow-up: "What can you still parallelise?" Independent searches, reviews, test runs and exploring alternatives (module 5 of this level).
How would you show that splitting an agent was worth it?
"I would run both designs on the same sample of tasks and compare accuracy, total tokens across all agents, and latency, and report the difference with its spread. I would not accept a better demo as evidence. The parametric model in this module shows why the answer can flip: if the model is robust, the reliability benefit of splitting vanishes for dependent tasks." Follow-up: "What would make you go back to one agent?" A measured accuracy gain below the extra cost, or handoff errors showing up in traces.
Common mistakes
- Splitting by job title ("researcher", "writer", "reviewer") instead of by independence.
- Counting only the orchestrator's tokens.
- Ignoring the shared-context tax, so every worker loads a 10,000-token background.
- Parallelising a chain, and then paying for relays.
- Assuming more agents means more accuracy without a baseline.
- Forgetting the cache when comparing with a single agent.
- Passing facts through the orchestrator as free text (module 8 of Level 7).
What the example does not do
- No models. Reliability uses hazard rates I chose; the direction comes from module 6, and the values are mine.
- A simple graph. Each sub-task depends on at most its three predecessors; real dependency graphs have other shapes.
- Equal sub-tasks. All have the same size; real ones vary, and the slowest sets the latency.
- No retries, no failures, no tool latency.
- Optional real-model experiment (I did not run this): pick ten tasks that you can label as parallel or coupled, run each as a single agent and as an orchestrator with workers, and record accuracy, total tokens from the usage field, and wall-clock time.
Check yourself
Eight sub-tasks, each needing the output of the one before. Does splitting them across eight agents make the task faster? (No. A full chain was 1.46 times slower than one agent in the model, because each handoff adds a step and a chance to lose a fact. Split by independence, not by job title.)
For the curious Why the answer depends on the prompt cache
With no cache, eight independent workers used 0.45 of the single agent tokens. With a cache that makes one long context cheap, the same split used 0.87, and with two sub-tasks it cost more than one agent (1.44). Every size and rate here is an assumption chosen to show the shape, so treat the direction as the lesson.
What you will use daily at work
| Practice | What it looks like |
|---|---|
| Start with one agent | Add a second only when the task, the tools or the coordination outgrow one. |
| Count the dependencies | Many edges between sub-tasks means many handoffs, and each can lose a fact. |
| Measure cost and latency both | A split can cut one and raise the other. |
Draft: confirm your provider token prices and cache rules before using any cost comparison.
What you must be able to say (one page)
- Start with one agent. It is simpler, cheaper and faster, and every extra agent needs extra exchanges that add latency. Add agents only when the task, the number of tools, or the need for coordination outgrows one.
- Three reasons that justify splitting: 1. Parallelism: sub-tasks are independent, so they can run at the same time and cut latency. 2. Context or tool overload: the work does not fit one window, or one agent has too many tools to choose from reliably (for example, 16 tools split across three specialists). 3. Specialisation: different sub-tasks need different prompts, tools or models.
- Reasons against: every sub-agent costs a system prompt, a copy of the shared background, a brief and a result; dependencies between sub-tasks force handoffs, and each handoff can lose a fact. Anthropic's engineering write-up of its research system states the same limits: multi-agent suits heavy parallelisation, information beyond one window and many tools; it is poorly suited when all agents need the same context or when there are many dependencies between them, and it says coding has fewer truly parallel tasks than research. It also reports about 4 times the tokens of chat for an agent and about 15 times for a multi-agent system.
- The deciding quantities are the number of levels (the longest chain of dependent sub-tasks), the number of edges (facts that must cross between sub-tasks), the size of the shared background every worker must load, and whether a prompt cache already makes one long context cheap.
- Quote these numbers, with the caveat that this is a model with assumed parameters (8 sub-tasks of 6 steps; tokens and latency are accounting, reliability uses assumed hazard rates):
- independent sub-tasks: latency 0.23 of the single agent;
- at dependency density 0.5: 0.97; at 0.8: 1.24; a full chain: 1.46 (slower than one agent);
- tokens, no prompt cache: 0.45 of the single agent at 8 sub-tasks, but 1.15 at 2;
- tokens, with a prompt cache: 0.87 at 8 sub-tasks, 1.44 at 2, and it flips above 1 when the shared background is 10,000 tokens or more;
- reliability: with a weak model the split wins at every density; with a robust model it wins only when sub-tasks are independent (0.80 against 0.70) and loses at density 0.5 (0.60 against 0.70).
- One sentence: split by independence, not by job title.