Article · Vision & Strategy
The AI operating model: who owns what when agents do the work
An AI operating model isn’t the same model with a new tool bolted on top. When agents run part of the work, four things change at the root: who owns what, how decisions get made and escalated, where controls live, and what people are organized around. This article deals with the organizational version of that change (people, responsibilities and governance), not the technical craft of encoding it, which is a separate job.
A warning up front, so two things that sound alike don’t blur: here I’m talking about the operating model as organizational design. The idea of turning that model into definitions an agent runs directly I develop in the operating model as code. They’re complementary layers: one decides who answers for what, the other makes what’s decided executable. This piece stays on the first.
The problem the traditional model doesn’t solve
In a classic organization, work is split by tasks and departments. A person does their part, hands it to the next, and accountability for the whole stays diffuse: if an order runs late, the blame spreads across sales, warehouse and billing, and no one answers for the entire process.
That task-based split worked while the tasks were done by people coordinating through habit and email. The moment an agent runs a process end to end, diffuse accountability stops being tolerable. The agent doesn’t “know” who to ask when something doesn’t fit. It needs explicit rules and an owner to set them. The ambiguity the organization tolerated becomes an operational failure.
Who owns what
The central change in an AI operating model is separating four ownerships that used to live tangled together. In the deployments I support, I force a named owner for each one, and they’re different people or functions.
| Ownership | What it covers | Who usually owns it |
|---|---|---|
| Process | The business rules, the exceptions, the line between agent and person | A process owner, on the business side |
| Result | That the process does its job and hits its metrics | The function head (finance, operations, service) |
| System | That the agents work, stay maintained and pass their evaluations | The technical operator, in-house or contracted |
| Data | What can be read and written, with what permissions and under what regulation | The data owner and the compliance lead |
The costliest confusion I see is putting process and system on the same person. They’re opposite jobs: the process owner knows the business and decides the rules, and the technical operator maintains the machine that runs them. When one person carries both, either the business gets neglected or the system does, and usually both.
Process ownership is the one most companies forget to assign, because it didn’t exist before: the process lived split apart. That new figure, the owner of a process now run by agents, is one of the roles that gains weight in this change, and I describe it in detail in AI agents and the future of work.
How decisions get made and escalated
With agents in the operation, decisions sort into three planes, and it’s worth not mixing them.
Business decision. What the agent can do alone, what it escalates to a person, what’s off-limits. The process owner makes it. It isn’t a technical decision: it’s where you set the line on the risk you accept, and one of the important ones.
Exception decision. The specific case the agent couldn’t resolve and escalated. The person designated for that class of case resolves it, with the context the system prepares. Each exception is also a signal: if one type of case escalates often, a rule is missing that someone has to decide.
Scaling decision. When a process that works in one team extends to others, or when human control is loosened because the data shows reliability. Management makes this one, with operational evidence in front of them, not on intuition.
Separating these three planes avoids the usual mistake: a business problem treated as a technical fault, or a risk decision made by default by whoever maintains the system because no one else took it on.
Where controls live
In the traditional model, control is a manager’s supervision and after-the-fact review. With agents, control has to sit in the process design itself, not in constant human watching, because an agent can repeat a mistake at a scale no person reaches.
Controls live in three places: in permissions (what each agent can read and write, what’s off-limits), in evaluations (quality measurement before real work and on an ongoing basis) and in traces (the record of every action, so you can audit what happened and why). None is optional in a process that touches money or customers. The full governance frame, with who answers for each control, I cover in AI agent governance.
What matters for the operating model is that these controls create new supervision work that has to be assigned to someone. You don’t supervise the way you supervised a human team. You review samples, read traces and adjust thresholds. It’s a function, not a gesture of goodwill.
The org chart gets redrawn around processes
The structural consequence is the deepest and the slowest. When work is organized by tasks split across departments, the org chart mirrors that division. When part of the work is run by agents end to end, the natural unit stops being the task and becomes the whole process, with its owner, its result and its controls.
That doesn’t mean dissolving departments overnight. It means process owners appear who cut across the old departmental borders, because a process like order-to-cash runs through sales, warehouse and finance. The organization starts to have two axes: the usual functional one and the one of processes run by agents. Managing that double structure without the two treading on each other is part of the redesign.
This redesign is what separates a company that merely uses AI from one that has changed how it operates. The full frame is in the AI-first organization. And the concrete terrain where these processes deploy first I cover in AI agents in operations. To place it all inside adoption in general, the entry point is the pillar article on AI agents for business.
Frequently Asked Questions
What is an AI operating model?
It’s the design of how the organization works when agents run part of the work: who owns the process, the result, the system and the data; how decisions get made and escalated; where controls live; and what people are organized around. It’s organizational design, not a tool.
How does it differ from the operating model as code?
This covers the organizational layer: people, responsibilities and governance. The operating model as code covers turning those rules and exceptions into definitions an agent runs directly. One decides who answers for what, the other makes what’s decided executable. They complement each other.
Who should own a process run by agents?
Someone on the business side who understands the rules and the risk, not the technical team that maintains the system. Merging both ownerships in one person is the costliest mistake: they’re opposite jobs and one gets neglected. The process owner sets the rules. The technical operator runs and maintains them.
Do you have to reorganize the whole company at once?
No, and doing so would be reckless. The org chart gets redrawn process by process: an owner appears for the first process run by agents, then for the next, and the process-based structure coexists with the functional one for years. The change is measured in years because it advances on evidence, not by decree.