Sub-Agents in Claude Code: The Subagent Orchestration Behind the Response Awareness Methodology

From beginner to expert

I've been working with Claude Code's agent system extensively while developing my Response Awareness methodology. The Anthropic documentation tells you what agents are - autonomous workers that handle multi-step tasks. What it doesn't explain is how they can create a fundamentally different cognitive architecture for complex work.

This isn't just about parallelization. It's about managing cognitive load across focused context windows.

---

What Anthropic's Documentation Says

Initially you only have one subagent, general-purpose.

Each agent operates independently with its own context window, receives a task description, and returns a single result.

Getting Started: Your First Sub-Agents

If you're new to Claude Code agents, here's the simplest way to start:

Just type in “Please spawn a subagent and find all authentication-related files in this codebase and list their dependencies” to your terminal. Or whatever it is you want it to do.

That's it. Claude spawns a sub-agent that searches, analyzes, and reports back. Additionally Claude can deploy agents in parallel so multiple agents can work at the same time, speeding up progress.

For beginners, `general-purpose` agents work fine for everything. But as you scale up, and look to trying the response awareness methodology, specialized agents perform better:

Planning Agents:

- `system-architect`: Overall system design and integration planning

- `data-architect`: Database schema and data flow design

- `ui-planner`: Interface structure and user experience planning

Synthesis Agent:

- `plan-synthesis-agent`: Reviews all plans, resolves conflicts, creates unified blueprint

Implementation Agents:

- `backend-engineer`: API endpoints and business logic

- `frontend-engineer`: UI components and state management

- `database-engineer`: Migrations, queries, optimizations

Verification Agents:

- `code-reviewer`: Assumption checking and cleanup

- `test-engineer`: Validation and edge case detection

Start with general-purpose agents to understand the flow. Then experiment with specialized agents as your tasks get more complex.

---

---

The Real Architecture: Focused Context Windows

Agents aren't just about doing more things at once. They're about creating isolated cognitive spaces where specific problems can be solved without interference from the larger context.

When you give Claude a complex task directly, everything competes for the same context window - your instructions, architecture decisions, implementation details, error handling, cross-system integration. We know from context rot, the more context a model takes in, the less older context contributes to the output. It all blurs together. With your instructions being the first and oldest context the model is going to have.

With agents, you can create boundaries. Each agent holds only what it needs.

---

The Orchestrator Problem

In the Response Awareness methodology, the main agent is forbidden from doing any actual work. No coding. No analysis. No verification.

This constraint exists because the orchestrator has exactly one job: holding the entire multi-phase plan. The full Response Awareness framework is ~1000 lines. That's a lot of complexity to maintain while also trying to write code.

I discovered this through failure. Early versions let the orchestrator "help out" with simple tasks. Every time, without exception, the overall plan quality deteriorated. Claude would begin struggling to clearly maintain and adhere to the plan.

The orchestrator must remain a pure coordinator.

Division Strategy

The orchestrator divides complex tasks into chunks small enough for individual sub-agents to hold clearly.

Example: Building a real-time collaborative editor.

The orchestrator creates:

1. Architecture Planning Agent: System design, data flow patterns

2. Data Synchronization Agent: CRDT or operational transform implementation

3. UI State Agent: Editor interface, cursor management

4. WebSocket Integration Agent: Real-time communication layer

5. Conflict Resolution Agent: Merge algorithms, race condition handling

Sub-Agent Context Management

Each sub-agent receives:

1. Task description

2. Phase-specific tags: Only metacognitive markers relevant to their role

3. Critical context: Key decisions from previous phases

4. Recognition patterns: Domain-specific uncertainty markers

---

If your not familiar with what I call meta cognitive tags, check out the two foundational Response Awareness articles behind this.

---

Tag Lifecycle

Meta cognitive tags are how agents communicate uncertainties and decisions across phases.

1. Planning agents mark key points:

- `#PATH_DECISION`: Multiple valid approaches identified

- `#PLAN_UNCERTAINTY`: Assumptions that need validation

- `#EXPORT_CRITICAL`: Architecture decisions for next phases

2. Orchestrator extracts and passes forward:

- Collects all exported decisions

- Removes tags from files (cleanup)

- Provides context to next phase agents

3. Synthesis agent creates unified plan:

- Reviews all PATH_DECISION points

- Selects optimal combinations

- Documents choices with `#PATH_RATIONALE`

4. Implementation agents mark their work:

- `#COMPLETION_DRIVE`: Implementation assumptions

- `#CARGO_CULT`: Pattern-driven code that might be unnecessary

- `#SUGGEST_ERROR_HANDLING`: Things that feel missing

5. Verification agents resolve everything:

- Check every assumption

- Remove unnecessary code

- Return structured reports

---

Model Selection Strategy

Not all agents need the same horsepower. After extensive testing, here's the optimal configuration:

High-Complexity Planning (architecture, data modeling):

- Model: Opus 4.1

- Thinking: `think_hard`

- Why: High assumption risk, need deepest analysis

Plan Synthesis (the critical integration moment):

- Model: Opus 4.1

- Thinking: `ultra_think`

- Why: This is where everything comes together - max cognitive power

Implementation (actually writing code):

- Model: Sonnet 4

- Thinking: `think_hard`

- Why: Quality implementation at efficient speed

Verification (checking assumptions):

- Model: Sonnet 4

- Thinking: `think` (regular)

- Why: Systematic checking without over-analysis

Deploy cognitive resources strategically. The synthesis agent gets `ultra_think` - it's making path decisions affecting everything downstream. Verification agents checking method existence/naming? Regular thinking suffices.

---

Why It Works

1. Each agent maintains focus - no context-switching between planning and implementing

2. The orchestrator never loses the big picture - stays focused purely on coordination

3. Information flows cleanly - tagged decisions pass between phases without noise

4. Assumptions get caught - multiple layers of review catch uncertainties

5. Cognitive load stays manageable - no single Claude gets overwhelmed

Practical Results

When applied to complex tasks (legacy refactoring, cross-system features):

- Better accuracy: Assumptions are marked and verified, not hidden

- Cleaner code: Pattern-driven cruft gets removed

- Documented decisions: PATH_RATIONALE tags explain non-obvious choices

- Managed complexity: Even massive tasks become manageable

- Preserved intent: Plan and instruction architecture doesn't drift as implementation progresses

---

Conclusion

The sub-agent system creates focused context windows where each Claude operates without cognitive overload. The orchestrator maintains the plan. Agents execute their pieces. Information flows between phases through orchestrator instructions, plan .md files, and careful tag management.

The complexity is worth it. Code matches original vision. Assumptions get caught. Integration points align.

You know that frustrating moment when you give Claude detailed instructions, and halfway through implementation it starts forgetting key requirements? The architecture you carefully specified morphs into something else. The constraints you emphasized get ignored. By the end, the code barely resembles what you asked for.

This isn't Claude being "dumb." It's context rot - a fundamental limitation when a single context window tries to hold planning, implementation, and all the decisions in between. This is a all too common result of context rot, as a model continues to take in more context, older context (your instructions being the first and oldest) degrades in impact on the models response.

The orchestration framework solves this. The orchestrator holds your requirements pristine while agents execute. No degradation. No drift. Your original vision makes it all the way through to working code.

---