Skip to main content
Kodelyth ECC
architecture

Opus 4.6 Agent Teams Just Shipped. Our Parallel Commands Have Been That for Eighteen Months.

Anthropic calls them agent teams. We call them /devil-mode, /team-review, and /debug-blitz. The shape is identical: specialist fan-out, parallel execution, synthesised return. Here is what we learned building eight of them before the pattern had a name.

· 6 min read

A central node labelled 'user prompt' fans out into eight parallel specialists each with its own worktree, then collapses back into a single synthesised reply.

Anthropic's Opus 4.6 announcement adds "agent teams" as a research-preview feature in Claude Code. The pitch: break a task into independent subtasks, run subagents in parallel, identify blockers with precision.

We shipped eight of them in April 2025 and called them parallel commands:

  • /team-review — code-reviewer, security-reviewer, performance-optimizer, api-guardian
  • /project-launch — architect, pair-programmer, security-reviewer, tdd-guide, ux-reviewer
  • /debug-blitz — debug-detective, silent-failure-hunter, env-debugger
  • /security-audit — security-reviewer, dependency-doctor, api-guardian
  • /refactor-sprint — refactor-cleaner, code-simplifier, type-design-analyzer, tdd-guide
  • /pre-release — release-captain, security-reviewer, code-reviewer
  • /onboard — code-explorer, architect, doc-updater
  • /devil-mode — prompt-injection-hunter, supply-chain-auditor, secret-hunter, backdoor-hunter (plus four more with --all)

Our devil-mode has 8 agents. If you asked us what it is in architectural terms, we would answer: "it is an agent team with an adversarial contract."

The validation of the pattern by a frontier lab is useful. It means teams who could not justify adopting the pattern when only ECC had it can now adopt it. The ground is more solid.

Here are the lessons that shaped how we built them — things the research preview will have to decide on too.

1. Fan-out is cheap. Fan-in is where the design is.

Spawning eight subagents is one Promise.all. Gathering their output into one coherent reply is a design problem.

Our pattern: each subagent returns a FindingList — a short structured object with {title, severity, file:line, fix}. The parent then synthesises, not concatenates. If three agents found the same bug from different angles, you see one finding with three evidence lines. If one agent found a false positive and another contradicted it, you see one line that says "A says X, B says ~X — showing both".

Concatenation produces reports that look like eight linters taped together. Synthesis produces a report that looks like one senior engineer who delegated.

2. Shared context is a cost trap

Each subagent gets its own context. That is the point — isolation is why parallelism works. But every subagent re-reads the files it needs. If four agents each read src/auth/*.ts, you pay for four reads.

Our mitigation:

  • Subagents receive a pre-digested project context from the parent — a 2-page summary of structure, stack, recent commits. They do not each re-read package.json.
  • Agents that need the same files are grouped so their reads land in the parent's prompt cache when they come back for synthesis.
  • We cap each devil-mode subagent at 15k tokens of context. If a specialist needs more, that is a signal to narrow its scope, not to lift the cap.

Opus 4.6's compaction API helps here — each subagent can self-compact between phases. We will adopt it as soon as it leaves preview.

3. Not every task benefits from a team

The disappointing truth: for a 20-line bugfix in one file, a single debug-detective agent beats a team of four on both quality and latency. Teams win on:

  • Multi-vector problems — security + perf + API contracts intersect in a single change
  • Pre-release gates — "would any specialist block this?" is a fan-in reduce
  • Adversarial sweeps — different attack mindsets catch different classes
  • Breadth-first exploration — a new codebase has more surface than one agent can walk

Our intent routing picks a team only when two independent signals from the same compound pattern fire (see the /debug-blitz trigger in intent-routing.md). The default is one agent, picked precisely.

4. Blocker identification needs a graph, not a list

Opus 4.6's announcement emphasises identifying blockers "with real precision". That phrase is the heart of what makes agent teams work in production, and it is the hardest part.

Our implementation: subagent findings carry a blocks field. If security-reviewer finds "auth bypass in POST /login", that finding carries blocks: ["release"]. When the parent synthesises, it computes the transitive closure of blockers and surfaces them first. A HIGH severity finding that does not block the user's actual goal (ship v2) is secondary to a MEDIUM finding that does.

Without the graph, a team report is a priority-queue of severities. With the graph, it is a DAG of what-to-fix-first.

5. The arena is the final form

The newest ECC pattern — /arena — is where the agent-team idea stops being a static fan-out and becomes a loop. A god crew builds, an evil crew attacks, both scored against a rubric, iterate until the attacker gives up or the budget caps.

Agent teams at Anthropic are a research preview. In our shop they are a 2-year-old pattern we have run thousands of times. Everything in this post is a lesson paid for in sessions that failed, synthesis that was useless, and reports nobody read.

If you are adopting agent teams for the first time: start with fan-in, cap the context, measure cost-per-task not time-saved, and skip the pattern when one agent would do.

Read how we wire them in Parallel Commands and Intent Routing v2.

Sources: