You have five specialist agents that can collaborate on a complex investigation. When would you use a supervisor, when would you use a swarm, and how would you prevent routing loops, duplicated work, and unbounded conversation?

How to think about it

The answer

Use a supervisor—the one agent that owns the plan, task queue, and final synthesis—when the investigation has dependencies or must produce one coherent, auditable answer. Use a swarm—specialists that can route work directly to one another—when the work is genuinely exploratory and parallel, peer discovery is valuable, and no single coordinator should sit in every exchange.

With five specialists, I would default to a supervisor and permit tightly bounded peer consultation where the dependency graph justifies it. In either design, I prevent chaos with explicit task ownership, deduplication keys, leases, maximum hops and turns, wall-clock and token budgets, and a termination condition that does not depend on an agent saying, “I think we are done.”

Why the topology matters

The interviewer is probing whether you understand that agent collaboration is a control problem, not merely a prompt-writing problem.

A supervisor creates a hub-and-spoke system:

1. The supervisor decomposes the investigation.
2. Specialist agents receive scoped tasks.
3. They return evidence and conclusions.
4. The supervisor decides what is missing, requests limited follow-up work, and synthesizes the answer.

This is a fan-out/fan-in pattern: work fans out to specialists, then findings fan back in to one decision point. It works well when tasks have dependencies. A database specialist may need to inspect the timestamp discovered by the release specialist. The supervisor can make that dependency explicit instead of letting every agent ask every other agent.

A swarm is a peer-to-peer system. An agent may decide that another specialist has the right expertise and send work there directly. That can uncover connections a rigid plan would miss. A security agent investigating suspicious traffic might notice a clue that should immediately go to the identity specialist, without waiting for a central planner.

The price is global coordination. A swarm does not automatically know that two agents are investigating the same hypothesis, that an old message has already been disproven, or that the conversation has crossed the point of diminishing returns. You must add those controls.

The important distinction is this:

Five agents running in parallel are not necessarily a swarm.

If a supervisor assigns five independent tasks and later collects the results, that is still a supervisor architecture. Concurrency describes when work runs. A swarm describes who is allowed to route the next piece of work.

Situation	Better default	Reason
Incident response with one final decision	Supervisor	Dependencies and accountability matter
Open-ended hypothesis discovery	Bounded swarm	Peer routing can expose unexpected connections
Tasks with shared evidence	Supervisor or hybrid	One view of state prevents repeated work
Independent research with separate deliverables	Parallel workers	A full swarm adds complexity without much benefit
Safety-sensitive action	Supervisor	Central approval makes authority visible

A concrete investigation

Imagine a payment outage at 03:00. Checkout failures rise from 2 percent to 18 percent. A production release happened 14 minutes earlier. You have five specialists:

• A release agent checks the deployment diff and rollback signals.
• A database agent checks connection saturation, locks, and query latency.
• A network agent checks the gateway and upstream payment provider.
• An application agent examines traces grouped by route and build.
• A security agent checks unusual traffic, authentication failures, and abuse.

I would use a supervisor because the output is not five interesting reports. It is one operational decision: roll back, fail over, rate-limit, or continue investigating.

The supervisor creates five tasks with separate evidence boundaries. Each task has an objective, an owner, a deadline, a maximum tool budget, and a definition of done. For example:

• “Compare the current payment service build with the previous build and identify changes affecting authorization.”
• “Report whether database saturation explains the timing and error shape.”
• “Report provider-side failures using gateway logs and status data.”

Each worker gets 30 seconds of investigation time and one permitted follow-up request in this incident policy. The whole investigation has a 120-second wall-clock deadline. Those numbers are not universal tuning constants. They make the control policy concrete and force a choice when the clock is running.

The release agent finds a new authorization code path. The database agent reports normal lock and connection levels. The application agent finds that failures occur only on the new build. That is enough for the supervisor to request one focused validation: “Confirm whether the authorization exception is present in traces from the affected route, and cite three event IDs.”

The other agents do not restart their original investigations. The supervisor now has a targeted question, a finite budget, and evidence it can audit. If the validation confirms the finding, the supervisor recommends rollback with the supporting event IDs and records the database and network checks as ruled-out hypotheses.

The task contract matters more than the cleverness of the agents. A useful contract contains fields such as task_id, parent_id, owner, objective, scope, status, evidence_ids, done_when, expires_at, and remaining_budget. Agents may propose new work, but the supervisor is the component that accepts it into the queue.

Preventing duplicated work

Deduplication is not “never investigate the same idea twice.” Deliberate independent validation is often valuable. The rule is that repeated work must be explicit.

Give every task a normalized deduplication key based on the investigation, question, evidence scope, and purpose. For example, these two requests are duplicates:

• “Check whether database locks caused the checkout errors.”
• “Investigate database locking as the cause of the payment failure.”

They should map to the same underlying task if they cover the same time range and data. The second requester can subscribe to the first task’s result rather than launching another query.

By contrast, “Independently validate the database-lock hypothesis using read-replica metrics” is different. It has a different purpose and evidence source. Mark it as validation of the first task, not as an accidental duplicate.

Use a lease for active work. A lease says, “Agent B owns task 17 until 03:01:30.” If the agent crashes or misses the deadline, the task becomes available again. Without leases, a retry may create a second copy while the first worker is still running. That is how a quiet outage turns into ten agents all querying the same broken database.

Store findings as evidence-bearing claims, not just chat messages. A claim should point to source records, timestamps, and the agent that produced it. The supervisor can then merge two reports that cite the same event instead of counting them as two independent discoveries.

Preventing routing loops and unbounded conversation

A routing loop is a repeated forwarding cycle: agent A asks agent B, B asks C, and C sends essentially the same request back to A. The transcript grows, but the investigation does not.

In a supervisor design, the simplest rule is that workers cannot directly create arbitrary work. They can return findings and propose a follow-up. The supervisor checks the proposal against the task key, remaining budget, and evidence already collected.

In a swarm, the protocol needs equivalent guardrails:

• A maximum hop count, such as four peer handoffs.
• A maximum number of turns per investigation.
• A visited set for agent-task pairs, so the same request cannot revisit the same route.
• Capability-based routing, so an agent can forward only to a specialist whose declared scope matches the request.
• A request time-to-live, after which stale work is discarded.
• A global wall-clock deadline and token or tool budget enforced outside the agents.

Do not rely on the model to count reliably. The orchestrator or run controller must enforce these limits. A prompt saying “be concise” is not a termination mechanism.

Define termination before execution. For the payment incident, the run could stop when all five mandatory checks finish and either:

1. One cause has strong, corroborated evidence and no unresolved high-severity contradiction exists; or
2. The deadline is reached, in which case the system returns the best-supported hypothesis, known unknowns, and recommended next action.

A contradiction should create one adjudication task, not a fresh debate among all five agents. For example, if the release agent blames the deployment but the network agent finds provider errors at the same timestamp, ask for a comparison using a shared time window. Then stop after that adjudication budget is spent.

A common failure mode is visible before the final answer: the transcript contains repeated lines such as “I’ll ask the application agent to check this,” followed by the same request several times. Costs rise, latency rises, and the findings contain no new evidence. The usual causes are missing task identity, retries without idempotency, or agents being allowed to spawn work without a decreasing budget. Fix the protocol, not the wording.

The senior-level nuance

A supervisor is not automatically superior. It can become a bottleneck, lose useful local context, or anchor the whole investigation on a bad initial decomposition. If the supervisor is the only agent allowed to interpret evidence, five specialists may simply amplify one confident mistake.

A swarm is not automatically more intelligent either. Peer freedom is useful only when agents can discover valuable relationships that the initial plan cannot predict. If the work is already cleanly separable, a swarm adds routing overhead and makes reproducibility harder.

The strongest design is often hybrid. Use a supervisor for global state, budgets, synthesis, and authority. Permit a specialist to consult one peer when it has a concrete dependency, such as the security agent asking the identity agent to validate a suspicious token pattern. That consultation gets its own task ID, hop limit, and expiry. The peer can contribute evidence, but it cannot silently expand the investigation forever.

Choose the topology from the dependency graph, not from enthusiasm for “autonomous agents.”

What they’ll ask next

How do you handle a wrong supervisor?
Let workers challenge the plan with evidence and a reason code such as “scope mismatch” or “contradictory observation.” Reserve a small replan budget. The supervisor may revise its plan, but every revision remains bounded and recorded.

How do you measure whether the system is working?
Track time to first useful finding, unique evidence yield, duplicate-task rate, loop violations, budget overruns, unresolved contradictions, and final-answer accuracy. A swarm that produces more messages is not necessarily better.

What happens when specialists disagree?
Preserve both claims with their evidence and confidence. Ask one targeted adjudication task using a defined source hierarchy or narrower time window. If the conflict remains at the deadline, report the uncertainty instead of laundering it into a single confident sentence.

One line to say in the room

“I default to a supervisor for a five-agent investigation, use a swarm only where peer discovery is genuinely useful, and make both designs finite state machines with ownership, deduplication, hop limits, budgets, deadlines, and explicit evidence-based termination.”