How many agents does a task actually need?
When I first began running several AI sessions, the visible unit of capacity was a window. If there was room for another one, there was room for another task.
That is an easy way to start. It becomes a poor way to decide how work should be organized.
In late August, I added more explicit director and implementation roles to the repository workflow. The purpose was to make delegation deliberate: who owns the change, what help is useful, and who decides whether the result is acceptable.
The question I ask now is what an additional agent would contribute that the current task cannot efficiently do on its own.
Separate independent work from repeated work
A read-only investigation can be useful while implementation is underway. One agent can inspect a neighboring contract, another can analyze a failure, and the writer can remain focused on the change.
That arrangement works when the findings inform different decisions. It works less well when three agents read the same files, produce similar summaries, and require me to reconcile the wording.
The same issue appears in review. A second look is valuable when it has a distinct responsibility: checking a runtime path, examining a risky assumption, or judging visual quality. A second agent that accepts the first agent’s explanation adds little independent evidence.
Keep routine work small
A contained fix often needs one implementation owner and a focused check. Making it pass through a planner, director, implementer, reviewer, and verifier can increase coordination without changing the quality of the decision.
My starting point depends on the work:
| Task | Useful initial shape |
|---|---|
| Known fix in one subsystem | One writer and the relevant check |
| Unfamiliar subsystem | A bounded investigation before implementation |
| Two independent changes | Separate owners with an explicit integration point |
| Consequential shared contract | A deliberate design decision and independent evidence |
These are defaults, not a requirement to create roles for their own sake.
I want more structure when the risk justifies it: shared contracts, consequential state changes, ambiguous design, or work that spans independently owned systems. I want the workflow to become simpler when inspection shows that the task is straightforward.
That requires the person directing the work to keep making judgments. A fixed number of agents for every task is easier to automate, but it is not automatically a good allocation of attention or compute.
Use model capability where uncertainty is high
The difficult part of a task is not always its largest diff. A small architectural choice can have more consequences than a long, mechanical implementation.
I prefer to spend more reasoning effort on unclear goals, competing designs, and decisions that are expensive to reverse. Once those decisions are made, a bounded implementation brief can let a less expensive worker proceed with useful autonomy.
The boundary is practical, not ideological. If the worker repeatedly needs help understanding the task, I may have chosen the wrong scope, supplied inadequate context, or assigned a problem that needs stronger reasoning.
Changing the model is one option. Improving the assignment is another.
My attention belongs in the calculation
Agents can run in parallel while their results still arrive at one human review queue. If I cannot evaluate the work promptly, increasing the number of writers can make the system less manageable.
I would rather leave capacity unused than create overlapping changes I am not ready to judge. I can also redirect capacity toward a bounded investigation that will make the next decision easier.
The useful number of agents changes with the task. I want each one to have a concrete contribution, a clear owner for the result, and a reason its work is worth integrating.
The guardrails essay covers the ownership rules behind these choices.