The first artefact I build for any program is the team plan. It is also the artefact I am asked for first by the leadership team and by procurement. “How many people do you need? When do you need them? Where will they sit on the org chart?”
For twenty years, I had a clean answer. I knew how to size a team by application complexity, by phase, by velocity assumptions. I knew the calibration points, the right ratio of seniors to juniors, the right span of control for a tech lead, the cost of bringing on a partner versus going internal.
That clean answer doesn’t survive contact with an AI-native delivery model. The simplest reason: half the team isn’t people anymore. The agents are doing the work. The humans are navigating them. The team plan has to show both, with names on both sides, and a clear pairing of which human navigates which agent.
The question that doesn’t work anymore
“How many people do I need” assumes the people are doing the work. In an AI-native delivery model, the people aren’t doing the work, the agents are. A senior engineer in week four is reviewing twice as much output as they did the week before because the testing agent is now ten percent better at its job. The bottleneck has moved. So has the unit of accountability.
Counting people gives you a wrong-shaped answer. You either over-hire (because you sized to the worst week) or you under-hire (because you sized to the best week), and either way you misallocate. The accountability gets blurry too: the named person on the team plan isn’t the one producing the output. The agent is. The team plan that doesn’t name the agent and name its navigator is a team plan that cannot be defended to a board, a regulator, or an auditor.
The question that does
The question I now ask first is: what capability mix does this workflow need? Not “how many engineers” but “what is the team, agents and humans, across the next four phases, and where does each agent need a named human navigating it?”
In the retail transformation program, the capability map looked something like this.
Discovery and inventory. Small human team, no agents. Senior architects working from interviews and the existing landscape.
Refactor planning. Human architects + an optimisation agent that re-ranks applications by complexity and dependency. The agent drives the ranking; an architect navigates it, accepting, overriding, recording the why.
Build. Human engineers + coding agent + testing agent. The coding agent writes the code; the testing agent generates and runs the tests; named engineers navigate both, reviewing outputs, defining acceptance criteria, signing off the gates.
Cutover and stabilisation. Human-heavy, agents in advisory mode. Named accountability sits with the cutover lead; agents surface options, humans decide.
Run. Humans for accountability, agents for monitoring and ticket triage. Every alert the agent escalates has a named human who decides whether the escalation was correct.
Each capability has a sizing logic of its own. The coding agent isn’t sized by FTE, it’s sized by token budget, throughput, and the ratio of agent output to navigator capacity. The reviewer capability is sized by the agent’s output rate, not by application count. The agent operator capability is sized by how many agents need active navigation at once.
The team, agents on the roster, humans as navigators
A capability-mix plan surfaces roles for both kinds of teammate, and that surfaces roles that didn’t exist on my org chart five years ago.
On the agent side, the team now includes the agents themselves as named members. The coding agent. The testing agent. The optimisation agent. They appear on the team plan with model name, configured behaviour, the workflows they own, and a named human navigator beside them. Treating agents as anonymous tooling, line items in a tech-stack diagram, is how accountability blurs and audit trails become unrecoverable. Naming them, on the team plan, with an accountable navigator each, is how the work becomes governable.
On the human side, the new roles are all navigation roles, humans whose job is to direct agents, not to execute work alongside them.
The agent operator. The full-time navigator. Tunes prompts, watches for drift, calibrates evaluation harnesses, decides when an agent is no longer fit for purpose. In a serious AI delivery program, this is a senior role, not a junior one.
The human-in-the-loop reviewer. Not a reviewer in the old sense (catching mistakes after the fact) but a reviewer in the new sense, a named gate the agent’s output passes through before the next step. The discipline is closer to clinical supervision than to QA.
The consumption analyst. A finance-fluent technologist who watches token cost, model selection, and runtime spend the way a traditional PM watches burn rate. New role, no off-the-shelf job description.
The governance lead. Sometimes a separate role, sometimes the delivery lead’s second hat. Owns the AI policy, the impact assessments, the audit trail, and the named ownership map of which human navigates which agent.
None of the four human roles are exotic. All of them already exist in production teams I have seen. What is new is that they appear together, with named accountability, on the team plan from day one, paired with the agents they navigate.
How to staff this without overhiring
The biggest mistake I see organisations make is adding navigator roles on top of the existing engineering team, instead of letting the team contract in the places where agents are now doing the work.
In the retail transformation program, the testing capability ended up about a third of the human headcount it would have needed in a traditional run. The testing agents took the volume. The human testers who remained were doing higher-judgment work, navigating the agents, defining edge cases, scenario design, exploratory review. They were not redundant. There were fewer of them, and the ones who stayed had shifted from drivers to navigators.
Agents drive the work. Humans navigate it. The team plan has to show both, and name which human navigates which agent.
The conversation with finance
A capability-mix plan needs a finance partner who can hold two cost models in their head at the same time, FTE for the human side, consumption for the agent side, with a defensible logic for why the trade-off works. CFOs who came up through the cloud era have already lived through “headcount versus cloud spend” in another form; this conversation lands easily with them. CFOs who still expect to size a program by people-months struggle more.
Worth flagging early. The team plan looks weird if your CFO is reading it like a 2018 staffing plan, and even weirder if the agents are line items but unnamed.
Where to start
If you are about to size a team for an AI-native program, start with a one-page capability map by phase. List agents and humans on the same chart. Mark which workflows each agent owns. Mark which human navigates which agent. Mark the seams, where an agent hands off to a human gate, where two agents pass work between them, where a human escalates back into the loop.
Then size each capability with its own logic. Some by people. Some by tokens. Some by gate throughput. Add them up at the bottom and you have a team plan that holds water, one where every agent has a named navigator, and every navigator knows what they’re navigating.
That, more than any other artefact, is what made the shift real for me. The first time I drew this map, the program stopped feeling like a normal delivery I was trying to graft AI onto, and started feeling like a new kind of delivery, one where agents are teammates with their own named roles, and humans are the navigators that keep them accountable.