The AI Operating Model: Redesigning the Org Chart Around Agents
There's a pattern I keep encountering as organisations move from AI experiments to AI in production: the technology works, the pilots succeed, and yet the operating model never changes. Agents get added to teams the way a new SaaS tool gets added — as something people use on the side of their existing jobs. The org chart stays exactly as it was. And then everyone wonders why the productivity gains are real but modest, rather than the step-change the pilots seemed to promise.
I've written before about the 20x company — the emerging model where small teams architect their entire operation around AI agents as virtual employees. That post was about what's possible at the frontier. This one is about the more common, more pressing question for established organisations: if agents can now do real work, what does the operating model actually need to become? Because the answer is not "the same structure, plus some agents." It's a genuine redesign of how work is divided, who is accountable for what, and what a team is even for.
The Bolt-On Trap
The default approach to AI adoption is additive. You keep the existing roles, the existing reporting lines, and the existing process, and you give people AI tools to make their current work faster. This is comfortable because it changes nothing structural, and it delivers something — usually a 10–20% efficiency improvement in the tasks where the tool is a good fit.
But additive adoption hits a ceiling quickly, for a structural reason. If a process was designed around the constraint that humans do every step, then speeding up individual steps doesn't change the shape of the process. The handoffs, the queues, the review cycles, the coordination overhead — all of that remains. You've made the runners faster without redrawing the track. As I noted in the AI readiness piece, the organisations capturing the most value are the ones asking "if AI can do this, what should we do differently?" rather than "how do we do the same thing faster?" The bolt-on trap is answering the second question when the first one is where the value lives.
From Headcount to Capacity
The most consequential shift is conceptual: you stop planning in units of headcount and start planning in units of capacity. In a traditional operating model, the way you get more output from a function is to hire more people into it. Capacity and headcount are effectively the same variable.
Once agents can perform meaningful chunks of work, that link breaks. A function's capacity becomes a combination of its people and its agents, and those two scale on completely different curves. Adding agent capacity is fast, cheap, and reversible; adding headcount is slow, expensive, and sticky. This changes resourcing decisions at a fundamental level. The question stops being "how many people does this team need?" and becomes "what's the right mix of human judgment and agent capacity for the work this team owns?" Organisations that keep planning purely in headcount will systematically over-hire for execution and under-invest in the orchestration and oversight that agent capacity actually requires.
Roles That Change Shape
When agents absorb execution work, the human roles around them don't disappear — they change shape, and not uniformly.
Managers become orchestrators. The traditional manager coordinates people: assigning work, unblocking, reviewing, developing. In an agent-heavy team, a growing share of that coordination is directed at agents and at the interface between agents and people — deciding what work to delegate to agents, defining the guardrails, and designing the points at which humans inspect the output. This is a real skill, and it's not the same as people management. Some of the best individual contributors will be better orchestrators than some of the best people managers.
Individual contributors become reviewers and editors. When an agent can produce a first draft of the analysis, the code, the campaign, or the contract, the human contributor's centre of gravity shifts from production to judgment — framing the problem well, then evaluating, correcting, and taking responsibility for the result. This is more demanding than it sounds. Reviewing agent output well requires more domain depth than producing it from scratch, not less, because you have to catch the plausible-but-wrong answer that an agent will produce confidently.
Specialists become standard-setters. The deep experts in a function increasingly express their expertise by encoding it — into the prompts, the evaluation criteria, the examples, and the escalation rules that govern how agents do the work. One expert's judgment, encoded well, can now shape thousands of agent actions. That's enormous leverage, but it relocates where the expertise lives, from the expert's individual output to the system the expert designs.
Accountability and Oversight by Design
The question I always come back to, and the one my readiness framework puts at the centre, is accountability: when an agent produces a bad output, who is responsible? An operating model built around agents has to answer this structurally, not case by case after something goes wrong.
The workable pattern is to make a named human accountable for each class of agent work, with the level of oversight scaled to the consequences of failure. Low-stakes, easily-reversible work can run with light, sampled review. High-stakes or hard-to-reverse work keeps a human in the approval loop. The principle I find most useful is the one from agentic systems generally — start with agents that recommend and humans that decide, then selectively expand agent autonomy only in the areas where the failure modes are well understood and the cost of a mistake is low. The mistake is treating oversight as a single global setting rather than something you design differently for each kind of work an agent does.
Team Topology: Smaller, Flatter, More Leveraged
Put the role changes and the capacity shift together and the natural team shape changes too. Teams get smaller, because a pod of a few people directing agent capacity can own a scope that previously needed a much larger group. They get flatter, because when execution is delegated to agents, the layers of management that existed mainly to coordinate execution have less to coordinate. And they get more cross-functional, because when the cost of producing work drops, the binding constraint becomes judgment that spans disciplines — the kind of integrated, cross-functional capability I've argued is the real work of transformation.
This doesn't mean a wave of restructuring announced on a slide. The organisations doing this well are evolving topology function by function, as agent capability in each area matures — not redrawing the whole chart at once. The destination, though, is consistent: fewer, smaller, more capable teams, each owning more outcome and carrying more leverage per person.
Where to Start
You don't redesign an operating model in one move, and you shouldn't try. A few questions worth working through before you do:
- Which functions are still planning purely in headcount, when they could be planning in capacity?
- Where are you bolting agents onto an unchanged process, rather than redesigning the process around what agents can now do?
- For each class of agent work, who is the named human accountable for it — and is the level of oversight matched to the actual cost of failure?
- Which of your managers are natural orchestrators, and which of your specialists could have far more impact by encoding their judgment than by applying it case by case?
- Where would a smaller, flatter, more cross-functional team capture more value than the structure you have today?
If the answers reveal that your structure hasn't moved while your tooling has, that's not a failure — it's the most common place to be right now, and it's a clear roadmap for where the next round of value is. The technology has already changed what's possible. The operating model is what turns that possibility into results.
If you're working through what an agent-centred operating model looks like for your organisation — or trying to move past marginal, bolt-on gains — I'm happy to share frameworks from what I've seen work.