AI team structure: the five functions every team working with AI agents has to cover
Structure the team around the work, not the tools: the five ORBIT functions, the coverage rule, and the three AI team structures that fail.

Every founder who has asked me about AI team structure has asked the wrong question first. They want to know who reports to whom once the agents arrive. What they need to know is which work the agents get, and which five human functions have to be covered around them. Get that order backwards and you end up with a new box on the org chart labelled "AI" and the same company underneath it.
This page is the structural answer. It uses the ORBIT Framework, the function map I run on every team I work with, and it gives you the names, the coverage rule, and the step-by-step for a team of five and a company of forty.
Why "AI team structure" is the wrong question until you sort the work
A team structure is an answer. The question it answers is "what work does this team do, and who does each piece?" AI changes the first half of that question before it touches the second. So a structure drawn before the work is sorted is a structure for a company that no longer exists.
The sort is the 3-Zone Co-Pilot: every workflow goes into Replace, Augment, or Refuse. Replace, the AI runs it end to end and a human defines the input and accepts the output. Augment, the AI prepares and a human decides. Refuse, the AI stays out, and that is written down with a name and a date on it.
Every time I have run that sort across a company of 20 to 200 people, the same thing falls out. The Replace column is not spread evenly. It concentrates in the roles whose week is routing, summarising, status-keeping and chasing. That is the narrow middle of the org chart, and it is the argument of the Hourglass Collapse: AI automates the coordination layer faster than the wide top or the wide bottom, and the shape goes from hourglass to lens.
So the structure question has half-answered itself. The coordination roles that sorted into Replace do not reappear on the far side. What replaces them is not a thinner layer. It is a function map.
Function maps beat org charts once agents do the routing
An org chart answers "who reports to whom." That was load-bearing when human bandwidth was the bottleneck and information moved by hand, one layer at a time. Once agents carry the information, the reporting line stops describing how work moves. A function map answers a different question: what does this team have to do for the system to work, and who is doing each thing? A title tells you who was hired. A function tells you who catches the silent failure on a Tuesday. Only one of those can be checked.
That is ORBIT at its core. ORBIT is the five functions by their initials, O, R, B, I, T: Outcome Orchestrator, Operator, Innovator/Builder, AI Champion, Stakeholder Liaison/Translator. Always human, never delegated to an agent. Functions, not job titles. One person can hold two. In a four-person pod, someone must.
The five functions of an AI team structure
For each one: the job, the skill that carries it, and where it sits at five people and at forty.
O: Outcome Orchestrator
Owns outcomes and direction. Routes work between humans and AI. Decides who decides.
The load-bearing skill is decision-rights design: being explicit about who decides, who is consulted, and who is informed, for every workflow the agents touch. Underneath it sit outcome articulation, writing a target that survives the gaming question, and the routing call itself: this work is augmented, this work is not.
In a five-person pod, this is usually the pod lead, carrying one other function alongside it. In a forty-person company, the founder or COO holds the org-level version, and each pod has its own. The misread I see most is treating this as project management. It is closer to a CEO function compressed into a single team.
R: Operator
Runs and monitors the AI-augmented systems day to day. Catches the failures that do not announce themselves.
The load-bearing skill is silent-failure detection: spotting when AI output looks right but is subtly wrong. Around it sit system-state literacy, knowing when a system is performing differently from its baseline, and observability craft, installing the dashboards and probes that make drift visible before a customer does.
In a five-person pod, this is often the ops-minded person, and it is a named responsibility, not "shared." In a forty-person company, an Operator sits inside each pod that runs live agent workflows, so "who noticed?" always has one answer. The failure signature: workflows that worked in one quarter are quietly broken by the next.
B: Innovator/Builder
Designs and improves the workflows. Builds the scaffolding: prompts, evaluation harnesses, integrations. Judges whether AI output is good, not just complete.
The load-bearing skill is output judgment. This is the point the teams I audit get wrong most often: they treat the Builder as pure infrastructure and put the quality call somewhere else, or nowhere. It belongs here. Alongside it: workflow design, seeing the end-to-end flow rather than the AI step, and build-versus-buy reasoning.
In a five-person pod, this is the person who saves and versions the prompts everyone else uses. In a forty-person company, the Builder is the one function that gets staffed without anyone deciding to, because engineering owns it by default. The healthy signal is compounding: the pod's outputs get measurably better over weeks, not just faster.
I: AI Champion
Embedded, peer-level culture carrier. Coaches peers one to one and in small groups. Works the identity refusal directly, not through a program.
The load-bearing skill is influence without authority. The Champion usually cannot command anyone. Alongside it: psychological safety reading, telling silence from disengagement from deference, and identity-conversation craft, naming a refusal pattern to a person without triggering more of it.
In a five-person pod, this is the person peers already go to when a tool does something strange. In a forty-person company, there is one per pod, and the org-level Orchestrator cannot also be every pod's Champion. More below, because it is the function I see given to the wrong person most often.
T: Stakeholder Liaison/Translator
Connects the pod to users, stakeholders and data. Turns signal into direction in both directions: what customers say becomes pod priorities, and what the pod ships becomes something a stakeholder can read.
The load-bearing skill is customer-voice preservation: verbatim, not paraphrased. A paraphrased complaint is already half a decision. Alongside it: signal-versus-noise discrimination, telling durable user signal from one-off feedback, and two-direction fluency, speaking engineer and stakeholder in the same meeting.
In a five-person pod, this is a customer success lead, a user researcher, or the founder's chief of staff, explicit even when part-time. In a forty-person company, it is the function my audits most often find left implicit, because everyone assumes the Orchestrator has it covered. The Orchestrator does not.
The AI champion role, and why it is not the loudest person
When I ask a founder to name the AI champion, they name the person who talks about AI the most. That is usually the wrong choice.
The Champion is a peer-level function. Its job is to carry the change narrative inside the team and to work the identity refusal, the quiet "this isn't what I do" resistance that never shows up as open disagreement. That work runs on trust, not enthusiasm. The person peers defer to is rarely the person with the most opinions in the sync.
The test is empirical. Who do people go to, unprompted, when a tool does something they did not expect? Who gets asked "how did you get it to do that?" in the channel? That person is the Champion whether or not you have told them.
Two signals the function is present: identity refusal gets named to people, not just about them, and the pod has visible new norms and defaults, not only new tools. One signal it is missing: a handful of people account for nearly all the AI usage and everyone else is compliant on paper. That is a stack with no users, and it shows up late.
How to structure a team around AI agents, step by step
The sequence is People before Process before Tool. If your rollout started with a licence, you ran it in reverse, and that is why it produced a licence and a dashboard and nothing else.
1. Sort the workflows with Replace / Augment / Refuse
Take your top ten workflows. For each one: what is the human's actual contribution, what breaks if it goes wrong, and which named person signed the answer? Coordination and routine generation go to Replace. Judgment under ambiguity goes to Augment. Asymmetric downside goes to Refuse. An unsigned zone drifts back to the default within a quarter.
2. Assign the five functions by name
Names down the left, five columns across: O, R, B, I, T. Mark what each person actually does, not what their title says. Use the function word first. "Sarah is the Operator for the lead-routing loop" survives; "Sarah is head of ops" tells you nothing about who catches the silent failure.
3. Check the coverage rule
A pod is healthy when all five functions are present at the pod's current maturity. It is at risk when any function is unowned, when two functions collapse into one person and compress decision rights, when a function is nominally owned but the signals are not there, or when three or more functions are doubled up across fewer than three people.
Doubling and collapse are not the same thing. Holding two functions by decision, named, with the decision rights written down, is normal in a pod under six people. Collapse is when nobody decided it, the second function has no signals, and one calendar now owns two sets of calls.
The one signal per function, so the ten-minute version fits on a screen:
- Orchestrator: the pod can state its headline objective in one sentence.
- Operator: AI systems have a named runner, and would-be silent failures get caught.
- Builder: prompts are saved, versioned and getting better, not just more numerous.
- Champion: peers ask them for help unprompted.
- Translator: user voice appears verbatim in the pod's artefacts.
Then look for the anti-patterns. Functions named by job title, so the title's baggage distorts the function. A single person carrying four functions in a four-person team, so decision velocity collapses to that person's calendar. The Translator left implicit, so the gap between what the pod builds and what users need goes undetected. And a Builder rewarded for novelty over compounding, so the pod ships impressive one-offs and its capability never stacks.
4. Keep an apprenticeship path
The Replace column is where juniors used to learn. Automate all of it and you have removed the mechanism that manufactures your seniors, which is the Apprenticeship Crisis. So staff Augment work juniors-first, deliberately, and make a named senior own their correction. Review their reasoning, not their artifact. A lens-shaped org needs more senior judgment than the hourglass did, not less, and it cannot buy that judgment forever.
Three structures that fail
A central AI team that owns everything
The most natural first move and the most reliable way to build a stack nobody uses. A central team ends up heavy on Builder, light on everything else. It ships agents into pods that did not ask for them, with no Champion inside those pods and no Translator carrying signal back. The pod treats the output as someone else's project, which, structurally, it is.
The centre has a job: standards, shared scaffolding and the org-level Orchestrator function. The five pod-level functions live in the pods.
AI as an IT project
If the AI budget sits in the IT line, the company has already decided this is a tool problem. BCG's 10-20-70 rule puts the weight the other way: 10% algorithms, 20% technology and data, 70% people and processes. Its October 2024 research found roughly 74% of companies struggle to achieve and scale value from AI. An IT project funds the 30% and hopes the 70% happens on its own. It does not. The Champion and the Translator are the 70%, and neither of them is a procurement decision.
Copiloting the middle layer
"Let's augment the PMs." It sounds prudent. What it does is preserve the exact layer the sort would have moved into Replace, and hand you a faster version of the company you already had. That is the copilot anti-pattern in its purest form. The manager whose week was routing and summarising does not need a copilot. The work needs a loop, and the person needs a function on the map or a different role.
None of these are technology failures. Each is a structure drawn before the work was sorted. If you want the sort and the map run on your own org, with a defined exit once your team can run it without me, that is what the Fractional CAIO engagement is built for. The rest of the essays on AI-augmented teams cover the surrounding structure.
The binary
Two versions of the next twelve months.
In the first, you add an AI team to the org chart. It builds well. The rest of the company keeps its shape, its middle layer, and its personal ChatGPT accounts. A year on you have an impressive stack, a usage graph that peaked in month two, and a pipeline of juniors that never opened.
In the second, you spend a week sorting the work and thirty minutes naming five functions. One of the columns comes up empty. You fix that one. Nothing in this version needs a better model than the one you already have.
One of those is your company this year. The org chart is changing either way... the question is whether you drew it.
FAQ
What is the best AI team structure?
A function map, not a reporting structure. Every team working with AI agents needs five human functions covered: Outcome Orchestrator, Operator, Innovator/Builder, AI Champion, and Stakeholder Liaison/Translator. That is the ORBIT Framework. Team size changes how many functions each person holds, not which functions exist. The best structure is the one where all five have a name attached and none is doubled up past the coverage rule.
How do you structure a team around AI agents?
Sort the work first, then map the people. Put every workflow into Replace, Augment, or Refuse using the 3-Zone Co-Pilot. Then assign the five ORBIT functions by name, check the coverage rule, and keep a deliberate apprenticeship path on the Augment work so juniors still earn judgment. People before Process before Tool. The tool decision comes last, and by then it is usually obvious.
What is an AI champion's role?
The AI Champion is the embedded, peer-level culture carrier in a team. They coach peers on AI use one to one and in small groups, name identity refusal patterns to the people holding them, and carry the change narrative without any authority to command. The load-bearing skill is influence without authority. The test for who holds it is empirical: who do peers already go to, unprompted, when a tool does something unexpected?
Do we need a central AI team or embedded roles?
Embedded, with a thin centre. The five functions live at pod level because that is where the work, the users, and the refusal are. A central group owns standards, shared scaffolding and the org-level Orchestrator role. A central team that also owns the Builder, Champion and Translator functions for every pod ends up shipping a stack nobody uses, because the pods treat it as someone else's project.
How big should an AI pod be?
Big enough to cover five functions without collapsing them. In a two-to-three person pod each person holds two or three. At four to six, each function can have its own owner, which is the size where coverage is most legible. Beyond roughly ten to twelve people, split into two pods with full coverage each rather than adding a sixth or seventh person to one. Adding rebuilds the coordination overhead the pod was meant to remove.
Read this next: The ORBIT Framework... the full function map, the pod-sizing rules by team type, and the 30-minute self-audit.
Sources
BCG: the 10-20-70 rule (10% algorithms / 20% technology and data / 70% people and processes). See From Potential to Profit: Closing the AI Impact Gap (2025): https://www.bcg.com/publications/2025/closing-the-ai-impact-gap and The Leader's Guide to Transforming with AI: https://www.bcg.com/featured-insights/the-leaders-guide-to-transforming-with-ai
BCG: Where's the Value in AI? (October 2024). Source of the finding that roughly 74% of companies struggle to achieve and scale value from AI; restated in the 2025 publication above. https://www.bcg.com/publications/2024/wheres-the-value-in-ai
Frameworks referenced are my own: the ORBIT Framework, the Hourglass Collapse, the 3-Zone Co-Pilot (Replace / Augment / Refuse), and the Apprenticeship Crisis.
The five functions and the coverage rule, one per issue, in your inbox.
The frameworks behind this page go out to the list, one per issue.
Or if you already know this is your situation: book a 30-minute scoping call