You have read the claim by now, probably more than once.
“One person with AI agents can do the work of an entire team.”
It appears in headlines, in conference keynotes, in articles that get forwarded around. The multiplier shifts depending on who is writing; sometimes it mentions the work of four people, sometimes ten, but the confidence behind it never wavers.
So we tested it on our own internal delivery projects, with deadlines and our normal review standards, and with the teams rebuilt around coding agents rather than around people. If the squad of one worked anywhere, it should have worked here.
It did not, quite. But the way it fell short turned out to be more useful than a clean result would have been. Agents took over most of what we used to call the work: writing code, running tests, and producing the first version of almost everything. What they could not take over was the decision. That left us with a question no tool vendor can answer: Who do you actually need on a team once production is no longer the constraint?
For as long as anyone has planned software teams, headcount has followed the volume of work to be produced. More screens meant more developers. That link has broken, because production is now the affordable part, and nothing has automatically replaced it as the basis for team sizing. Carry on as before, and you pay for capacity you do not need. Cut on the assumption that agents replace people, and you lose the judgment that made the tools worth buying.
Count decisions rather than output
The useful reframe is to stop asking how much work needs to be produced and to start asking how many decisions a person needs to own.
Most companies hand everyone a tool and keep the organisation chart. The same six functions, the same handoffs, each step somewhat faster. The alternative is to redesign the team around the decisions it has to make. When we did that, the core of a squad came to three people.
-
One person owns what should be built and why, and keeps the shared context that the agents draw on accurate and current.
-
One person owns the software architecture: how the system is designed and built, how any AI model is integrated into it, the quality bar, and the tests that prove it works.
-
One person owns the data science decisions: which model to use, how to fine-tune it, and what the data pipeline needs to supply.
Two further roles support every squad rather than belonging to one. The design steward sets the standards and the automated checks that keep every screen looking and behaving like the company’s products. The tools and standards role builds the tooling and guardrails all teams run on. Work that used to pass through six specialists now runs through three people with agents in between, while these two shared roles build the tools and hold the hard lines.
The map below shows the two paths side by side. Read it as a process map, because that is the decision it represents: which handoffs you remove, and who owns what is left.
What our trial runs showed
The trial ran within our own AI transformation programme, which had two goals: to grow our capability in enterprise AI transformation work and to change how we work. One of the simplest changes was to have AI engineers own and manage their projects, with leadership supporting programme management and external communications. In most cases, two people carried the scoping, discovery, planning and proof-of-concept delivery.
The speed gains were real. In our trial runs, reaching a working prototype was five to seven times faster: work that took two to three people over a week was done by one person in one to two days, where the work was clear and bounded.
The more important finding was where the constraint moved. Agents produce far more than a team can comfortably check, so the bottleneck shifted from production to review. The pull request, the design check and the acceptance decision became the slow points. That is where the next investment goes: harnesses around the agents, and tools to sift what they produce.
Most of that result came from greenfield work, where agents had a clean start. Making it work on existing systems is harder, and for us, it is only now taking off. A 2026 paper reported one staff engineer delivering an initiative on an existing system, scoped for a four-person squad, in half the planned time. That depended on a clear product boundary, a readable codebase, and a knowledge base that the agents could reach within governance guardrails. The model breaks down when a decision exceeds what one person can hold, and it becomes a business risk when only one person understands how those decisions were made.
Accountability did not move at all. However fast the agents work, they do not own the result. The person who assigned the work does. Every piece of work in our teams carries a person’s name, and the agents answer to a reviewer, never the other way around.
Where to start this quarter
Begin with one delivery team.
-
List the decisions it actually makes and put a name against each. Anything with no owner, or with two, is where the reorganisation should start.
-
Next, review the next few roles in the hiring plan and ask which ones produce work and which ones decide or review it. The answer shows how well the plan reflects how the work currently gets done. None of these forces a smaller headcount. You can keep your people and take on several times the work by running more small teams in parallel. The rule for adding someone stays the same either way: add a person when there is a new set of decisions to own.
-
To test it, pick one well-bounded part of the business, give one person real ownership of the result, and run it for six weeks on normal systems and normal review standards. Measure whether the new way of working holds after the six weeks end, alongside what it produced.
We ran this on our own projects, and the findings changed how we staff our work. The full findings, the roles in full detail, where the bottleneck moved, and how to run the same six weeks in your own organisation here: Reorganise Your Team in the Agentic Era
