Spawning sub-agents multiplies both capability and cost. The naive default — "one big agent loop that does everything sequentially" — is right surprisingly often. The cases where a swarm wins are specific: independent parallel work, adversarial review, exploration with multiple angles. This is the decision rule and the patterns that hold up.
LingCode supports both. A single agent runs a long conversation, accumulates context as it goes, and tackles tasks step by step — what most people mean when they say "Claude wrote the code." A swarm spawns one or more sub-agents, each with their own clean context and their own scoped task, run in parallel or in sequence, with results integrated by the parent. The marketing story is "more agents = better results"; the engineering reality is "more agents = more tokens, more synthesis work, more places to lose the thread." Both shapes have their place. Picking right makes the difference between getting work done faster and getting an expensive distraction.
The mental model that holds up: agents share nothing except what you explicitly pass. Each sub-agent starts fresh — no memory of the parent's earlier work, no shared scratchpad. The parent agent passes a prompt; the sub-agent does the task; the parent reads the result. That isolation is the swarm's power (parallel work without context contamination) and its cost (you can't ask a sub-agent to "continue what we were doing" — you have to re-explain). Tasks where the right move requires the full conversation history are exactly the tasks where a swarm hurts. Tasks where each sub-task is independent and well-scoped are exactly where a swarm helps.
This tutorial covers the decision rule, the four patterns that work, the three that don't, and the specific LingCode features (Explore, Plan, parallel Task spawning) that operationalize them. We'll use code-review and refactor scenarios as the running examples because that's where the contrast is sharpest.
If yes → swarm is a candidate. If no → single agent.
Examples that pass the test (sub-agents work fine):
Examples that fail the test (single agent wins):
When you find yourself thinking "I'll spawn one agent to do the planning, then another to do the work" — pause. The planner's context is exactly what the worker needs; spawning a separate worker means re-feeding all of it. A single agent with a "plan-then-act" prompt usually beats two sequential agents because no context is lost in handoff.
Pattern 1: Parallel independent work. N tasks, none depend on each other, results combine at the end. The canonical case: "audit these 5 services in parallel." Five sub-agents run simultaneously; total wall-clock time ≈ longest single audit, not sum of all audits. Token cost scales linearly with N but you're paying for actual work, not coordination.
Pattern 2: Exploration with multiple angles. "Try three implementation approaches for this feature." Each sub-agent attempts one approach in isolation. The parent reads the three results and picks (or synthesizes). Wins when you'd otherwise commit to one approach prematurely; the parallel exploration catches the case where approach #2 was clearly better but you'd never have written it.
Pattern 3: Adversarial review. One agent produces output; a second agent — with a clean context — reviews it. The reviewer's lack of context is the feature: they catch things the author rationalized. The classic version is "writer agent + editor agent" but it works for code (proposer + critic) and design (designer + skeptic). Two-agent minimum; more reviewers don't usually help.
Pattern 4: Long-horizon plans with isolated stages. Some workflows have stages that legitimately don't need each other's working state — "research this topic" then "draft a doc using the research" then "format and lint the doc." Each stage's output is the next stage's input; intermediate scratch doesn't need to survive. A sequence of sub-agents (each fed only the prior's final output) keeps context budgets low and lets each stage focus.
Anti-pattern 1: Spawning a sub-agent for a small task. If the task fits in 5–10 sentences of prompt and would take the parent under a minute, spawning a sub-agent adds setup overhead (re-explaining context, re-loading any tools the sub-agent needs) that exceeds the actual work. Threshold: only spawn for tasks that need their own dedicated context window or take genuine minutes of compute.
Anti-pattern 2: The orchestrator-for-its-own-sake. Spawning a "manager" sub-agent whose only job is to spawn other sub-agents. The manager has no skill the parent lacks; it just adds a token-spending hop. If the parent can decide which sub-agents to spawn, the parent should spawn them directly.
Anti-pattern 3: Chained sub-agents that should be one conversation. "Agent A reads the file, Agent B analyzes what A read, Agent C writes the fix." If A's understanding of the file is what B and C need, the chain is paying re-explanation cost at every handoff. A single agent reading the file and then doing A→B→C in conversation wins. The rule of thumb: if the natural data flow between stages is everything the prior stage knew, the stages should be one agent.
Sub-agents have no memory of the parent's reasoning. Whatever the parent passes is all they get. Two common mistakes in parent prompts:
A good parent prompt to a sub-agent reads like a self-contained bug report: enough context to do the work, no narrative about why the parent decided to delegate.
LingCode exposes the patterns above as specific tools:
.claude/agents/ — define your own with constrained tool sets. Useful for repeated specialized tasks ("the SQL-injection auditor"). See Write a subagent.The pattern matrix:
The output of a swarm is N partial answers. Combining them is its own task — and the most common place a swarm setup degrades into worse-than-single-agent results. Three approaches:
If synthesis is genuinely hard — the sub-agents produced overlapping, contradictory, hard-to-reconcile outputs — that's often a sign the task didn't actually pass the "independent sub-tasks" test from Step 1. Reconsider whether a single agent would have produced a cleaner answer.
Task: "Add tests for these 8 modules that have no test coverage." Each module's test suite is independent; the modules don't share code under test. Pattern 1. Spawn 8 general-purpose subagents, one per module, in parallel. Wall-clock time ≈ longest single test suite. Cost ≈ 8× single agent on one module. Worth it.
Task: "Refactor this 50-file codebase from JavaScript to TypeScript." Every file's typing depends on imports / exports of other files; type definitions established early constrain later files. Single agent. A swarm would re-derive the same type model in each sub-agent and produce inconsistent type definitions across files. Sequential agent that holds the type map in context wins.
Task: "Investigate this production crash." Debugging is inferential; each new piece of evidence redirects the next step. Single agent. Spawning a "log reader" and a "stack tracer" and a "git blamer" produces three partial views that the parent has to reconcile — exactly the work the single agent would have done while reading the artifacts itself, with full context.
Task: "Write a marketing landing page; have one agent draft it and another critique it for clarity." Adversarial review benefits from clean context. Pattern 3. Author drafts; critic reviews without seeing the brainstorming; author revises based on the critique. Two agents, sequential, not parallel.
The most reliable default in 2026 is "one agent, long context, careful prompt." Modern Claude models handle 200K-token contexts well; modern tooling lets a single agent inspect 100s of files in one run. The cases where swarms add real value are specific and increasingly few — the model improvements that closed the "context too small" gap also closed most of the case for swarms. Use them when the task genuinely has independent parallel structure, or when adversarial isolation between author and reviewer is the point. Skip them when "more agents" is just decoration.