Project Aristotle said how a team works together beats who is on it. Agent-assisted work changes the how. Bigger teams now cost more to coordinate than they used to.
Bottom line. Keep teams small and give them hard boundaries. Adding a person to an agent-assisted team costs more coordination than it used to. The cost grows as the agents get more capable, since each person now produces more output for teammates to integrate. Design the team boundary and the agent’s scope at the same time. A fuzzy team boundary produces a fuzzy agent scope, and the result is cross-team overhead. Then protect the conditions that made teams work before any of this: psychological safety, dependability, and clear ownership. Those still decide the outcome. What changed is the size at which they stop being achievable.
Google studied 180 teams
Google ran Project Aristotle from 2012, studying 180 teams, 115 in engineering and 65 in sales, across 250 attributes. They expected to find a formula for team composition.
They found composition mattered less than interaction. Who is on a team predicted performance less well than how the team worked together, which is an uncomfortable result for any organization that staffs by collecting strong individuals.
Five factors separated the effective teams, in order: psychological safety, dependability, structure and clarity, meaning, and impact. Psychological safety came first by a wide margin and the other four rest on it.
Amy Edmondson’s underlying research has a detail that explains what the term means better than any definition. Studying hospital teams, she found the better-performing units reported more errors, not fewer. Her first reading was that good teams made more mistakes. The actual explanation was that they felt safe enough to report them. The error rate was not different. The reporting rate was.
She is also explicit that psychological safety is not about being comfortable. Her framework pairs it with high standards, and the combination she calls the learning zone. Safety with low standards produces a comfortable team that does not perform.
Five things that decide team performance
None of that has been overturned. The list is short.
People say “I do not know” and “this is broken” without first calculating the cost of saying it. That is the safety factor, and it is measurable through proxies like near-miss and error reporting rates.
Commitments hold. Dependability is second on the Aristotle list and it is the one that decays quietly, since a team where dates slip without comment stops being able to plan.
Ownership is clear enough that people know who decides. Structure and clarity is third, and most teams that feel chaotic are failing here rather than at safety.
Feedback arrives at the work, not at the review. That comes from a different literature, and the effect is large enough that delaying it inverts the result.
Teams stay together long enough to accumulate context. Reassignment churn destroys the shared history that makes a team fast, and the loss is invisible in any individual’s utilization numbers.
Agents changed the coordination math
Now the part that is new, and it affects team size rather than the factors.
A 2026 analysis of human effort scaling in AI-assisted work derives what the authors call an AI-era Brooks’s Law. The original observation was that adding people to a late project makes it later, because coordination cost grows with team size. The revision is sharper.
In the pre-AI case, adding a person adds one unit of throughput. The coordination cost scales with the number of people already there. In the agent-assisted case, each person commands agents that multiply their individual throughput, and that multiplied output raises the integration burden on their teammates. The marginal coordination cost of the next hire now includes a term that grows with agent capability.
Read that again with your own roadmap in mind. As the agents get better, the cost of adding a person goes up rather than down.
The authors’ practical prediction: organizations using AI heavily should converge toward smaller and more autonomous teams rather than larger ones. Five engineers with frontier agents can match the output of fifty without them, at a fraction of the coordination overhead.
That inverts the instinct most organizations are running on. The common plan is to adopt agents and grow, on the theory that amplified individuals compose into a more productive large team. The math says amplified individuals compose worse than unamplified ones, because the volume each person emits for teammates to absorb has grown.
Conway’s law now applies to agent scope
The second change is about boundaries, and it follows from an old result.
Conway’s law says a system’s structure mirrors the communication structure of the organization that built it. Applied to agent-assisted work, team boundaries now shape agent scopes, with the same consequences. Fuzzy team boundaries produce fuzzy agent scopes, and the cost shows up as cross-team coordination rather than as a visible failure.
The practical implication is a sequencing one. Team boundaries and agent scopes have to be designed together and up front, rather than reconciled later once the patterns are established and expensive to change.
There is a throughput ceiling in the same territory. Practitioner reports put the curve flattening somewhere above seven to ten parallel agents, unless the codebase is unusually modular. Each additional agent adds merge, review, and conflict-resolution overhead. The constraint is the same one that limits human teams, arriving through a different door.
Reading the five factors against agent work
Take the five factors and read them against agent-assisted work.
Psychological safety acquires a new failure mode. The old question was whether someone will say a colleague’s design is wrong. The new one is whether they will say an agent’s output is wrong, in front of a team that adopted the agent enthusiastically, when the output reads fluently and the objection is hard to articulate. Fluency makes disagreement harder, and that is a safety problem before it is a technical one.
Dependability changes shape. It used to mean I can count on your work. It now includes whether I can count on your review of something you did not write. A pull request comes with a different warranty depending on whether the author generated it and read it closely or generated it and skimmed it. Nothing in the artifact distinguishes those two cases.
Structure and clarity absorbs the boundary problem above. Clear ownership now has to specify not only who decides but which agent operates in whose territory.
Meaning and impact are the two nobody talks about, and they are where orchestration work is most exposed. An engineer who spent the day directing agents and reviewing output produced more than they would have alone, and may feel less connected to it. That is worth watching in your one-on-ones before it shows up in attrition.
Cap the team, write the boundary, ask for disagreement
Cap team size deliberately and treat the cap as a design decision. The number that worked at your company three years ago was set against a coordination cost that has since gone up.
Write the boundary before the agent. Every autonomous tool should have a scope that maps to a team’s ownership. Where you cannot state that mapping, you have found an ownership problem that predates the tool.
Ask explicitly for disagreement with agent output. A general invitation to speak up does not cover it. Contradicting a confident machine in front of enthusiastic colleagues costs more socially than contradicting a person.
Make review depth visible. Some teams tag pull requests with how closely the author examined the generated code. It is a small ritual and it restores information that dependability used to supply for free.
And keep measuring the old things. The five factors were not repealed. What went up is the coordination cost that determines how many people you can have while still achieving them. That argues for building smaller, not for building less.
Reader discussion