Single-Agent and Multi-Agent Systems

A single-agent system is one model in one loop with one set of tools and one context. It is the default, and for most tasks the right design.

• Advantages: simple to build, test and debug; one context holds the whole picture; nothing is lost between agents; cheapest in total tokens for small tasks.
• Disadvantages: the context grows with every step; too many tools blur selection; one prompt must cover every role; steps run one after another.
• Use it when: the task fits in a manageable context, needs up to a couple of dozen tools, and its steps depend closely on each other.

Every step in a single agent can see everything before it.

• That shared view is exactly what multi-agent systems struggle to recreate.
• Most 'we need more agents' problems are really 'the context is too long' or 'there are too many tools', which have simpler fixes (modules 3 and 12).
• Exhaust the single agent first.

A multi-agent system uses several agents, each with its own prompt, tools and context, working on parts of one task. It helps in four situations:

• Independent strands: research on five companies that do not depend on each other can run in parallel.
• Context isolation: a side-task that reads fifty pages can be done by a sub-agent that returns one paragraph, keeping the main context clean.
• Specialisation: clearly different jobs needing different tools, instructions or models.
• Separation of duties: one agent proposes and another, with different access, checks or approves.

These are the only good reasons, and each can be tested.

• If the strands depend on each other, splitting them loses the shared view.
• If the context is not actually too long, isolation buys nothing.
• If one prompt can do the job, specialisation is ceremony.
• A second agent should earn its place by parallel speed, a cleaner context, or an independent check.

In a team, each agent has a role: a defined job with its own prompt and tools. The common ones:

• Supervisor (orchestrator, manager): receives the task, breaks it up, assigns the parts, combines the results.
• Worker (sub-agent): does one assigned piece and reports back.
• Router: decides which agent should handle a request, and does nothing else.
• Planner: writes the plan; does not execute.
• Executor: carries out one plan step with tools.
• Researcher: gathers and summarises information; read-only tools.
• Critic (reviewer, evaluator): checks another agent's output against criteria.
• Specialised agent: any agent narrowed to one domain, such as billing or SQL.

A role is useful only if it changes what the agent can see or do.

• A researcher with read-only tools cannot cause damage, whatever it reads.
• A critic that did not write the draft, and has the evidence, reviews better than the writer.
• A router with no tools is cheap and easy to evaluate.
• Roles that differ only in name ('senior analyst', 'junior analyst') add cost and nothing else.

Delegation is one agent giving a sub-task to another. The sub-agent starts with an empty context, so the brief it receives is everything it knows. A good brief states:

• the objective, and the larger goal it serves;
• the context it needs: facts already found, constraints, what to avoid;
• the output format wanted, and its length;
• the tools and limits it has;
• what done means.

A sub-agent cannot see the conversation that led to its task.

• 'Research the competitor' produces a generic essay.
• 'Find Acme's 2025 revenue and headcount from primary sources, for a pricing comparison; return five bullet points with links; stop after six searches' produces what was needed.
• Most multi-agent failures are briefing failures: the worker did a slightly different job from the one intended.

Coordination is how agents avoid getting in each other's way. Task allocation is deciding who does what. Three approaches:

• Central: a supervisor assigns every task and sees every result. Simple and traceable.
• Rule-based: code routes by type: billing questions to the billing agent.
• Market or claim-based: agents pick tasks from a shared list, each claiming one so no two take the same.

Allocation can be static (fixed in advance) or dynamic (decided as the work unfolds).

Without coordination, agents duplicate work, leave gaps and overwrite each other.

• Central assignment is the easiest to reason about and debug, and is the right starting point.
• Claim-based allocation scales to many workers but needs locking, so a task is claimed once.
• Whatever the scheme, each task should have exactly one owner at a time.

Agents in a team need some common knowledge. Three designs, from least to most shared:

• Nothing shared: each agent has its own context; information moves only in briefs and reports.
• Shared state: a structured record all agents read and write: the plan, task statuses, established facts.
• Shared memory store: a searchable store of findings any agent can query.

Sharing more helps agents build on each other and costs isolation.

• With nothing shared, contexts stay small and mistakes stay contained, but work is repeated.
• With shared state, everyone sees progress, but a wrong entry misleads everyone.
• Rules that keep shared state healthy: each field has one owner; entries record who wrote them and from what source; agents append findings, they do not overwrite others'.

When agents disagree, something must decide. The options:

• Authority: a designated agent, usually the supervisor, decides.
• Evidence: the claim with a verifiable source wins; unsupported claims are dropped.
• Voting (consensus): several agents answer independently and the majority is taken.
• A judge: a separate agent or model weighs the positions against criteria.
• A person: if the disagreement matters and cannot be settled, escalate.

Disagreement is information: it marks the cases most likely to be wrong.

• Evidence beats opinion; settle by checking wherever something can be checked.
• Voting helps only when answers are independent. Agents shown each other's answers tend to converge on the first, right or not.
• An unresolved conflict silently averaged into the final answer produces a confident statement that nobody verified.

Several agents cost more than one in three ways:

• Tokens: every agent has its own system prompt and tools, and briefs and reports are extra text. On a short task this overhead multiplies the total.
• Latency: sequential hand-offs add waiting; parallel workers reduce it.
• Complexity: more prompts to maintain, more traces to read, more ways to fail.

They can still be cheaper for long tasks, because each worker's context stays short and workers can use a smaller model.

The arithmetic depends on length.

• A single agent's context grows every step, so a long task becomes expensive quickly.
• Splitting the same work across fresh, short contexts avoids resending a long history.
• For short tasks the fixed overhead of extra agents dominates, and one agent wins.
• Measure for your task; do not assume either way.

The questions interviewers ask about single-agent and multi-agent systems, from the first screening call to the senior round. Cover the answer, say yours aloud, then compare.

Reading an idea and explaining it are different skills.

• Each answer below is the two or three sentences an interviewer is listening for.
• The reasoning behind each one is in the cards above. If an answer surprises you, go back to that card.

A short build that uses this module's ideas. Write it yourself before looking anything up; the checks at the end tell you whether it works.

An idea you have only read fades in a week.

• Building it once, even in fifty lines, is what makes it yours.
• Interviewers can tell the difference between someone who has read about a loop and someone who has debugged one.