Most companies that have started running agents are running them under the CTO.
The reasoning makes sense on the surface. Agents are software. Software lives under the CTO. The agent sprawl problem looks like an IT problem. So the CTO inherits it.
I think that is wrong. Not slightly off. Structurally wrong in a way that explains why so many agent programs look productive and deliver little.
The argument for the COO is not organizational politics. It follows directly from where agents actually create value, and that argument is causal. Operations is where agents pay off. The COO owns operations. Therefore the COO owns the agent operating model.
Where agents actually create value
Agents create value by carrying work that previously required a human to initiate, coordinate, or execute. The categories where that value is largest are not in the IT department. They are in the daily operational layer: briefings, performance tracking, pipeline hygiene, client communications, project status, lead response, call center coaching, inbox triage.
At Sneeze It, Radar compiles the morning briefing. Dash monitors ad performance across forty accounts. Tally pushes scorecard values to the org chart four times a day. Crystal monitors the project list in Accelo and flags late milestones. Pepper triages the inbox. Arin coaches the call center team. Dirk runs the sales pipeline and flags stale deals. Nick drafts cold prospecting emails to qualified leads.
None of those seats live inside IT. They live inside operations. Every one of them is replacing or augmenting work that was previously done by a human in an operational role, not a technical one.
That is not a coincidence. It is the nature of what agents are good at. They are good at high-frequency, rule-governed, information-heavy work that repeats daily. That is a description of operations. It is not a description of software engineering.
Why the CTO ownership model fails
When agents sit under the CTO, the questions that get asked about them are technical questions. Is the model performing well? What is the latency? How are the tokens being used? Is the infrastructure reliable?
Those are real questions. They are not the right questions.
The right questions are operational: Is the agent doing the work it is supposed to do? Is the output meeting the standard? Is the handoff between this agent and the next seat clean? When the agent fails, what is the escalation path and who owns the fix?
A CTO who inherits the agent fleet will optimize for uptime and cost. A COO who owns the agent fleet will optimize for output quality, process fit, and business outcome. Those are not the same optimization target.
Deloitte's 2026 State of AI in the Enterprise study, which surveyed 3,235 respondents, found that only 21% of organizations have a mature governance model for agentic AI. The common failure mode they identified is that senior leadership delegates agent governance to technical teams rather than shaping it directly. The result: agents that run well technically and deliver little operationally.
That 79% gap is not a capability gap. It is an ownership gap. Technical teams optimize for what technical teams are trained to care about. The business outcomes live somewhere else.
The COO is already managing the equivalent problem
Operations management is, at its core, the discipline of getting work done reliably through a mix of people, processes, and systems. The COO has been solving versions of this problem every year. What changes when agents enter the picture is not the nature of the problem. What changes is that one of the execution layers now scales instantly and never has a bad week.
The COO already knows how to:
Design a process that produces consistent output across variable inputs. Identify the handoff points where quality breaks down. Decide what gets measured and who is accountable for the number. Build an escalation path so that when something goes wrong, it surfaces fast and lands on the right person. Retire a seat that is not producing.
Every one of those skills transfers directly to agent fleet management. The COO does not need to learn agent fleet management from scratch. They need to apply the operational discipline they already have to a new class of worker.
The CTO needs to learn operational design from scratch. That is a harder ask.
The process redesign problem requires operational authority
Accenture's framing on agentic AI is direct: reinvent the process first, then infuse the agents. Their version of the warning is "don't make inefficiency run efficiently."
That warning has teeth. If you hand an inefficient process to an agent, the agent will execute it perfectly and the inefficiency will scale. The agent will not notice that the process is broken. The agent will not push back. The agent will just run the broken process faster.
Fixing the process before the agent takes it over requires someone with operational authority: authority to say this step is wasteful, authority to redesign the handoff, authority to decide that two seats can be merged or that a step should be eliminated entirely. That authority lives with the COO, not the CTO.
At Sneeze It, before I brought Radar online, I redesigned the morning briefing process. The old version required pulling data from five sources manually, formatting it, and deciding what to include. The new version defined what the briefing should contain, in what order, at what threshold, with what escalation logic. That design work had to happen before the agent ran it. And it required someone who understood the operations deeply enough to know what the briefing was actually for.
That is COO work. It is not architecture work.
The hybrid chart requires operational judgment to build
The organizing principle of the Sneeze It fleet is one seat, one owner. Every seat on the org chart, human or agent, has a clear role, a clear metric, and a clear escalation path. Humans and agents sit on the same scorecard. The Monday review walks both rows the same way.
Building that chart requires knowing which work belongs to which seat, which seats can be held by agents, which require human judgment, and how to draw the handoff line between them. That is an organizational design problem. It is not a software architecture problem.
The COO is already building org charts. Adding agents to the chart is an extension of a skill the COO already has, applied to a new class of worker.
Bogdan, our COO, does not manage Radar, Dash, or Tally the way a CTO manages infrastructure. He manages them the way an operations lead manages any seat: he looks at the output, evaluates whether it is meeting the standard, and decides what to change when it is not. The agent seats have the same accountability structure as the human seats because they are on the same chart.
That design decision, putting agents on the operational org chart rather than the IT asset register, is what makes the agents legible and accountable. It is not a technical decision. It is an organizational one.
The guardrail and handoff problem is operational
The other place the CTO ownership model breaks down is guardrails.
Guardrails for agents are mostly not technical. They are operational. When does the agent escalate? Who approves before the agent sends? What is out of scope? What does the agent do when it hits an exception it has not seen before?
Those questions require someone who understands the operational context: the client relationships, the approval flows, the exceptions that matter, the ones that do not. The CTO can enforce the technical guardrail. Only the COO can define the right operational boundary.
At Sneeze It, all Slack messages require David's approval before sending. Dirk drafts reactivation outreach; Pepper sends it after approval. Nick drafts cold emails to Gmail drafts; they go out manually. The agents do not have unilateral outbound authority. That is not a technical constraint. It is an operational policy, and it lives with the COO because the COO understands the reputational and relationship stakes.
The MIT CISR maturity research shows that firms at Stage 4 AI maturity, where agents are embedded in workflows and delivering measurable business results, are led by a united top leadership team that includes the CEO, the chief strategy officer, and the head of HR alongside the technology function. What is notable is that the COO-equivalent is always in that group, because the value is showing up in operations, not in the technology layer.
What the COO who owns this gets right
The COO who takes ownership of the agent operating model does a few things the CTO typically does not.
They redesign the process before they put an agent on it. They put agents and humans on the same org chart with the same accountability structure. They treat the handoff between human and agent seats as an operational design problem, not a software integration problem. They build escalation paths that land on human judgment for the work that actually requires it. And they are willing to retire an agent seat that is not producing, the same way they would retire a human role that is not producing.
We retired Jeff, a data integrity agent, in April. The retirement came after a formal hearing, with evidence, with capabilities redistributed to other seats. That is not how a CTO retires an agent. That is how a COO retires a role. The discipline made the retirement honest and the redistribution clean.
The agents carry the operational work so the people on the team are free for the work that matters. That sentence is an operational statement. It requires an operational owner to make it true. The COO is that owner. Not because of org chart politics, but because the work lives in their domain and the skills required to govern it are the skills they already have.
See the live chart
The Sneeze It hybrid org chart, showing which seats are human and which are agents, is queryable from the OTP MCP.
In Claude Desktop or Cursor or any MCP client, add this block:
"otp": {
"command": "npx",
"args": ["-y", "@orgtp/mcp-server"]
}
Restart the client. Then ask: "Use OTP to show me the Sneeze It org chart and tell me which operational seats are agent-held and what each one is accountable for."
The chart is the argument made concrete.
Series: AI COO. Post 6 of an in-progress series.