Team Composition Patterns: By Hand vs With an AI Agent
Choosing the smallest sufficient set of agents for a data task, and who assigns the roles
Team composition is the decision about how many agents a task gets and what role each one plays. Done by hand, an engineer guesses the team size and the review step from memory. Done with an agent, the Orchestration Agent selects the smallest sufficient set of swarm agents and assigns a lead, workers and a reviewer. The stakes are real: Anthropic reported that a multi-agent research system outperformed a single-agent baseline by 90.2% on its internal evaluation, while using about 15x more tokens than a chat. More agents help only when the task earns them.
Key Takeaways
- •Team composition means choosing the number of agents for a task and giving each a role: lead, worker or reviewer.
- •Over-staffing burns tokens and adds handoffs; under-staffing leaves work unreviewed. The goal is the smallest team that is still sufficient.
- •The dw-team-composition-patterns skill of the Data Workers Orchestration Agent selects the smallest sufficient set of swarm agents and assigns lead, worker and reviewer roles.
- •A human still approves anything that writes to production data, and still owns the decision to widen an agent's autonomy.
- •Evaluate an agent for this job by checking that it justifies team size, keeps a reviewer separate from the workers, and shows its reasoning.
The job and who does it today
Every multi-agent setup has a staffing question hiding inside it. A request such as 'Is the customer_id join safe after the migration?' touches schema, lineage and quality. Someone has to decide which agents take part, who coordinates them, and who checks the result before it reaches a person. In most teams that someone is a senior data engineer or platform lead, working from habit rather than a written rule.
The role is rarely a job title. It shows up as a prompt that an engineer writes in a terminal, a hand-built workflow definition, or a convention in a README that says 'always add a review step.' Because the decision is implicit, two engineers staff the same task differently. One sends three workers and no reviewer. Another sends one worker and reviews the output personally at midnight.
The Model Context Protocol specification gives the transport and the tool contract, so any compatible client can reach an agent. It deliberately does not say how many agents a task should use or what each should do. That judgment sits above the protocol, and today it sits with a human.
The manual workflow, step by step
When engineers compose a team by hand, the sequence is usually the same, whether or not anyone wrote it down. The steps below are the ones we see most often when a team wires several agents together without a coordinator.
- •Read the request and guess its scope: one table, one pipeline, or the whole domain.
- •List the agents or subagents that might apply, usually from memory of what is installed.
- •Pick a team size, often by copying whatever worked on the last similar task.
- •Name one agent as the coordinator and write its instructions by hand.
- •Decide whether anything reviews the output, and who that reviewer is.
- •Run the task, read the results, and adjust the team next time if it went badly.
Each step is a handoff between the engineer's head and a prompt file. The scope guess in step one drives everything after it, yet nothing checks that guess. If the request looked like a one-table question and turned out to span three pipelines, the team is already wrong before any agent runs.
The review decision in step five is the one most often skipped. A reviewer costs another agent run, so under deadline pressure it gets dropped. The cost shows up later, when an unreviewed change reaches a stakeholder and the engineer spends the afternoon explaining it.
Where the manual approach breaks
The first failure is over-staffing. An engineer who has been burned once adds more agents to every task. Anthropic's write-up is candid about the trade: agents typically use about 4x more tokens than chat interactions, and multi-agent systems about 15x more. Spending that on a task one agent could finish is waste, and every extra agent is another place for context to be lost.
The second failure is under-staffing. A single worker that both produces and checks its own output has no independent review. Anthropic's guidance on building effective agents recommends starting with the simplest solution and adding complexity only when it demonstrably improves outcomes. The word demonstrably matters: the team should grow because the task needs it, not because the last incident was embarrassing.
The third failure is drift. A team shape that fit last quarter's pipeline no longer fits after a migration, but the prompt file still lists the old agents. Nobody revisits it until something breaks. Hand-composed teams have no feedback loop, so staffing rules rot quietly while the data estate changes under them.
What the Orchestration Agent does instead
The dw-team-composition-patterns skill belongs to the Orchestration Agent. Its job, as defined, is narrow: select the smallest sufficient set of swarm agents for a task and assign roles, lead, workers and reviewer, so the task is neither over- nor under-staffed. It does not rewrite your pipelines or widen its own permissions. It decides who works on the request and in what role.
In practice that means the request goes in once, from Claude Code, Cursor or any MCP-compatible client, and the staffing decision comes back with a reason attached. A question like 'What's the blast radius if I drop this column?' may need a lineage-aware worker and a reviewer. A freshness check may need one worker. The agent starts from the small team and adds a member only when the task calls for it.
Because every Data Workers agent is an MCP server, the roles map onto agents that already exist rather than onto new infrastructure. The lead coordinates, the workers do the scoped pieces, and the reviewer checks the combined output before it is shown to a person. The engineer stops being the integration layer for staffing decisions and reads the proposed team instead.
What still needs a human approval
Choosing the team is a planning decision, not a license to change production. The open-source edition of Data Workers is read-only by default, so a composed team can investigate and propose but not write. Pro adds writes with approval workflows and audit trails. A human approves the first write, and that boundary does not move because a different set of agents ran.
A person should also own the autonomy setting. The Autonomous Data Conductor exposes a per-domain autonomy dial, so a team can run unattended in a domain where you trust it and stay supervised in one where you do not. Moving that dial is a human decision. The Orchestration Agent staffs work inside the limit you set; it does not raise the limit.
Finally, a human should review staffing exceptions. If the agent proposes a larger team than usual for a routine task, or drops the reviewer, someone should ask why. A good composition decision is explainable in a sentence, and the reasoning should be visible in the audit trail rather than buried in a prompt.
Manual versus agent, side by side
The table below compares the two approaches on the dimensions that matter for this job. It describes effort qualitatively, because team composition is rarely timed and we would rather not invent numbers.
| Dimension | By hand | With the Orchestration Agent |
|---|---|---|
| Scope assessment | Engineer guesses from the request | Agent assesses the task and picks agents from the swarm |
| Team size | Copied from the last similar task | Smallest sufficient set, grown only when needed |
| Roles | Written into prompts by hand | Lead, workers and reviewer assigned per task |
| Review step | Often skipped under deadline | Reviewer role assigned as part of the team |
| Consistency | Differs by engineer | Same selection logic on every request |
| Writes to production | Whatever the engineer wired up | Still gated by approval, regardless of team |
| Effort | Recurring senior-engineer attention | Engineer reads and approves the proposed team |
The rows that matter most are consistency and review. Two engineers staffing the same task should not get two different team shapes, and a reviewer should not be the first thing cut when time is short. Moving those decisions into an agent makes them repeatable.
The row where nothing changes is writes to production. We keep that line deliberately. Better staffing improves the quality of the proposal, not the authority to execute it.
How to evaluate an agent for this job
Do not judge a composition agent by how impressive its team looks. Judge it by whether its choices are defensible. Give it a handful of real requests of different sizes, from a single-table freshness question to a cross-pipeline impact question, and compare the teams it proposes. A good agent staffs the small task small and the large task larger, and says why in plain language.
- •Does it justify team size for each task, rather than defaulting to the same shape?
- •Is the reviewer a separate role from the workers, so no agent checks only its own output?
- •Does it start small and add agents only when the task demands it?
- •Are its decisions logged, so you can audit why a team was chosen?
- •Does it respect your permissions, staying read-only where you set read-only?
- •Can you reach it from the client your engineers already use, over MCP?
Keep a small set of regression requests and rerun them whenever the swarm changes. If the proposed team for a routine task suddenly grows, you have found drift before it costs money. This is the feedback loop that hand-composed teams lack.
Also read the open-source code and the Model Context Protocol repository to confirm the agent speaks standard MCP rather than a private protocol. Portability matters: a staffing decision that only works inside one vendor's client is a lock-in decision wearing a planning decision's clothes.
Frequently Asked Questions
What are team composition patterns in a multi-agent system?
They are the repeatable shapes a team of agents takes for a task: how many agents take part and which role each plays, such as lead, worker or reviewer. A pattern answers the staffing question before the work starts. The Orchestration Agent's dw-team-composition-patterns skill applies this by selecting the smallest sufficient set of swarm agents and assigning those roles, so the shape fits the task instead of a habit.
Is a bigger agent team always better?
No. Anthropic's own account of its research system shows the trade-off: multi-agent systems used about 15x more tokens than chats, so extra agents must earn their cost. The guidance in Building effective agents is to start simple and add complexity only when it demonstrably helps. That is the reasoning behind choosing the smallest sufficient team.
Does the Orchestration Agent write to my production data?
Not on its own. The open-source edition is read-only by default, and Pro adds writes behind approval workflows with audit trails. Composing a team is a planning step. A human approves any write, and the per-domain autonomy dial you set decides how much runs unattended in each area of your data stack.
Can I run this from Claude Code or Cursor?
Yes. Every Data Workers agent is an MCP server, so you can reach the Orchestration Agent from Claude Code, Cursor, Windsurf, VS Code, GitHub Copilot or any MCP-compatible client. You ask the question where you already work, and the staffing decision comes back with its reasoning. There is no separate dashboard to check.