ORBIT: The Five Functions Every AI-Augmented Team Needs (And Why Most Are Missing Two)

Every AI-augmented team needs five functions covered to actually work. Most companies are running with two or three. They are wondering why their pilots are not converting, why their agent stacks fail in production, and why the ROI numbers in the McKinsey deck never seem to materialize in their own quarterly review.

The answer is almost never the model. It is rarely the prompt. It is almost always the org-design layer underneath the technology.

This essay is the full walkthrough of ORBIT — the framework I use to map the five human functions every AI-augmented team must cover. ORBIT is not a methodology. It is not a maturity model. It is a function map: a way to look at any team, of any size, in any industry, and see which of the five functions are owned, which are missing, and which are being done by the wrong person.

If you have read the companion essay on The Hourglass Collapse, this is the structural follow-up. The Hourglass Collapse explains why the old org chart is dissolving. ORBIT explains the shape of what replaces it.

Why Function Maps Beat Org Charts in the Agentic Era

Traditional org charts answer the question "who reports to whom." That question was load-bearing in an industrial-age organization where coordination was the bottleneck. In an AI-augmented organization, coordination is no longer the bottleneck. Orchestration is.

A function map answers a different question: "what does the team have to do for the system to work, and who is doing each thing?" Titles can lie. Reporting lines can lie. The functions cannot.

Here is the most common pattern I see when I run an ORBIT audit on a team that has been investing in AI for 12+ months and is frustrated with results: every team has someone Building. Most have someone Running. Almost no one has explicitly named who is Translating. Almost no one is treating Orchestrate as a leadership function at all.

That is where the gaps are. That is where the performance delta lives.

The Five Functions of ORBIT

ORBIT stands for Orchestrate, Run, Build, Influence, Translate. Each is a distinct human function. Each must be covered. None of them can be delegated to an agent.

O — Orchestrate

What it is: Direct the agents toward an outcome. Decide what the AI is pointed at and why.

Orchestration is the leadership function of an AI-augmented team. The Orchestrator owns the answer to two questions that nothing else in the system can answer: what outcome are we producing? and which agents are doing what to produce it?

Most companies treat Orchestration as a project-management function. That is the most expensive misclassification in the framework. Orchestration is closer to a CEO function compressed into the unit of a single team. The Orchestrator is making real-time decisions about which work goes to which agent, which workflows to chain, where humans need to insert themselves, and when to redesign the flow because the agents are reliable enough to take over more of it.

Common signs Orchestration is missing: the team has a backlog of agents that work in isolation but never combine into a workflow; nobody can articulate the pod's outcome in a single sentence; "automation" decisions are made by whoever is loudest, not by whoever owns the outcome.

Who tends to do this well: M-shaped supervisors, in McKinsey's vocabulary — generalists with breadth across multiple specialties who can hold multiple agent workflows in their head at once. Former senior product managers, agency-trained creative directors, and ex-consultants tend to fit naturally.

R — Run

What it is: Manage the workflows the agents are inside. Operations does not disappear. It gets denser.

There is a widespread belief that AI replaces operations. It does not. It compresses it. The number of workflows running in parallel inside an AI-augmented team is dramatically higher than the number running in a traditional team. Each workflow has more handoffs, more agent-to-agent dependencies, more edge cases, and more places where something can fail silently.

The Runner is the person who keeps the system actually running. They monitor the queues. They notice when an agent's output quality drifts. They catch the silent failures — the ones where every individual agent appears to be working but the end-to-end output is wrong. They are the equivalent of a senior SRE for an agent network.

Common signs Run is missing: agents fail and nobody notices for days; quality degrades gradually and the team blames the model; workflows that worked in February are quietly broken by April and nobody can say when they broke.

Who tends to do this well: former operations managers, technical leads with strong systems instincts, and people who came from QA or production engineering. The Runner is your team's daily quality conscience.

B — Build

What it is: Create the systems, tools, and prompts the agents operate within. Infrastructure is still infrastructure.

The Build function is the only one most companies have already covered, often by accident. It is the function the engineering team naturally owns. The Builder writes the prompts, designs the agent harnesses, integrates the tools, builds the connectors, and engineers the data pipelines that feed the agents.

Two warnings about Build. First, it is the most overrepresented function in companies that are early in their AI journey. Most "AI teams" at the 12-month mark are 80% Build and 20% everything-else. That ratio has to invert as the system matures. Second, the most common failure mode is treating Build as a one-time project. The agents you ship in Q1 will need rebuilding by Q3. Build is a continuous function, not a project deliverable.

Common signs Build is overweight (yes, that is possible): the team has 40 agents and 4 active workflows; technical debt in the prompt layer is invisible because nobody owns it; everyone on the team can ship an agent but nobody can explain which agents are still being used.

Who tends to do this well: agentic engineers, prompt engineers, integration specialists, and developers who are comfortable working at the boundary between human language and structured systems.

I — Influence

What it is: Drive adoption and culture change. The best agent stack in the world fails without humans willing to work with it.

This is the function organizations consistently underweight, and the function that BCG's research most directly maps to its "70% of AI value comes from workforce change, not technology" finding. The Influencer is the person who closes the gap between the agent stack existing and the agent stack being used.

Influence work looks like: training peers on agent workflows, designing the rituals that make agent use a default rather than a special case, identifying internal AI Champions and giving them air cover, surfacing resistance early and resolving it without forcing it underground, and translating wins into stories the rest of the organization can repeat.

Influence is also the function that determines whether the 29% of employees using unsanctioned AI tools (McKinsey, 2026) get pulled into the official workflow or stay in the shadows. That decision alone determines whether the company has visibility into what AI is actually doing inside it.

Common signs Influence is missing: tools get built and never get used; the team's pilot dashboard shows declining weekly active users; the same 3 people are responsible for 80% of the AI usage; resistance shows up as quiet sabotage rather than open disagreement.

Who tends to do this well: people with high relational capital across the organization, internal AI Champions, change managers, and L&D leaders who have run adoption programs before. Often the best Influencer in a team has no prior AI background — they have organizational fluency, which is the rarer asset.

T — Translate

What it is: Bridge agent outputs and human decisions. Someone has to interpret, validate, and act on what the agents produce.

Translate is the most-underowned function in ORBIT. Almost every team I audit has nobody explicitly responsible for it. They assume Orchestration covers it. It does not. Orchestration directs the agents. Translation interprets what comes back.

The Translator is the person who looks at an agent's output and says "this is correct but irrelevant," "this is plausible but wrong," "this is right and we should act on it now," or "this is right but we need to reframe it before it goes to the customer." That judgment cannot be delegated to a model. It depends on context, stakeholder dynamics, and tacit knowledge that does not fit in a prompt.

Translation also runs in the other direction. The Translator is who turns ambiguous human signals — a vague stakeholder request, an unstructured customer complaint, a half-formed strategic intent — into prompts and tasks the agents can actually act on. They are the inbound and outbound interpretation layer.

Common signs Translate is missing: agent output is impressive in isolation but never quite fits the actual problem; stakeholders bypass the AI workflow because "it doesn't get what we need"; valuable agent outputs sit unused because nobody decided what to do with them.

Who tends to do this well: user researchers, internal liaisons, senior consultants, customer success leads, and anyone whose career has trained them to hold context in two languages at once — technical and business, strategic and operational, internal and external.

How ORBIT Differs from Existing Frameworks

ORBIT is not the only framework in this space. Understanding what it is not helps clarify what it is.

• ORBIT is not RACI. RACI assigns accountability for tasks. ORBIT assigns coverage for functions. A team that has clean RACI on every task can still be missing two ORBIT functions and not know it.
• ORBIT is not an org chart. An org chart describes hierarchy. ORBIT describes function coverage independent of hierarchy. A 3-person pod and a 30-person department both need the same five functions covered.
• ORBIT is not a maturity model. Models like SIA Partners' AI maturity ladder describe stages of organizational capability. ORBIT is orthogonal — a team at Level 2 maturity needs the same five functions as a team at Level 5.
• ORBIT is not an AI competency model. Frameworks listing AI skills (prompt fluency, agentic thinking, output judgment) describe the competencies individuals need. ORBIT describes the structural functions a team needs covered. Both are useful; they answer different questions.

The closest cousin to ORBIT is McKinsey's Agentic Organization model, which identifies three human archetypes (M-shaped supervisors, T-shaped experts, AI-augmented frontline). ORBIT is the next-layer-down: it specifies the five functions those archetypes are actually doing inside any given team.

Team Sizing: How ORBIT Distributes Across Pods

ORBIT scales by combination, not by addition. The five functions are constant. What changes with team size is how many functions each person covers.

2-to-3 person pods

Each person covers two or three letters. Common combinations: O+I (Orchestrator/Influencer), R+B (Operator/Builder), and a third person covering T plus a partial overlap on whichever function is heaviest that week.

In my own pod-of-one inside BrainWrk, I am covering all five letters at varying intensities. Most of my time is in O and I. Some in B. R is partially automated and partially handled in fixed weekly windows. T is the function I have most consciously had to design discipline around, because it is the easiest to skip.

4-to-6 person pods

Each letter can be explicitly owned. The cleanest distribution is one person per function, with the Orchestrator also carrying part of Influence and the Translator also carrying part of Run. This is the size at which an ORBIT pod is most legible from the outside — every function has a name attached to it.

7-to-10 person pods

Five ORBIT roles plus one to two specialist functions. The most common specialists at this size: Data Steward (a Run-adjacent function focused on the data the agents consume and produce) and Integration Specialist (a Build-adjacent function focused on connecting agents to external systems).

10-12 people

At 10-to-12 people you are at the natural ceiling for a pod. Beyond that, ORBIT prescribes splitting into two pods, each with its own complete five-function coverage. Adding a sixth or seventh person to an existing pod, rather than splitting, is the most common scaling mistake I see. It rebuilds the coordination overhead the pod model was designed to eliminate.

How ORBIT Plays Out by Team Type

The five functions are universal. Their relative weight is not. Different team types lean into different parts of ORBIT.

Product teams

Heavy on Build and Translate. The Builder ships the agent stack and the integrations. The Translator is usually a user researcher or product manager who turns customer signals into prompts and validates that the agent outputs are actually solving the right problems. Often add: an Agentic Designer (specialist Build role) and a Data Steward (specialist Run role).

Service or client-facing teams

Heavy on Translate and Influence. The Translator owns the client-facing interpretation layer — taking ambiguous client requests and turning them into agent workflows, then translating agent outputs into client-ready deliverables. The Influencer manages the internal adoption that determines whether the team actually uses the workflows the Builder created. Often add: change support and, in regulated services, ethics and governance owners.

Operations teams

Heavy on Run and Build. The Runner monitors the workflows that are quietly the lifeblood of the business — fulfillment, billing, inventory, scheduling. The Builder creates and maintains the agent harnesses that touch operational data. Often add: Integration Specialists and governance leads where compliance is in scope.

Consulting and advisory teams

Heavy on Orchestrate, Build, and Translate. The Orchestrator runs the engagement; the Builder spins up the bespoke agent stack each engagement requires; the Translator interprets the agent outputs into client recommendations. Often add: AI Solutions Architects (a senior Build/Orchestrate hybrid) and Prompt Librarians (a Build specialist).

The Self-Audit: Run ORBIT Against Your Own Team

If you do nothing else with this essay, do this audit this week. It takes about 30 minutes and produces actionable output the next time you are deciding where to invest team capacity.

Step 1: List your team

Names down the left column. One row per person.

Step 2: Map each person to ORBIT letters

Five columns: O, R, B, I, T. For each person, mark the letters they actually do — not what their job title says they do, what they actually spend their time on. Use a simple scale: heavy (3), partial (1), none (blank).

Step 3: Sum each column

Each letter should have a column total of at least 3 — meaning equivalent of one full person doing the function, even if it is split across two or three people. If any column totals zero or one, that function is your bottleneck.

Step 4: Find the unowned function

The unowned function is your bottleneck regardless of what your strategy doc says. It is more important than your tooling decision. It is more important than your model selection. It is the next thing you should fix.

In my experience running this audit with founders and operators, the unowned function is Translate about 60% of the time, Influence about 25% of the time, and Orchestrate (yes, even Orchestrate) about 10% of the time. Build is rarely unowned. Run is occasionally unowned but usually overlaps with Build enough to mostly hold.

The Common Failure Modes

Three patterns show up repeatedly when ORBIT is incomplete. If any of these sound familiar, you have already diagnosed your missing function.

Failure 1: The "Builder team without an Orchestrator"

A team with strong Build, decent Run, no Orchestrate. The output is technically impressive — well-engineered agents, clean prompts, solid integrations — but the agents do not combine into a system that produces a clear business outcome. Engineering decisions are being made without an outcome owner. The team produces individual capabilities, never compounding them. This is the most common failure mode in technical organizations.

Failure 2: The "stack with no users"

A team with Build, Run, and even Orchestrate, but no Influence. The agents work. Nobody uses them. The team builds increasingly elaborate workflows for an audience that never showed up. This is the most expensive failure mode because it shows up late — usually in the second year of the AI investment, after the budget is committed.

Failure 3: The "agent output graveyard"

A team with Build, Run, and Influence, but no Translate. Agents produce outputs. Outputs get logged. Nothing happens with them. The team has invested in the production side of AI without investing in the interpretation side. The result is a stack that runs but does not act. This is the failure mode that is hardest to see, because the operational metrics all look fine.

The Close

ORBIT is a map, not an org chart. It is meant to be drawn on the back of a napkin in a meeting where someone has just asked "why are our AI investments not producing results?"

The answer is almost always one of the five letters. Once you can name it, you can fix it.

If you have not read the structural argument for why this framework matters now, the companion essay The Hourglass Collapse covers it: why the bottom layer of white-collar work is being absorbed by AI, why middle management is the next domino, and why pod-based teams (the unit ORBIT describes) are replacing the traditional pyramid.

The org chart is changing whether or not your organization participates in the change. The teams that map their function coverage early are the ones that come out of this restructure with their pods intact.

FAQ

Is ORBIT a published or peer-reviewed framework?

ORBIT is original framing developed inside BrainWrk and refined across founder and operator engagements. It synthesizes McKinsey's agentic-organization research, BCG's workforce-value findings, and patterns observed in production AI-augmented teams. It is published here for the first time in long form. The underlying claims about pod sizing and human-agent ratios reference McKinsey's 2026 research; the framework itself is mine.

Can a single person cover all five ORBIT functions?

Temporarily, yes. I do this inside BrainWrk as a pod of one. It is sustainable as long as the workload is contained and as long as the human covering all five letters explicitly designs time for the functions that are easiest to skip — usually Translate and Influence. Long term, even a solo operator should be looking for the first ORBIT function to delegate, and Translate is almost always the right one to delegate first.

Where does the Outcome Orchestrator role fit?

The Outcome Orchestrator is the canonical role label for someone whose primary ORBIT letter is O. It maps to McKinsey's "M-shaped supervisor" archetype. In a 4-6 person pod, the Outcome Orchestrator is typically also carrying part of Influence — they are the most natural culture-shaper because they own the outcome.

Should every team have a Fractional CAIO?

A Fractional CAIO is an organizational-level role, not a pod-level role. A single Fractional CAIO can cover the strategic Orchestrate function across multiple pods, set the AI governance and architecture standards, and provide air cover for the Influence function inside individual teams. For organizations between 20 and 200 employees who know AI matters but are not ready for a full-time CAIO, Fractional CAIO is the most cost-efficient way to put an experienced operator inside the strategy.

How long does it take to fix a missing ORBIT function?

Naming the gap takes 30 minutes. Reassigning ownership takes a week. Building the muscle to actually do the function well takes 8 to 12 weeks. The biggest mistake is treating "we assigned it" as "we covered it." Most missing ORBIT functions stay missing for months after they are formally assigned, because the assignee is still doing their old job and has no time to do the new one.

Sources

• McKinsey & Company. (2026). The Agentic Organization: Workforce, Governance, and Operating Models. Source for pod sizing data (2-5 humans supervising 50-100 agents) and the M-shaped / T-shaped / AI-augmented frontline archetypes.
• BCG. (2025). The 70/20/10 of AI Value: Why Workforce Change Is the Largest Lever. Source for the "70% of AI value comes from workforce change" finding.
• Microsoft. (2026, February). Cyber Pulse Report: Enterprise AI Agent Adoption. Source for 80% Fortune 500 active-agent figure and 29% unsanctioned-agent usage.
• Gartner. (2024). Future of Work Forecast: Management Layer Compression Through 2026.
• HatchWorks. (2025). GenDD: Generative Development Pod Sizing in Agent-Augmented Teams. Source for pod compression from 8-12 to 3-5 people.
• SIA Partners. (2024). AI Maturity Model: 50 Dimensions Across Governance, People, Process, Technology, Data.

---

If you want the structural framing this essay sits on top of, read The Hourglass Collapse. If you want this kind of org-design analysis in your inbox on Wednesdays, subscribe to the newsletter.