Governance & Operations

Who Owns the Agent?

Agents fail organisationally before they fail technically. In traditional software, owning the system and owning its decisions collapse together — in agent systems they do not, and conflating them is why incident reviews go in circles.

Two roles, named individuals, staffed differently
Engineering

System owner

Sits with the engineering team that runs it
  • Availability and latency
  • Cost and budget enforcement
  • Observability and trajectory logging
  • Incident response
  • Dependency and model-version currency
  • Lifecycle and decommissioning
Business

Decision owner

Sits with whoever owned the outcome before the agent existed
  • Are the outputs correct?
  • Is the autonomy profile appropriate?
  • Are escalation thresholds right?
  • Are outcomes defensible to a customer, regulator, or auditor?
  • Authority to decline deployment

The most common structural mistake

Handing decision accountability to the engineering team that built the agent. It fails in both directions: engineers cannot adjudicate whether a business decision was correct, and the business stops paying attention to decisions it remains externally accountable for. If accounts payable owned invoice approval before the agent, the head of accounts payable is the decision owner after it. Both roles must be named individuals — "the platform team owns it" reliably means nobody does.

Why agent ownership differs from software ownership

The artefact is not primarily code

Behaviour comes from instructions, tool definitions, retrieved context, model version, and configuration. Much of it is not in a repository, not reviewed as code, and changes without a deployment.

Behaviour changes without a change

A provider updates a model, a corpus shifts, a tool's response format moves — the agent behaves differently and nobody on the owning team did anything. Conventional ownership assumes change originates with the owner.

Accountability bifurcates

There are two distinct things to own: does it function, and are its decisions right. Traditional software collapses these because the decisions were explicitly specified.

Where the capability lives
Centralised

One team builds all agents

Fast to establish, consistent quality, concentrates scarce expertise. The right choice for the first handful.

Fails as: a two-quarter backlog, with business units quietly building unsanctioned agents on SaaS tools — worse than either alternative because it is invisible.

Federated

Each business unit builds its own

Scales with demand, produces agents that fit their domains.

Fails as: six teams solving identity differently, no shared evaluation practice, and nobody able to say how many agents the organisation operates. Governance arrives late and is resented.

Platform + embedded

Shared infrastructure, domain teams build on it

Gateway, identity, observability, evaluation harness, capability layer, cost attribution, and approved patterns owned centrally. Where most organisations that succeed at scale end up.

Critical property: the governed path must be the easiest path. If using the platform is slower than calling a provider SDK directly, teams will call the SDK — and your governance model becomes documentation.

Two capabilities that go unstaffed by default

Evaluation engineering

Someone must own the golden datasets, judge calibration, regression thresholds, and the analysis when a run degrades. A real specialised discipline, and nobody's job by default — which is why eval suites decay within two quarters. Sits naturally with the platform team, with domain teams owning their own datasets.

Human-in-the-loop operations

If agents escalate, someone receives the escalations. Teams model the agent's throughput and not the review queue it generates.

6%escalation rate
×
10,000requests / day
=
600human decisions / day

Requiring staffing, training, and its own quality management. An under-resourced review queue degrades into rubber-stamping — which invalidates the autonomy border it was created to enforce, and the human oversight requirement that high-risk compliance depends on. Plan review capacity when you design the escalation threshold. They are the same decision.

What good looks like operationally

What structure cannot fix

No ownership model compensates for a missing outcome definition — the decision owner simply becomes accountable for something unmeasurable. And decision ownership without the authority to decline deployment is not accountability; it is exposure. Where senior sponsors treat governance as an obstacle to a target, the model will be formally correct and practically empty.