What is an agent team? A set of subagents, each with its own context window, prompt, and tool permissions, coordinated by a main agent that owns planning and integration. The specialists do bounded work. The coordinator decides what happens next.
The useful way to think about one is not roles. It is permissions. A subagent is a boundary around what a piece of the system can read, can change, and can do without asking. Name it whatever you like. The permission set is the design.
The unit is the permission, not the persona
Most agent team diagrams are org charts. Planner, builder, reviewer, writer. That framing produces teams that look sensible and behave badly, because the interesting question was never what to call the agent. It is what the agent can reach.
A research subagent that reads your ticket tracker and your call transcripts but writes nowhere is a safe thing to run every morning. The same subagent with write access to the tracker is a different product with a different risk profile and a different review requirement. Same prompt, same model, same name. The permission set changed and so did everything that matters.
This is also why adding an agent to a shared channel is an access decision rather than a convenience. Whatever the agent can query, everyone in that channel can now ask for. If the agent reaches the warehouse, channel membership is warehouse access with extra steps.
Which subagents a product org actually needs
Engineering agent teams are well mapped by now: implementation, test repair, security review, migration. Product orgs have been slower, and the temptation is to copy the engineering split. It does not transfer, because the work is shaped differently.
4 that earn their keep. A research agent that reads support tickets, sales call notes and churn surveys on a schedule and reports what changed, read-only, writing nowhere. A data agent that answers questions against the warehouse and is required to show the query it ran. A drafting agent that works from your own templates and prior documents, which is the one that gains most from having your team's real conventions available to it. And a monitoring agent that watches the release path and says what shipped, what regressed, and what is still open.
None of those is exotic. They work because each has an obvious blast radius and an obvious owner. The agents that fail are the ones defined by ambition rather than scope.
Context obesity is the failure mode
The most common way a multi-agent system degrades is not a wrong answer. It is a full context window. Agent A produces something verbose, agent B receives all of it, agent B's window fills with low-signal text, and agent B misses the one line that mattered.
Nothing errors. No step failed. Every individual agent did its job and the system still produced the wrong outcome, which is exactly the class of failure that ships, because the tests that would catch it are not the tests most teams write.
The fix is unglamorous. Pass keys, not payloads. Agent A writes its output somewhere durable and hands the next agent a reference plus the 3 fields it needs. Every token in a context window competes for attention, and precision drops as the window fills, so the discipline is deciding what stays out.
Handoffs are where quality dies
Step-level evals check each agent in isolation and will happily pass a pipeline that fails end to end. Handoff evals check what agent B received and whether it was enough. Those catch context obesity. The first kind never will.
Run the full pipeline against real tasks and track completion rather than per-step accuracy. Per-step accuracy is an engineering number. Task completion is the product number, and it is the one that predicts whether anyone keeps using the thing. End-to-end runs are slow and expensive, so they belong on release candidates rather than every commit.
This is the same grading problem AI products face at the customer boundary, and the same answer applies: the suite sits in the release path or it is a report. I worked that through in Evals Are the New QA, and the question of who checks the checker in Who Grades the Grader.
What stays human
3 things, and they are the same 3 whether the team is 2 agents or 20.
The pass bar, because good enough for an internal summary and good enough for something a customer reads are different standards, and no agent sets that line for you. The scope call, meaning the decision to hold something back because it is not ready, which is a judgment about consequences rather than quality. And the kill switch, which has to exist, be tested, and belong to a person allowed to use it without asking permission.
Everything else is negotiable. Those 3 are why the system is accountable to anyone, and giving them away is how a pilot becomes an incident.
How to know it is working
Not by counting agents. A team of 2 that ships beats a team of 8 producing artifacts nobody reads, and agent count is the vanity metric of this discipline.
The signal is whether work that used to wait now moves. Research that happened when someone had a free afternoon happens weekly. The data question that took 3 days of asking gets answered in the channel where it was asked. If a human still reviews every output line by line before it is usable, you have not built a team. You have built a slower way to do the work yourself, and the fix is almost never a better prompt. It is a narrower job.
Which is the same reason most agent pilots stall before production, a pattern I went through the surveys on in Production Is an Org Problem.