One job, one agent; one task, one tree
Three patterns, three sweet spots
Assignable agentic work falls into three patterns. A single agent is right when the work is one piece of writing, one file, one focused conversation; the simplicity is the value. A sub-agent is right when a larger working session needs a specialist with a clean memory for one bounded task — research a topic, review a document, generate variants — and the result is then returned to the main session. An agent team is right when several pieces of work need to share state and coordinate, each with its own context, reporting to a shared task list rather than to a single hub. Each pattern has a sweet spot, and using the wrong one is more expensive than using the wrong words.
The single-agent default
Most work is well served by a single agent. The pattern is cheapest in tokens, simplest to debug, and easy to keep oriented because everything visible is happening in one place. The instinct to reach for multiple agents on simple work is almost always wrong; it adds coordination overhead, multiplies cost, and produces less predictable results. The right test for whether to leave the default is whether the current task has at least two genuinely independent sub-tasks that would benefit from clean memory. If the answer is no, the single agent stays in place.
Worktrees as the parallelism primitive
A worktree is a mechanism for letting more than one agent operate on the same project without interfering with each other. Each agent gets its own working copy, on its own branch, drawing from the same shared history. The result is that several agents can work in parallel on different parts of the same project — a feature here, a bug fix there, an experiment somewhere else — without overwriting each other's changes. The mechanism is simple to use and surprisingly powerful in practice. The discipline is to use worktrees deliberately for tasks that are genuinely independent, rather than to spawn parallel agents on work that should have stayed sequential.
The routing decision with cost in mind
Each pattern has a cost signature. A single agent is the cheapest because everything happens in one context. A sub-agent adds the cost of a separate context but usually saves more in clarity than it spends. An agent team adds the cost of several contexts and shared coordination, and only earns its keep on genuinely parallel work. The honest routing rule is to start with a single agent, escalate to a sub-agent when the working session begins to feel crowded with sub-tasks, and reach for an agent team only when the work is genuinely structured as several specialists collaborating on a shared output. The rule produces lower bills and clearer thinking at the same time.
Of the pieces of work you currently run through an assistant, how many could in principle be running in parallel right now, and what is stopping that from happening?