Anthropic's Subagent Rules: Fold Them, and Split by Context

0:00Ray Amjad — software-factory educator and the builder behind Impell.AI — digs into Anthropic's sub-agent design article (Oct 22). The message: if you built an agent with a bunch of sub-agents, a lot of them should probably be folded back into your main agent loop. Written for customer-facing agents, but he argues the ideas transfer to coding agents.

When to keep a subagent

1:18First, the positive cases — a sub-agent is its own context window, tools, and instructions. Keep one when: (1) a single loop hits a measurable performance degradation (not "I said something twice" — an actual drop in your eval); (2) you have independent parallel tasks, each with a fresh context window you can throw away; (3) one agent struggles to pick the right tools, or your system prompt has conflicting instructions. Anthropic leans on evals throughout — use /claude api with build-eval to build them.

The org-chart trap

2:15What Anthropic's Applied AI team kept seeing: enterprises give each team (or problem type) its own sub-agent, and the architecture ends up "a copy of the org chart" — Conway's law in practice. The e-commerce example: a shipping agent, an orders agent, a refunds agent, an orchestrator routing between them. Five failure modes follow: context management (details lost in handoffs), sub-agent sprawl (a returns agent and a refunds agent and a "returns-and-refunds" agent because nobody checked — companies end up with hundreds of overlapping agents, no shared standard, no single owner), the Franken prompt (every team adds a sentence, rules conflict, no consistent voice), isolated testing (each team tests its own agent, nobody tests the whole system), and latency (a complicated multi-agent harness is often slower and worse than a single loop). 5:11His own data point: his old video-editing flow split clips into 30–60s segments for parallel agents — "janky, full of mistakes, no single agent could see the entire picture." One agent doing the whole edit won.

Why a single loop works

6:43Three reasons. Shared context: a long-running agent that has seen every earlier step connects dots that a set of handed-back summaries can't — fewer context windows, fewer lossy handoffs. The 150K "dumb zone" is a myth: 7:11"I haven't seen any evidence for that number coming out of the labs." It may have been true for Opus 4/4.1, but he regularly pushes Opus 5.5 to 400–500K tokens and gets good results. Progressive disclosure prevents bloat — split monster skill.md files into smaller ones and Claude Code loads the right context at the right time. And models are more capable — they manage far more in one loop than expected, and given the right tool they check their own work (give the refund-status tool and the model verifies the refund went through without you writing that rule).

The personas anti-pattern

9:37An Anthropic engineer's tweet he cites: "I don't want to manage agents with different personas. If intelligence is truly super, there should be no need for roles. Smart generalists rule the world." He tested it himself: switched his software factory to a chief-of-staff chatting with a QA agent, security agent, analyst, builder, reviewer, growth agent… The result, per his own Claude-analyzed comparison: "product output is down, quality per PR is unchanged, cost per PR is flat, and a bunch of new layers added nothing — plus a brand-new coordination tax." He switched back. "Personas are just not worth it" — maybe they will be when agents work better in teams, but by then you may not need to define them at all.

Swarm scaling: λ

11:16The framework that made it click is Toby Ord's "Swarm Scaling". Economists model team work as: n people get as much done as one person working n^λ times as long — where λ is "the stepping-on-toes parameter." λ = 1 is perfectly parallelizable; in reality λ is usually between 0 and 1. If λ = 0.5, then 100 people = 1 person × 100^0.5 = 10× as long. Estimates put coding benchmarks (like Terminal-Bench) at λ ≈ 0.5 — "in line with economists' estimates for human teams." The precise λ depends on the task. The implication: just like you wouldn't put a 15–20-person team on a single feature, don't do it with agents. If a future model reached λ ≈ 0.9, he'd revisit multi-agent — but today's models are bad at judging how parallelizable a task is, so the coordinators do a poor job.

Split by context

15:20The concrete reframe, via a team-invites feature. Split by problem type = backend agent, frontend agent, tester, security reviewer — all four need the same knowledge (the spec, the token format, "invites expire in 7 days"), so you either over-define up front or lose things in handoffs (the backend decides emails are stored lowercase; the frontend never hears). Split by context instead: one implementer does endpoint + modal + accept page in one window, so the lowercase decision applies everywhere. The question changes from "what kind of work is this?" to "would what the main session already knows help, hurt, or not matter?" A code-review agent gets a fresh window (spec + diff only, so it doesn't inherit the implementer's blind spots); a verifier gets even less (just which flow to verify); a research agent needs nothing from the project. The two patterns that survive: generator-verify and orchestrator sub-agents — where you split by context, not problem type.

The ticket anti-pattern

18:43The biggest coding-agent mistake he sees: write a spec, have an agent split it into 5–20 tickets, implement each in a fresh sub-agent. "Agent seven might miss something agent three already learned." A single implementer doing the whole spec in one context can correct itself as it discovers what the spec missed. 22:28The second anti-pattern: run those tickets in parallel under a coordinator — because λ is still small, the coordinator does a bad job knowing what's truly independent, and "tickets that look independent are often tangled together in ways you can't see." His day-to-day instead: spec → one implementer in one context (compaction handles it — he's monothreaded sessions compacted 20–30 times over weeks, still performing) → a code-review agent (fresh window, spec + diff) → verification agents running user flows, which he parallelizes by forking a sandbox N times (each flow gets its own DB/Redis), compiling the results back to the builder. That parallel verification is real parallelism — where λ is high.

The bitter lesson

25:36The through-line is Rich Sutton's Bitter Lesson: "the crutches we introduce to make a model work better end up no longer being needed when a new model comes out — and most people don't get rid of those crutches, which can actually hold a new model back." He now runs only two skills ("task lifecycle" and "idea to spec"), actively trimming them toward deletion. His closing recommendation: fold your sub-agents into the main loop, split by context, and let the model decide if it needs a sub-agent. "As models get smarter, you want to cut the ceremony in your setups."

Claims checked

Sources & further reading