Glossary
71 terms from “Multi-Agent Collaboration.” Hover the first occurrence in the lesson for its definition.
| Term | Definition | Source |
|---|---|---|
| context pollution | An error or irrelevant scrap picked up early in a task mixes into the one context that all later reasoning depends on, and later correct information has a hard time washing it out completely. | Effective context engineering for AI agents (Anthropic Engineering) |
| attention dilution | The more content packed into one context window, the less attention the model can give to any single piece of it, so it slips up or leaves things out on tasks that need many details held precisely at once. | Effective context engineering for AI agents (Anthropic Engineering) |
| attention budget | Anthropic's framing for the finite pool of attention a model draws on when parsing large volumes of context; every new token depletes some of it. | Effective context engineering for AI agents (Anthropic Engineering) |
| performance gradient | Anthropic's description of how context-driven degradation actually shows up: quality declines gradually as the context grows, rather than working perfectly until some threshold and then failing outright. | Effective context engineering for AI agents (Anthropic Engineering) |
| multi-agent system | Several agents — LLMs autonomously using tools in a loop — working together on one task, each with its own context. | How we built our multi-agent research system (Anthropic Engineering) |
| coordination overhead | The extra time and tokens spent getting several agents to divide work and collaborate: splitting the task, aggregating results, and reconciling contradictory output. | How we built our multi-agent research system (Anthropic Engineering) |
| parallelization | Handing the genuinely separable parts of a task — the ones that do not depend on each other's intermediate results — to different agents to work on at the same time. | How we built our multi-agent research system (Anthropic Engineering) |
| depth-first task | A task whose answer lives in one chain of reasoning you have to work through step by step, with tightly coupled steps that resist being cut cleanly into pieces for different agents. | How we built our multi-agent research system (Anthropic Engineering) |
| breadth-first task | A task whose answer spreads across a few relatively independent directions that can genuinely be chased separately, without depending on each other's intermediate results. | How we built our multi-agent research system (Anthropic Engineering) |
| context window | The span of information a model can hold in one inference pass; multi-agent systems ease pollution and dilution by giving each agent its own separate one. | How we built our multi-agent research system (Anthropic Engineering) |
| single-agent system | Getting the task done end to end with one agent, without splitting it or introducing multi-agent collaboration. | Building effective agents (Anthropic Engineering) |
| scaling rule | Anthropic's rule of thumb for sizing agent count against task complexity: simple fact-finding needs 1 agent with 3 to 10 tool calls, a direct comparison 2 to 4 subagents with 10 to 15 calls each, and only research complex enough to divide responsibilities cleanly goes past 10 subagents. | How we built our multi-agent research system (Anthropic Engineering) |
| economic viability | The condition that a multi-agent system is only worth using when the task's own value is high enough to pay for the extra token cost that comes with the performance gain. | How we built our multi-agent research system (Anthropic Engineering) |
| separation of concerns | Anthropic's term for what subagents buy you: distinct tools, prompts, and exploration paths per agent, which reduces path dependency so one agent's dead end does not steer the others. | How we built our multi-agent research system (Anthropic Engineering) |
| orchestrator-subagent | An architecture where a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results. | Building effective agents (Anthropic Engineering) |
| orchestrator | The central agent that decides how to divide the work, who gets which piece, and how to stitch several returned results into one coherent answer. | Building effective agents (Anthropic Engineering) |
| subagent | An agent dispatched by the orchestrator to complete one delegated task inside a fresh, isolated context window, returning its result when done. | Create custom subagents (Claude Code Docs) |
| context isolation | Confining each agent's working scope to its own context window, so context pollution inside one agent does not spread to another. | Create custom subagents (Claude Code Docs) |
| fan-out | The orchestrator distributing the split-up subtasks in parallel to a matching number of subagents, so they all start working at once instead of queuing one after another. | Building effective agents (Anthropic Engineering) |
| aggregate | The step after fan-out where the orchestrator puts several independently produced results side by side, compares them, resolves duplication or contradiction, and reorganizes them into the final deliverable's shape. | Create custom subagents (Claude Code Docs) |
| return only the conclusion | The principle that a subagent should hand back its final, defensible conclusion and the key evidence behind it, not the whole reasoning trail with its detours and self-corrections. | Create custom subagents (Claude Code Docs) |
| fork | A subagent that inherits the entire conversation so far instead of starting fresh; its own tool calls still stay out of the main conversation and only its final result comes back. | Create custom subagents (Claude Code Docs) |
| Manager pattern | The OpenAI Agents SDK's name for the orchestrator-subagent structure: a central manager invokes specialized sub-agents as tools and retains control of the conversation. | Agents (OpenAI Agents SDK) |
| break down | The first of the orchestrator's three actions: look at one big task and work out which chunks it splits into. | Building effective agents (Anthropic Engineering) |
| delegate | The second of the orchestrator's three actions: hand each chunk, along with the background it needs, to a subagent to carry out. | Building effective agents (Anthropic Engineering) |
| synthesize | The third of the orchestrator's three actions: once the subagents return their results, combine those results into the final answer. | Building effective agents (Anthropic Engineering) |
| game of telephone | The fidelity loss that accumulates when a subagent's result gets paraphrased and compressed on its way through the orchestrator; writing subagent output straight to a filesystem is one way to avoid it. | How we built our multi-agent research system (Anthropic Engineering) |
| self-contained | A property of a delegation prompt: after reading it, the subagent needs no extra background to work out accurately what it should do. | Create custom subagents (Claude Code Docs) |
| source guidance | The part of a delegation prompt that tells the subagent where to look for the answer — the official pricing page, a third-party comparison site, or both with one taking precedence. | How we built our multi-agent research system (Anthropic Engineering) |
| task boundaries | The part of a delegation prompt that tells the subagent this run covers only this slice and not to reach beyond it. | How we built our multi-agent research system (Anthropic Engineering) |
| one problem domain, one agent | The principle that each subagent should own only one class of clearly bounded problem, rather than juggling several unrelated things at once. | How we built our multi-agent research system (Anthropic Engineering) |
| CitationAgent | A dedicated subagent in Anthropic's production system that processes the documents and research report to identify specific locations for citations, ensuring claims are properly attributed to their sources. | How we built our multi-agent research system (Anthropic Engineering) |
| delegation prompt | The task brief the orchestrator hands a subagent; its quality ceiling sets the quality ceiling of what the subagent produces. | How we built our multi-agent research system (Anthropic Engineering) |
| vague instruction | A brief like 'research the semiconductor shortage' that pins down no time range, angle, source, or deliverable, leaving subagents to improvise. | How we built our multi-agent research system (Anthropic Engineering) |
| output format | The part of a delegation prompt that states what shape the subagent's deliverable should take, which decides whether the orchestrator can use the result directly. | How we built our multi-agent research system (Anthropic Engineering) |
| misinterpreted the task | The failure where a subagent, working from a task description that was not detailed enough, reads the requirement wrong and produces something off from what the orchestrator wanted. | How we built our multi-agent research system (Anthropic Engineering) |
| pipeline | A collaboration pattern that decomposes a task into a sequence of steps, where each LLM call processes the output of the previous one. | Building effective agents (Anthropic Engineering) |
| prompt chaining | The official name for the pipeline pattern, emphasizing that the task is decomposed into a sequence of steps executed in order. | Building effective agents (Anthropic Engineering) |
| producer-reviewer | A collaboration pattern where one LLM call generates a response while another provides evaluation and feedback in a loop, repeating until it converges. | Building effective agents (Anthropic Engineering) |
| evaluator-optimizer | The official name for the producer-reviewer pattern, emphasizing that one call generates while another evaluates and feeds back. | Building effective agents (Anthropic Engineering) |
| multi-perspective voting | A collaboration pattern where several agents each judge the same already-existing content independently and in parallel, and the content gets flagged as soon as any one of them finds a problem. | Building effective agents (Anthropic Engineering) |
| handoff | A decentralized collaboration style where peer agents hand control off to a specialized agent that takes over the conversation. | Agents (OpenAI Agents SDK) |
| Peer agents | Agents of equal standing in a handoff-style setup, with no fixed superior-subordinate relationship, passing control directly between themselves. | Agents (OpenAI Agents SDK) |
| decentralized | The defining trait of handoff-style collaboration: control is not held throughout by one central node but passed directly between peer agents. | Agents (OpenAI Agents SDK) |
| control of the conversation | The authority to steer what happens next; the orchestrator retains it throughout in orchestrator-subagent, while a handoff transfers it to the receiving agent. | Agents (OpenAI Agents SDK) |
| single run | The boundary a handoff stays inside — the transfer of control holds for this run and does not carry over into a later, independent run. | Handoffs (OpenAI Agents SDK) |
| trust-then-verify gap | The named failure mode where a model produces a plausible-looking implementation that does not handle edge cases; the fix is to always provide verification, and if you cannot verify it, do not ship it. | Best practices for Claude Code (Claude Code Docs) |
| checkable standard | A concrete verification criterion defined for the specific task, which output can be measured against item by item, rather than scored on impression. | How we built our multi-agent research system (Anthropic Engineering) |
| LLM judge | The role in Anthropic's production system that evaluates each subagent output against criteria in a rubric. | How we built our multi-agent research system (Anthropic Engineering) |
| factual accuracy | One of the LLM judge's rubric criteria: do the claims in the output match the sources it cites? | How we built our multi-agent research system (Anthropic Engineering) |
| citation accuracy | One of the LLM judge's rubric criteria: do the cited sources actually match the claims they are attached to? | How we built our multi-agent research system (Anthropic Engineering) |
| source quality | One of the LLM judge's rubric criteria: did the subagent use primary sources rather than lower-quality secondary ones? | How we built our multi-agent research system (Anthropic Engineering) |
| duplicate work | Several subagents covering the same ground, producing heavily overlapping output — usually surfacing only at the moment results are aggregated. | How we built our multi-agent research system (Anthropic Engineering) |
| result conflict | Two subagents researching independently and returning conclusions that contradict each other, which cannot be settled by picking one at random or splitting the difference. | How we built our multi-agent research system (Anthropic Engineering) |
| misattribution | The integration-stage error of writing up data one subagent found as a conclusion about the slice a different subagent was responsible for. | How we built our multi-agent research system (Anthropic Engineering) |
| integration stage | The closing step where the orchestrator merges duplicate content, verifies or flags contradictory conclusions, and checks that every claim traces back to the right source. | How we built our multi-agent research system (Anthropic Engineering) |
| dedup | The part of integration that merges overlapping content across several subagent outputs so the final result does not say the same thing twice. | How we built our multi-agent research system (Anthropic Engineering) |
| structured review result | A review returned in fixed fields like `{approved, issues}` rather than a blanket natural-language verdict, so downstream code can read and act on it. | How we built our multi-agent research system (Anthropic Engineering) |
| MAX_ROUNDS | The ceiling on how many producer-reviewer rounds the pipeline will run, preventing the two agents from polishing back and forth forever. | Building effective agents (Anthropic Engineering) |
| safety valve | The mechanism that guarantees a loop terminates; in this lesson's pipeline, `MAX_ROUNDS` plays that role. | Building effective agents (Anthropic Engineering) |
| REVIEW_CRITERIA | The explicit checklist handed to the reviewer in this lesson's code, listing the specific standards it must check the draft against one by one. | How we built our multi-agent research system (Anthropic Engineering) |
| runProducer | The function in this lesson's code that generates or revises the draft; on a rerun it carries the previous version plus the review notes so the producer edits rather than restarts. | Using the Messages API (Claude API) |
| runReviewer | The function in this lesson's code that checks the draft against `REVIEW_CRITERIA` item by item and returns the review result. | How we built our multi-agent research system (Anthropic Engineering) |
| parseReview | The function in this lesson's code that turns the reviewer's text reply into a structured object, returning a rejection whenever parsing fails or the field shapes are wrong. | Best practices for Claude Code (Claude Code Docs) |
| extractJson | The helper in this lesson's code that strips a markdown code fence off the model's reply, if present, so the JSON inside can be parsed. | Structured outputs (Claude API) |
| approved | The boolean field in the review result that says whether this draft passed the review criteria. | Structured outputs (Claude API) |
| issues | The array field in the review result listing each failed criterion and its specific problem; empty when everything passes. | Structured outputs (Claude API) |
| defensive parsing | Writing your own checks around a model's reply — stripping fences, catching parse errors, validating field types — instead of trusting that it will match the agreed format. | Structured outputs (Claude API) |
| structured outputs | The official feature that constrains a model's response to strictly match a schema at the sampling level, guaranteeing valid, parseable output. | Structured outputs (Claude API) |
| stateless | The property of the Messages API that every request must carry the full conversation history it needs, because the API keeps no state between requests. | Using the Messages API (Claude API) |
| runPipeline | The function in this lesson's code that wires producer, reviewer, and parser into a loop bounded by `MAX_ROUNDS`, and hands over the last draft with unresolved issues if the cap is hit. | Building effective agents (Anthropic Engineering) |