An agent goes into production. Six weeks later it makes a decision that costs money. The incident review convenes, and the first twenty minutes are spent establishing who is responsible.
The platform team says they provided infrastructure and did not author the prompt. The product team says they specified the outcome and do not control the model. The data science team says they tuned it against a spec they did not write. The business owner says they approved a capability, not a specific decision. Everyone is being reasonable, and there is no owner.
This is the most common way enterprise agent programmes stall, and it is not a technical problem. Agents are the first software artefact most organisations have deployed where the boundary between “the system” and “the decision” is genuinely unclear — and existing ownership models do not resolve it, because they were built for software that does what it was told.
Why existing models do not transfer
Three properties make agent ownership genuinely different rather than merely new.
The artefact is not primarily code. An agent’s behaviour is determined by instructions, tool definitions, retrieved context, model version, and configuration. Much of that is not in a repository, is not reviewed as code, and changes without a deployment. “The team that owns the repo owns the system” stops being a complete answer when the most behaviour-determining artefact is a prompt someone edited in a console.
Behaviour changes without a change. A provider updates a model. A retrieved corpus shifts. A tool’s response format changes. The agent behaves differently and no one on the owning team did anything. Conventional ownership assumes change originates with the owner — which is why evaluation on a bare schedule is an ownership control and not only an engineering practice.
Accountability is bifurcated. There are two distinct things to own: the system (does it function, cost what it should, stay available) and the decisions (are its outputs correct, fair, and defensible). In traditional software these collapse together, because the decisions are ones someone specified explicitly. In agent systems they do not, and conflating them is the specific reason incident reviews go in circles.
The two ownership roles you actually need
The single most useful structural change is to name these separately and staff them differently.
The system owner is accountable for the agent as a running service: availability, latency, cost, observability, incident response, dependency currency, and lifecycle decisions. This is an engineering role and belongs with an engineering team. It looks a great deal like conventional service ownership, and existing SRE practice mostly transfers.
The decision owner is accountable for what the agent decides: whether outputs are correct, whether the autonomy profile is appropriate, whether escalation thresholds are right, and whether the outcomes are defensible to a customer, a regulator, or an auditor. This is a business role, and it belongs with whoever owned the outcome before the agent existed.
That last clause is the important one, and it connects directly to the first block of the AI Agent Canvas: naming the current owner of the outcome. If accounts payable owned invoice approval before the agent, the head of accounts payable is the decision owner after it. Handing decision accountability to the engineering team that built the agent is the most common structural mistake, and it fails in both directions — engineers cannot adjudicate whether a business decision was correct, and the business stops paying attention to decisions it is still accountable for externally.
The two roles must be named individuals, not teams. “The platform team owns it” reliably means nobody does.
Where the capability lives
Beyond individual agents, there is the question of how the organisation is structured to produce them. Three patterns, with reasonably predictable trajectories.
Centralised. A single team builds all agents. Fast to establish, produces consistent quality, and concentrates scarce expertise — the right choice for the first handful of agents. It becomes the bottleneck at roughly the point where demand exceeds the team’s throughput, which happens sooner than expected. The characteristic failure is a two-quarter backlog and business units quietly building unsanctioned agents on SaaS tools, which is worse than either alternative because it is invisible.
Federated. Each business unit builds its own. Scales with demand and produces agents that fit their domains. The characteristic failure is duplication and divergence: six teams solving identity differently, no shared evaluation practice, and no one able to answer how many agents the organisation operates. Governance arrives late, retroactively, and is resented.
Platform plus embedded. A platform team owns shared infrastructure — the gateway, identity, observability, evaluation harness, capability layer, cost attribution, and the approved patterns — and domain teams build agents on it. This is where most organisations that succeed at scale end up, and it is the Team Topologies platform pattern applied to a new substrate.
The consistent lesson from organisations that got there: the platform must make the governed path the easiest path. If using the platform is slower than calling a provider SDK directly, teams will call the SDK directly, and your governance model becomes documentation. The platform team’s actual product is not infrastructure — it is the reduction in effort required to do the right thing. Where that inverts, agentic debt accumulates regardless of policy.
The roles that are genuinely new
Most agent work is done by people who already exist under slightly changed job descriptions. Two capabilities, though, have no clean precedent and tend to go unstaffed.
Evaluation engineering. Someone must own the golden datasets, the judge calibration, the regression thresholds, and the analysis when a run degrades. This is a real, specialised discipline, and it is nobody’s job by default — which is why evaluation suites decay within two quarters at most organisations. It sits naturally with the platform team as a shared capability, with domain teams owning their own datasets.
Human-in-the-loop operations. If agents escalate, someone receives the escalations. This capacity is systematically underestimated: teams model the agent’s throughput and not the review queue it generates, then discover that a 6% escalation rate at 10,000 requests a day is 600 human decisions requiring staffing, training, and its own quality management. Worse, an under-resourced review queue degrades into rubber-stamping, which invalidates the autonomy border it was supposed to enforce and — for high-risk systems — the human oversight requirement that depends on it.
Plan the review capacity when you design the escalation threshold. They are the same decision, and treating them separately is how a control becomes theatre.
What good looks like operationally
A few practices distinguish organisations where this works.
Every agent has a named system owner and a named decision owner, recorded where the agent is registered. Not in a slide. In the inventory, alongside its autonomy profile and cost ceiling.
An agent inventory exists and is complete. You cannot govern, cost, or classify an estate you have not enumerated. The count is almost always higher than the central list says.
Autonomy changes are governance events. Raising an agent’s autonomy because it has earned trust is a decision with a record and an approver — the mechanism the Applied Autonomy Framework describes. Autonomy that drifts upward through configuration changes is how organisations end up with agents nobody authorised.
Incident review covers decisions, not only outages. An agent that stayed available while producing a materially wrong output has had an incident. If your review process only triggers on availability, you will not learn from the failures that matter most.
Decommissioning is somebody’s job. Agents accumulate. Without a periodic review that asks whether each one still earns its cost and risk, the estate grows monotonically. This is the lifecycle stage that is always specified and never staffed.
What structure cannot fix
Organisational design does not compensate for a missing outcome definition. If nobody can say what a good result looks like, no ownership model produces one — the decision owner will simply be accountable for something unmeasurable, which is how the role becomes nominal.
It also does not resolve genuine disagreement about acceptable risk. A structure that names a decision owner gives you someone to make the call, which is materially better than diffusion, but it does not tell them what the right call is. That requires a risk appetite the organisation has actually agreed, and most have not.
And no structure survives a mandate to deploy agents without the authority to say no. Decision ownership without the power to decline deployment is not accountability; it is exposure. Where senior sponsors treat governance as an obstacle to a target, the ownership model will be formally correct and practically empty — which is the organisational shape behind most of the incidents in the 2026 security data.
Key takeaways
Agent ownership is genuinely different from software ownership because the behaviour-determining artefacts are largely not code and not in a repository, behaviour changes without anyone changing anything when providers update models or corpora shift, and accountability bifurcates into owning the system versus owning the decisions — a distinction that collapses in traditional software and is the specific reason agent incident reviews go in circles. Name both roles as individuals: a system owner in engineering accountable for availability, cost, observability, and lifecycle; and a decision owner in the business accountable for correctness, autonomy profile, and defensibility, assigned to whoever owned the outcome before the agent existed rather than to the team that built it. Organisationally, centralised delivery works for the first few agents and becomes a bottleneck that pushes teams into unsanctioned tools, federated delivery scales but diverges, and most successful organisations converge on a platform-plus-embedded model whose critical property is that the governed path must be the easiest path — otherwise governance becomes documentation. Two capabilities have no precedent and go unstaffed by default: evaluation engineering, without which eval suites decay within two quarters, and human-in-the-loop operations, where review capacity must be planned at the same time as the escalation threshold, because an under-resourced queue degrades into rubber-stamping and invalidates the control it exists to enforce.