You've built a sophisticated system. Agent A researches the problem. Agent B analyzes the findings. Agent C writes the final deliverable. Three specialized agents, each doing what it does best.
The first time you run it, Agent A produces excellent research. Agent B delivers sharp analysis. But Agent C? The deliverable is confused—it references research tangents that weren't relevant to the analysis, conflates two similar concepts Agent B carefully distinguished, and misses the core insight entirely.
What went wrong?
Agent C inherited a polluted context. Every token of Agent A's research notes, every exploratory dead-end Agent B considered—all of it accumulated in the context window by the time Agent C started writing. The context was full, but full of the wrong things. Agent C had no room for clear thinking because its attention budget was consumed by its predecessors' work-in-progress.
This is the dirty slate problem. And it's why sophisticated multi-agent systems often produce worse results than a single, well-prompted Digital FTE. Complexity without discipline produces chaos, not value.
Consider how most people build multi-agent workflows:
This is a linear pipeline. Each agent passes its full context to the next. It feels natural—after all, Agent B needs to know what Agent A discovered, right?
The problem is what else comes along for the ride.
Agent A didn't just produce its final research summary. It also:
When Agent B starts, all of that research detritus is in the context window. Agent B's attention budget is already 40% consumed before it begins its actual task. It spends attention on Agent A's exploratory dead-ends instead of its own analysis.
By the time Agent C starts, the context is chaos:
Agent C needs maybe 2,000 tokens of actual input: Agent B's analysis and the original task description. Instead, it has 50,000 tokens of accumulated process. Its attention is diluted across content that isn't relevant to producing the deliverable.
This is why multi-agent systems fail. As LangChain's research concluded:
"The main issue with multi-agent systems is that they are highly failure-prone when agents work from conflicting assumptions or incomplete information. Failure generally boils down to missing context."
The irony: they fail from missing context while drowning in irrelevant context. The signal gets lost in noise.
The dirty slate problem isn't unique to any profession. Here's how it manifests across different fields:
The pattern is universal: exploratory work pollutes the context for synthesis work.
The solution isn't to avoid multi-agent systems. It's to isolate their contexts.
In the Clean Context Pattern:
Each subagent uses its full attention budget for its specific task. No pollution from other agents' work. No diluted attention. No accumulated noise.
Legal: Creating a Case Brief
Marketing: Creating a Strategy Document
Research: Creating a Synthesis Paper
Consulting: Creating Recommendations
The clean context pattern doesn't just prevent failures—it enables capabilities. When agents have isolated contexts, they can run in parallel. Research, analysis, and even preliminary writing can happen simultaneously if the orchestrator structures the task correctly.
Let's examine each benefit more concretely.
In Lesson 2, you learned about the attention budget—how context utilization above 70% degrades quality. In a dirty slate pipeline:
With context isolation:
Each agent operates in its optimal zone. No agent inherits its predecessors' burden.
Agent A's job is research. Part of research is exploring dead ends. That's not a bug—it's how discovery works. But Agent C doesn't need to know about the five approaches you considered before finding the right one. Agent C needs the winning choice and why it won.
Clean context means each agent only sees what it needs. The orchestrator translates "Agent A explored five options and chose Option 3 because of X, Y, Z" into "Use Option 3. Reasoning: X, Y, Z." The exploration is preserved in Agent A's context; the decision is passed to Agent C.
Examples across domains:
When a dirty slate pipeline fails, debugging is archaeology. The failure might be:
With clean contexts, debugging is straightforward:
Each agent can be evaluated independently. You can even rerun a single agent with modified inputs without rerunning the entire pipeline.
Consider this task: "Create a comprehensive market analysis."
Dirty slate approach (sequential):
Clean context approach (parallel where possible):
The research tasks are independent—they can run simultaneously. Only the synthesis and drafting require sequential execution because they depend on the research results. Clean contexts enable this parallelism because each research agent doesn't need to wait for another to finish.
Not all multi-agent work requires the same pattern. Here are three patterns for different needs:
Context handling: Fresh context each call, strong isolation
Key constraint: Subagents cannot spawn other subagents. This is a fundamental architectural limitation—only the orchestrator can delegate work. If you need nested delegation, structure your orchestrator to handle all agent creation directly.
Best for:
Example use cases by domain:
In Claude Code:
Context handling: Context transfers between agents
Best for:
Example use cases by domain:
Warning: This is the dirty slate pattern. Use only when context transfer is genuinely necessary, and monitor context utilization carefully.
Context handling: Common memory layer, agents read/write
Best for:
Example use cases by domain:
Implementation: The shared state is typically a file (progress file, central document, database) that all agents can read and update. Each agent still operates with relatively clean context—they read the shared state at start, do their work, write updates back.
Most real workflows combine patterns. An orchestrator might use Stateless subagents for parallel research, collect summaries into a Shared progress file, then use Stateful handoff for sequential refinement.
You just saw three subagent design patterns: Stateless, Stateful, and Shared (Network). The Stateless and Stateful patterns are well-established. But the Shared pattern raises a practical question: how do you actually coordinate multiple agents that need to communicate with each other, share state, and self-organize around a problem?
Claude Code's agent teams feature is a native implementation of the Network pattern. The key evolution from subagents: subagents report results back to their caller only. They cannot talk to each other. Agent teams are separate Claude Code instances that can message each other directly, share a task list, and self-coordinate without routing every communication through the orchestrator.
This changes what's possible. With subagents, the orchestrator is a bottleneck for all communication. Agent A discovers something relevant to Agent C, but must report it to the orchestrator, which must then relay it to Agent C. With agent teams, Agent A messages Agent C directly. The lead coordinates the overall mission, but teammates handle tactical communication on their own.
Use subagents when you need quick, focused workers that report back. Use agent teams when teammates need to share findings, challenge each other, and coordinate on their own.
Agent teams shine in specific scenarios where inter-agent communication produces better results than isolated reports:
Agent teams add coordination overhead and use significantly more tokens than a single session. They work best when teammates can operate independently on separate files or concerns. For sequential tasks, same-file edits, or work with many dependencies, subagents are more effective. The pattern selection table from earlier still applies -- agent teams are the practical implementation of "Shared (Network)" for cases where inter-agent dialogue matters.
The original pattern selection table covered Stateless, Stateful, and Shared. Here is how agent teams fit alongside subagents within the Stateless and Shared categories:
The decision comes down to one question: do the workers need to talk to each other? If yes, agent teams. If no, subagents.
Agent teams are experimental and disabled by default. Enable them in your settings:
Then describe the team structure you want in natural language:
Output:
Here is how agent teams operate in practice:
Interacting with teammates:
Delegate mode deserves special attention. Without it, the lead sometimes starts implementing tasks itself instead of waiting for teammates. This defeats the purpose of the team -- the lead should be coordinating, not coding. Delegate mode restricts the lead to spawning, messaging, shutting down teammates, and managing tasks. Use it when you want strict separation between orchestration and implementation.
Every best practice for agent teams maps directly to context engineering principles from this chapter.
"Give teammates enough context." Teammates load CLAUDE.md automatically, but they do not inherit the lead's conversation history. If the lead spent ten minutes discussing the authentication architecture with you, none of that context reaches the teammate who reviews the auth module. Task-specific details must go in the spawn prompt:
This is Strategy 3 (Include Critical Context in Delegation Prompt) from the context amnesia section, applied at the team level. The more specific the spawn prompt, the less time the teammate spends orienting and the more time it spends on actual analysis.
"Size tasks appropriately." Too small and coordination overhead exceeds benefit. Too large and teammates work too long without check-ins, increasing the risk of wasted effort. The recommendation is 5-6 tasks per teammate as a starting point. This is the Signal vs Noise principle from Lesson 2 applied to task granularity: each task should be large enough to produce meaningful signal but small enough that the lead can detect problems before they compound.
"Avoid file conflicts." Two teammates editing the same file leads to overwrites. Break the work so each teammate owns a different set of files. This is context isolation applied to file system state, not just token context. The same principle that keeps Agent A's research artifacts out of Agent C's attention budget also keeps Agent A's file edits from colliding with Agent C's file edits.
These are not new principles. They are the same context engineering fundamentals you have been learning throughout this chapter, applied at a different scale. The pattern holds: clean signal in, clean signal out, regardless of whether "in" means a single agent's context window or a team of six coordinating across a codebase.
Anthropic researcher Nicholas Carlini used 16 parallel Claude instances to build a C compiler from scratch. Over nearly 2,000 Claude Code sessions and approximately 2 billion input tokens, the agents produced a 100,000-line Rust-based compiler that can compile Linux 6.9 across x86, ARM, and RISC-V architectures. The compiler achieves a 99% pass rate on standard compiler test suites and can also compile QEMU, FFmpeg, SQLite, PostgreSQL, and Redis. Total cost: approximately $20,000.
The project was not a toy demonstration. It produced a working compiler that handles real-world software. And the engineering challenges Carlini encountered read like a chapter summary of everything you have learned about context engineering.
Test suites as signal. High-quality test suites directed agent behavior without human supervision. But the test harness had to be clean. As Carlini documented, the harness should avoid printing noise that obscures the actual error. Instead, it should log important information to files and keep error output on single lines for automated grep searches. This is Lesson 2 (Signal vs Noise) at compiler scale: the agents spent attention diagnosing real problems, not parsing noisy output.
Documentation for agent onboarding. Agents maintained extensive READMEs and progress files updated frequently with current status. When a new agent session started, these documents helped it orient quickly without human intervention. This is the context amnesia workaround (Strategy 2: Master-Clone) working at production scale: every fresh agent reads the project brief before starting its task.
Randomized test sampling. The harness included a fast mode that runs a 1% or 10% random sample of test cases, deterministic per-agent but random across instances. This enabled parallel debugging: each agent worked on different failure subsets simultaneously. This is decomposition for parallelism, the same principle behind the clean context pattern, applied to the test suite itself.
Clear error messaging. Pre-computed statistics and clear error messages reduced the computational overhead of understanding failures. Agents could immediately see what failed and why, rather than sifting through thousands of lines of output. This is context quality at the infrastructure level: the environment itself was engineered to present clean signal to the agents.
The takeaway: at 16-agent scale, the differentiator was not the model or the tools. It was context quality. The same model, the same tools, but disciplined context engineering produced a compiler that passes real-world test suites. Sloppy test harnesses, verbose output, or missing documentation would have turned those 2 billion tokens into noise instead of progress.
This principle scales down, too. Whether you are coordinating 16 agents building a compiler or 3 teammates reviewing a contract, the work succeeds or fails based on the quality of context each agent receives. Clean signal in, clean results out.
Here's the catch: clean context means subagents don't know your project. They start fresh. They don't know your organization's conventions, your client's preferences, your "we tried that already and it failed" history.
This is context amnesia—the price of isolation.
Three strategies to work around it:
Create Skills (from Chapter 3) that encode domain-specific knowledge:
Legal Professional:
Marketing Professional:
Research Professional:
Consulting Professional:
When invoking a subagent, include the relevant skill:
The skill provides domain knowledge without polluting context with irrelevant details.
The subagent reads the full project brief at the start of its task:
This works well when project briefs are well-organized (under 60 lines of signal, per Lesson 4). The subagent gets full project context at the cost of some token budget, but starts fresh without other agents' pollution.
The orchestrator extracts only the critical context for each delegation:
Legal example:
Marketing example:
The orchestrator knows what context matters for this specific task. It includes that context explicitly, leaving out everything else.
Best practice: Combine strategies. Use Skills for stable conventions, master-clone for project-wide context, and explicit context for task-specific details.
Context isolation includes controlling what each subagent can do, not just what it knows.
In Claude Code, you specify tool access when launching subagents:
This prevents a research subagent from accidentally modifying files. It prevents a review subagent from "fixing" issues without proper oversight. Tool access control is another form of isolation—capability isolation alongside context isolation.
Objective: See the difference between polluted and isolated context with your own eyes.
Duration: 60 minutes
Deliverable: Evidence documenting which pattern produces better results for a realistic task.
Select the professional context that matches your work:
The three-step process is the same regardless of domain:
Step 1: Start a fresh Claude Code session.
For Legal (Option A):
For Marketing (Option B):
For Research (Option C):
For Consulting (Option D):
For Development (Option E):
Let Claude research. Note what gets added to context: document reads, search results, exploratory tangents.
Step 2: Continue in the same session.
Note: Claude now has research context PLUS analysis context.
Step 3: Continue in the same session.
Save the output. Note the quality. Note context utilization.
Step 1: Start a fresh Claude Code session.
Use the same domain prompt from above, but add this structure:
Save the summary.
Step 2: Start a NEW session (or /clear).
Save the analysis.
Step 3: Start a NEW session (or /clear).
Save the output.
Now compare the two deliverables:
Create a brief document (1/2 page) with:
Symptom: The final output misses nuances that were in the original research.
Cause: Summaries were too aggressive; important details were compressed away.
Fix: Use structured summary formats that force inclusion of key elements. For complex tasks, use "summary + supporting evidence" format:
Symptom: Subagent produces output that violates professional conventions.
Cause: Clean context means no domain knowledge.
Fix: Use context amnesia workarounds: Skills for professional conventions, master-clone for project-wide context, explicit context in delegation prompt.
Symptom: The orchestrator is doing all the work; subagents aren't contributing much.
Cause: Tasks are too small or poorly defined; the overhead of delegation exceeds the benefit.
Fix: Increase task granularity. If a subagent task takes less than 5 minutes, it might not be worth isolating. Consolidate into larger, meaningful work units.
Symptom: Three subagents ran in parallel, but their outputs contradict each other.
Cause: Parallel subagents didn't share assumptions; they made incompatible decisions.
Fix: Provide shared constraints in each delegation. If certain decisions must be consistent across subagents, make those decisions before delegation, not during.
What you're learning: How to analyze existing professional workflows for context pollution. The diagnosis skill helps you see accumulation that you might have normalized as "just how it works."
What you're learning: How to architect multi-agent systems for your specific professional domain. The design process—decomposing into agents, specifying minimum context, defining summaries—builds the instinct for clean context patterns.
What you're learning: There's no universally correct pattern—the choice depends on your specific needs. This prompt builds judgment about when isolation helps versus when it adds unnecessary overhead.
Enable agent teams in your settings, then try this:
What you're learning: Agent teams demonstrate the network pattern from this lesson in action. Notice how each teammate operates with clean context (they don't inherit the lead's history), how they coordinate through the shared task list, and how inter-agent communication produces richer analysis than isolated subagents reporting back independently. The debate structure -- teammates challenging each other's findings -- is impossible with subagents, which can only report to their caller.
The insight that ties this chapter together: context is attention budget, and attention is finite. Every technique in this chapter—position sensitivity, signal-to-noise auditing, compaction, progress files, and now context isolation—serves the same goal: ensuring the AI's attention is spent on what matters, not on accumulated noise.
In the final lesson, you'll bring all these techniques together into a coherent playbook for building Digital FTEs worth selling.