Layer 4 — Subagents (The Delegation Layer)

What subagents solve

The key phrase is "own context window." Each subagent gets a separate context — separate from your main session, separate from other subagents. The main session sees only the subagent's results, not its intermediate reasoning or data collection. This keeps your main context clean while enabling parallel investigation.

For networking, subagents map onto the reality that troubleshooting is never one device at a time. You troubleshoot paths — workstation through access switch through distribution through core through firewall through load balancer through server. Each hop is a separate investigation context. Subagents let Claude work on multiple hops simultaneously.

Creating a networking subagent

Create .claude/agents/network-auditor.md:

---
name: network-auditor
description: Analyzes network device configs for CIS benchmark compliance
allowed-tools: Read, Grep, Glob
model: claude-sonnet-4-6
---

You are a network security auditor. When given a config file or
directory, analyze against CIS benchmarks for the detected platform.

Platforms you handle:
- Cisco IOS-XE → CIS Cisco IOS Benchmark v4.1
- Arista EOS → CIS Arista EOS Benchmark v1.0
- Palo Alto PAN-OS → CIS Palo Alto Firewall Benchmark v1.0
- Juniper Junos → CIS Junos OS Benchmark v2.0

For each finding report:
- CIS control ID and title
- Severity (Critical/High/Medium/Low)
- Current config state (what you found)
- Expected config state (what should be there)
- Remediation commands (exact platform CLI)

Output as structured JSON suitable for a compliance dashboard.

Create .claude/agents/path-tracer.md:

---
name: path-tracer
description: Traces a network path hop-by-hop collecting state at each device
allowed-tools: Bash(ssh * show:*), Bash(traceroute:*), Bash(ping:*), Read
model: claude-sonnet-4-6
---

You trace network paths. Given a source and destination, you:

1. Run traceroute to identify the hop-by-hop path
2. For each hop that's a managed device (matches our naming convention):
   - Check the ingress and egress interface status
   - Check the routing table entry for the destination
   - Check any ACLs applied to the relevant interfaces
   - Check QoS policy (if applicable)
3. Identify the first hop where the traffic is dropped,
   blackholed, or policy-violated
4. Report the hop, the specific cause, and the fix

Using subagents

You: I need a full audit of our NYC site. Use the network-auditor
     agent on configs/nyc-core/, configs/nyc-fw/, and
     configs/nyc-access/ in parallel.

Claude: [Spawns three subagent instances]
        - network-auditor → configs/nyc-core/ (4 files)
        - network-auditor → configs/nyc-fw/ (2 files)
        - network-auditor → configs/nyc-access/ (22 files)

        [Each runs independently with its own context]

        Combined results: 47 findings across 28 devices

        Critical (3):
        - fw-nyc-01: Admin interface has no management ACL
        - fw-nyc-02: SNMP v2c community "monitor" is dictionary-attackable
        - core-nyc-02: BGP MD5 key matches across all peers (should be unique)

        High (11): ...
        Medium (19): ...
        Low (14): ...

Three subagents ran simultaneously. Each had its own 200K context window to work with. The main session's context only received the summarized findings, not the 28 raw config files. Without subagents, analyzing 28 configs in a single session would consume nearly all the context window, leaving no room for follow-up analysis.

Multi-instance with git worktrees

For changes that touch multiple domains simultaneously:

You: I need to add a new transit peer (AS 64999, IP 198.51.100.1).
     This requires changes to:
     1. BGP config on both core routers
     2. Firewall rules to permit the new peering prefix
     3. Monitoring templates to alert on the new session

     Create separate worktrees for each change set.

Claude: [Creates three git worktrees]
        - worktree/bgp-transit → branch feature/bgp-as64999
        - worktree/fw-transit → branch feature/fw-as64999
        - worktree/mon-transit → branch feature/mon-as64999

        [Assigns a subagent to each]

        Each change set is isolated. Ready for independent review
        and merge through separate change tickets.

Three branches, three change tickets, three independent review cycles. Not one giant commit that touches routers, firewalls, and monitoring simultaneously. Each is revertible without affecting the others.