Split work across specialists only when isolation creates real value.
A team should beat a single agent on a named axis.
Learners decide when multi-agent orchestration is warranted.
Why this matters: This prevents adding agent personas that duplicate work and inflate cost.
Problem anchor: a lesson-quality review must check schema, source grounding, pedagogy, and code examples across many files. Separate workers can inspect disjoint slices or specialize in citations versus schema. A second “creative thinker” with no ownership adds little.
Multi-agent orchestration is valuable for breadth, specialization, independent verification, or context isolation. It is harmful when workers repeat each other, inherit a bad plan, or produce unsupported summaries.
A coordinator assigns one worker to schema/render validation and another to source-grounding review. Each returns findings with file paths, evidence, and confidence. The coordinator merges conflicts and decides fixes.
The team is justified because the checks are independent and can run in parallel. A vague brainstorming swarm would not be justified.
Multi-agent design is control-flow design.
Learners map task shape to topology.
Why this matters: The topology decides who plans, who acts, and who resolves conflicts.
A supervisor-worker team centralizes planning and synthesis. A pipeline gives each stage one owner. A debate or critic loop compares candidate answers. A blackboard lets workers contribute to shared state while a controller arbitrates.
Shared state should be intentional: findings, citations, unresolved questions, and artifacts. Private scratchpads should not become unreviewed evidence.
| Option | Topology | Best for | Risk | When to choose | Cost | Complexity |
|---|---|---|---|---|---|---|
| Supervisor-worker | Coordinator decomposes and merges. | Parallel research, audits, broad tasks. | Coordinator may accept unsupported findings. | Use for bounded independent packets. | Medium | Medium |
| Pipeline | Each agent owns one stage. | Draft -> critique -> revise workflows. | Early-stage errors propagate. | Use when stages are stable. | Medium | Low |
| Debate/critic | Candidate answer challenged by reviewer. | Ambiguous reasoning or quality review. | Can become persuasive but unsupported. | Use with evidence requirements. | High | Medium |
The packet is the API between coordinator and worker.
Learners design delegation as a contract.
Why this matters: Loose delegation produces noisy summaries that the coordinator cannot verify.
A good packet states the task, files or sources owned, allowed tools, forbidden actions, expected output schema, evidence requirements, confidence labels, and stop conditions.
Workers should know they are not alone in the codebase and must not revert unrelated changes. For safety, tool access should match the packet: a citation reviewer does not need production write tools.
Task: inspect three RAG lessons for source support. Scope: only listed files. Tools: read files, run validator. Output: findings with file path, block ID, unsupported claim, source evidence, severity. Stop: return after all files or blocker.
The worker is not asked for a broad opinion. It returns reviewable evidence the coordinator can merge.
Synthesis is an evidence-merging task.
Learners build a merge step with conflict handling.
Why this matters: Unsupported worker summaries can contaminate the final answer.
Workers may duplicate effort, disagree, miss citations, or overstate confidence. The coordinator should merge by evidence: source, trace, metric, or test result. Unsupported claims become follow-up tasks or caveats.
Conflict handling should be explicit. If one worker says a file validates and another reports render failure, the coordinator runs or requests the decisive check.
findings = [
{"id": "f1", "claim": "chunking lesson validates", "evidence": "OK chunking-strategies-for-rag", "confidence": 0.95},
{"id": "f2", "claim": "chunking lesson validates", "evidence": "OK chunking-strategies-for-rag", "confidence": 0.90},
{"id": "f3", "claim": "MCP lesson lacks policy section", "evidence": "module m4 missing host policy", "confidence": 0.60},
]
merged = {}
for f in findings:
key = f["claim"]
if key not in merged or f["confidence"] > merged[key]["confidence"]:
merged[key] = f
for claim, f in merged.items():
status = "accepted" if f["evidence"] and f["confidence"] >= 0.8 else "needs_follow_up"
print(status, claim, "<-", f["evidence"])
It is marked needs_follow_up because confidence is below 0.8, even though it includes some evidence.
The final question is whether the topology improves the product.
Learners define release gates for multi-agent systems.
Why this matters: Without baselines, coordination overhead can masquerade as sophistication.
Run the same tasks with one agent, supervisor-worker, critic loop, and deterministic workflow where possible. Compare recall, correctness, citations, tool count, cost, latency, and human review needs.
Safety evaluation must cover each agent’s permissions and communication path. A research worker should not gain write access because the coordinator has it.
Review the topology and final answer together.
Retrieval prompt: reconstruct orchestration by naming topology, coordinator, worker packet, tools, shared state, merge, conflict handling, safety, and baseline eval.
Design a two-worker research team for a lesson QA task. Define coordinator role, worker scopes, allowed tools, output schema, evidence requirements, merge rules, stop conditions, and a baseline comparison against one agent. Next rung: study AutoGen/AG2 or CrewAI patterns.
A team is debating whether to use a multi-agent system for a task that requires browsing five websites and summarizing the results into one report. Which factor most strongly justifies adding multiple agents instead of using a single agent?
Multi-agent systems earn their cost when sub-tasks are genuinely parallel and independent — here, each site can be scraped simultaneously, which a single sequential agent cannot do as efficiently.
You are designing a fact-checking pipeline where Agent A extracts claims, Agent B checks sources, and Agent C writes the verdict. No agent needs to see another's intermediate scratchpad — only their final outputs. Which topology and state model fits best?
A linear pipeline with private state is the right fit when tasks flow in a fixed sequence and agents only need each other's final outputs, not intermediate reasoning.
List THREE specific fields or constraints you should include in a delegation packet (worker brief) sent from a supervisor to a worker agent, and explain in one sentence why each matters.
A tight delegation packet constrains the worker's scope, tools, and output format — without these, workers overlap, hallucinate, or return unstructured data that is hard to merge.
Three worker agents all return findings about the same event. Agent 1 says the date was March 4; Agent 2 says March 5; Agent 3 says March 4 and cites a primary source. What is the correct merge strategy before synthesis?
Conflict resolution should be explicit and provenance-driven: prefer the best-evidenced claim, but preserve the dissenting finding in the log so the final answer is auditable.
After running a supervisor-worker topology and a single-agent baseline on the same task, you find the multi-agent system uses 4× more tokens and takes 2× longer, but produces no measurable quality improvement. What is the most appropriate conclusion?
Evaluation against a single-agent baseline is the decisive test: if the multi-agent topology costs more in tokens, latency, and complexity without a quality or speed benefit, it is theater — not engineering.