A support agent goes live on a Tuesday with write access to the CRM. By Thursday it has amended 400 customer records, roughly forty of them wrongly. The CAAO wants it switched off within the hour. The CTO wants it left running behind a feature flag while the team traces the fault, because switching it off breaks the queue that three other services depend on. Both are certain they hold the deciding vote. Neither has anything in writing that says so.
That argument is not about the agent. It is about a governance gap that was left open when the role was created, and it surfaces at the worst possible moment: when something is already live and already wrong.
The three decisions that actually get contested
Most CAAO job specifications are written in the language of outcomes – adoption, value realisation, agent portfolio. Outcomes are not decision rights. In practice, only three decisions cause standing conflict between a CTO and a CAAO, and every other disagreement is a variant of one of them.
- Model and vendor choice. The CTO owns the platform contract, the security review and the integration cost. The CAAO owns whether the chosen model can actually do the task at the required reliability. These pull in opposite directions when the enterprise-standard model underperforms on the specific workflow, or when the CAAO wants a second provider for redundancy and the CTO sees a second attack surface and a second bill.
- Agent permissions in production systems. Read-only access is rarely contested. Write access is. The dispute is not usually about the permission itself but about who decides when read becomes write – and whether that promotion counts as a change requiring the standard release process or a business decision the CAAO can make on Friday afternoon.
- The authority to halt a live agent. The most consequential and the least often documented. Engineering can always halt on technical grounds: latency, error rate, dependency failure. The open question is whether the CAAO can halt on behavioural grounds – the agent is technically healthy and producing outputs that are wrong, off-policy or reputationally unacceptable.
Four roles, four verbs: build, run, spend, stop
Overlapping mandates get untangled faster by verb than by remit. Assign each contested decision to one of four verbs, then name a single approver per verb. Anything with two approvers is not a decision right, it is a scheduled argument.
| Decision | Proposes | Approves (single) | Must be consulted | Cannot override |
|---|---|---|---|---|
| Model and vendor shortlist | CAAO | CTO | CAIO, security, procurement | CAAO cannot sign a contract |
| Model choice within the approved shortlist, per use case | CAAO | CAAO | CTO (cost and rate limits) | CTO cannot mandate one model for all workflows |
| Read access to a production system | CAAO | System data owner | CTO, DPO | – |
| Write access, or promotion from read to write | CAAO | CTO plus system data owner (both required) | Risk, internal audit | Neither party alone |
| Runtime spend within an approved envelope (e.g. inference budget per agent per month) | Head of automation | CAAO | Finance | CTO cannot reallocate between agents |
| Spend above the envelope, or a new platform commitment | CTO or CAAO | CFO | Both | – |
| Halt on technical grounds (error rate, latency, dependency) | On-call engineer | CTO or delegate | CAAO notified | No approval needed to halt |
| Halt on behavioural grounds (wrong, off-policy, reputational) | Anyone | CAAO | CTO within 30 minutes | CTO cannot reverse without CEO |
| Reinstatement after any halt | Head of automation | Whoever did not order the halt | Both | – |
| Workflow-level automation design and process change | Head of automation | Process owner in the business unit | CAAO | – |
| Enterprise AI policy, model risk standards, permitted data classes | CAIO | CAIO | CTO, CAAO, legal | CAAO cannot grant an exemption |
The split above is a starting draft, not a standard. The load-bearing feature is the last column: naming what each executive explicitly cannot do is what stops the table degrading into a diagram nobody consults. Where your organisation has no CAIO, fold the policy row into the CAAO’s remit and note that the same person then both sets the standard and operates against it – a concentration your audit committee will ask about.
Three clauses that are almost always missing
The gaps are consistent enough to check for directly.
Clause one: the halt is unilateral, and the reversal is not. A halt authority that requires agreement is not an authority. Write it so that either the CTO or the CAAO can stop a live agent alone, with no consultation and no delay, and so that restarting it requires the consent of the person who did not stop it. This is asymmetric on purpose. Stopping should be cheap and restarting expensive, because the cost of a wrongly halted agent is measured in hours of manual work and the cost of a wrongly running one is measured in customers.
Clause two: permission changes have a named approver and an expiry. Most incidents involving agent authority begin with a temporary elevation that nobody removed. Grant write access with a stated end date – 30 or 90 days is common practice for privileged access generally, though the right figure depends on your release cadence and audit obligations, so set it against your own change management standard rather than importing a number. Require re-approval to extend. Log the approver by name, not by team.
Clause three: the definition of “production”. A surprising share of CTO-CAAO disputes are definitional. An agent reading a live customer database to draft a message a human then sends – is that production? If the answer is no, the CAAO ships it without the release process. If the answer is yes, it queues behind the platform backlog. Settle it once: any agent that touches live customer data or live systems is production, regardless of whether a human sits between the agent and the outcome. Human-in-the-loop is a control, not a category.
Sequence for settling it in one session
This does not need a workshop series. It needs one meeting with the CEO in the room and a document that leaves it signed.
- List every agent currently live or in build. For each, record the systems it touches and whether its access is read or write. Expect the list to be longer than the CTO thinks and the write column longer than the CAAO thinks.
- Take the three contested decisions and assign a single approver to each, in writing, before discussing anything else.
- Write the halt clause first and test it against a live case from the last quarter. If nobody can say who would have made the call, the wording is not finished.
- Set the spend envelope per agent in currency per month, not as a percentage of an IT budget. Percentages move; envelopes get noticed when breached.
- Agree a review trigger, not a review date: the table is reopened when a new system class comes into scope, when an agent gets write access to a regulated system, or after any incident that required a halt.
Regulatory floor under the argument
For organisations in scope of the EU AI Act, human oversight requirements for high-risk systems include the ability for an assigned person to intervene in or interrupt operation. That places a legal floor under clause one: someone must be able to stop the system, and that someone must be named and competent to do it. The Act entered into force on 1 August 2024 with obligations phased in, and the timetable for high-risk provisions has been subject to amendment – verify the current position against the consolidated text before citing dates in a board paper. Financial services firms will find similar expectations in existing model risk and outsourcing supervision, which typically predate any AI-specific rule.
The practical point is narrow. Regulation tells you a halt capability must exist. It does not tell you whether the CAAO or the CTO holds it. That remains an organisational choice.
The choice the CEO cannot delegate
There are two coherent designs and no viable middle.
The first: the CAAO holds a veto on production access and a unilateral halt authority on behavioural grounds. That makes the role executive. It needs a direct line to the CEO, a budget line of its own, and someone with the standing to overrule a CTO in front of the board and survive it. It also needs the CTO’s mandate rewritten in the same session, because a veto granted without a corresponding subtraction produces a CTO who routes around it.
The second: the CAAO is advisory. It sets standards, measures agent performance, builds the business case and escalates. All production authority sits with the CTO. That is a legitimate design, cheaper, and appropriate for organisations running a handful of agents in low-risk workflows. It should be staffed and titled accordingly – a director-level role reporting into the CTO or the COO, not a C-suite appointment with no ability to stop anything.
What fails is the third option that most organisations pick by default: a C-suite title, a mandate written in outcome language, and no decision rights at all. That produces an executive accountable for agent behaviour they cannot halt, which lasts about as long as the first incident.
Put both designs on one page, take them to the next executive meeting, and ask the CEO to pick one before the next agent gets write access to a production system. If the meeting ends without a name against the halt clause, the answer is design two – whatever the title on the door says.