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

From beginner to expert

I’ve been working extensively with Claude Code’s agent system while developing my Response Awareness methodology. Anthropic’s 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 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: “Please spawn a subagent and find all authentication-related files in this codebase and list their dependencies” (or whatever task you need).

That’s it. Claude spawns a sub-agent that searches, analyzes, and reports back. Claude can deploy agents in parallel, so multiple agents can work simultaneously.

For beginners, general-purpose agents work fine for everything. But as you scale up and implement Response Awareness methodology, specialized agents perform better:

Planning Agents:

• system-architect: Overall system design and integration

• data-architect: Database schema and data flow design

• ui-planner: Interface structure and user experience

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 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 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. Context rot kicks in: the more context a model takes in, the less older context contributes to output. It all blurs together, with your instructions (being first) fading fastest.

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

The Orchestrator Problem

In Response Awareness methodology, the main agent is forbidden from doing 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 too much complexity to maintain while also writing code.

I discovered this through failure. Early versions let the orchestrator “help out” with simple tasks. Every time, without exception, overall plan quality deteriorated. Claude would struggle to 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

---

For Background on what i mean by metacognitive markers, check these related articles:

---

Tag Lifecycle

Metacognitive 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 needing 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 (critical integration):

• Model: Opus 4.1

• Thinking: ultra_think

• Why: Everything comes together here—use max cognitive power

Implementation (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? 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 marked and verified, not hidden

• Cleaner code: Pattern-driven cruft 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 during implementation

---

The Problem This Solves

You know that frustrating moment when you give Claude detailed instructions, and halfway through implementation it starts forgetting key requirements? The architecture you specified morphs into something else. 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. As a model takes in more context, older context (your instructions being first and oldest) degrades in impact.

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.

---

---

Related Articles: