A hard-looking request is not automatically a reason to launch five specialists and a manager. Sometimes it requires one retrieval, one calculation, or one careful reasoning step. Team composition is useful when it reduces a real problem, not when it makes the architecture diagram look sophisticated.
Start with the shape of work
Take the request 'Explain why our margins fell this month.' The system may need sales data, purchasing data and a calculation. The first question is not how many agents to launch. It is which domains are involved, whether tasks are independent, which evidence is required, and whether the result has one or several independently verifiable outputs.
A narrow, well-known computation can run in a controlled compute environment. It does not need a dedicated coding agent just because code is involved. A request for one domain-specific judgment may benefit from a specialist profile without creating a new durable child task.
Useful team composition begins by describing the work itself.
Expertise is different from a child task
A specialist is a source of expertise or constraints for a given assignment. A child Execution is an independently addressable unit with its own state, evidence, retries and possibly an external wait. These are not synonyms.
For instance, a finance worker could briefly consult procurement expertise while reconciling three-way matching rules. If the procurement check requires contacting a supplier and waiting a week, that may become independently durable work. The distinction affects recovery and the way the user sees progress.
A runtime that spawns child agents for every small consultation pays coordination costs before it has produced value.
Candidate structures instead of unlimited debate
A practical design can generate a small set of plausible compositions: one generalist, one specialist, specialist plus compute, two parallel independent specialists, or a coordinated multi-stage team.
Reject impossible candidates early: missing capability, forbidden authority, unavailable provider, exceeded budget or incompatible work dependencies. For a genuinely bounded choice set, a compact decision system may choose among valid candidates. Open-ended reasoning becomes appropriate when the task cannot be described by those structures.
The point is not to ban open reasoning. It is to avoid paying for it when a smaller, testable decision would do.
Parallel when independence is real
Parallelism helps if subtasks can progress without stepping on one another. Sales and purchasing analysis over separate evidence might proceed independently and join into a margin explanation.
Parallelism hurts when workers depend on shared mutable state or make assumptions that will be invalidated by another worker's writes. In that case, a sequential plan or explicit coordination can be more reliable.
A parent Execution should know what it delegated, what each child must return, and which conditions allow a join. A pretty team diagram is not enough.
Teams can change without restarting
A task may begin with one generalist, encounter a missing domain-specific rule, and add the right expertise. Or it may discover that an external approval will take a week and separate that dependency from the interactive work.
This requires a governed re-composition boundary. The system cannot arbitrarily multiply workers as soon as progress slows. It should identify the actual gap—evidence, computation, expertise, authority, or timing—and adapt that dimension.
The smallest adequate team is a moving target, but it should change for a reason.
Benchmark the team, not its story
Before calling a composition strategy smart, compare it against one generalist and simple deterministic baselines. Measure completion, cost, elapsed time, wasted calls, duplicated work and verification quality.
A system that launches fewer workers but still meets the goal may be better than one with an elaborate multi-agent trace. There is no prize for the largest number of agents.
The ambition is to treat collaboration as a resource allocation decision rather than a default persona pattern.
