1. Multi-agent systems

"When does splitting work across several agents help, and when does it just add failure points?" This question tends to follow an agent design in AI engineer and forward-deployed interviews. A multi-agent system splits one LLM (large language model) task across several agent loops, each with its own instructions, tools, and context, coordinated by one agent or passed from one to the next. The interviewer is checking two things: whether you know the patterns that work, and whether you would argue against splitting when it does not help.

Expect 5-10 minutes on it, mostly at companies building AI products. A mid-level answer names the orchestrator-worker and handoff patterns and explains why isolated workers help. A senior answer also designs what passes between agents, decides who owns shared facts, and estimates how much a split multiplies tokens and failure points.

The running example is the support assistant of a B2B (business-to-business) invoicing SaaS (software as a service) product. Most tickets, like "reset my password", need one agent and one tool call. A billing dispute like "why was I charged twice in March?" needs three sources: the billing ledger, the payment-webhook logs, and the help-center policy docs. The raw content from those three sources totals about 90k tokens.

Splitting the work is useful here because the lookups are independent and their raw output would fill too much of one context window. The password reset, or any coupled task that fits easily in one context, stays with one agent, because every split adds tokens and a failure point.

The assistant also routes account and refund questions from a triage agent to a billing specialist. This tutorial assumes the single-agent loop (the model picks a tool, reads the result, and repeats until done) from Agents.