Who Owns the Agents Inside a Company? The Accountability Question Nobody Asked Until It Broke

Table of Contents

• The Question That Sounds Trivial and Isn't
• What "Ownership" Actually Means for an Agent
• The Four Claimants
• The Business Unit
• IT and Platform Engineering
• Security, Risk, and Legal
• Procurement and Finance
• Three Ownership Models That Actually Ship
• The Digital-Employee Model: One Agent, One Manager
• Who Owns a GaaS Agent You Don't Run Yourself?
• A Practical RACI You Can Steal
• Insights Most People Overlook
• References

The Question That Sounds Trivial and Isn't

Ask "who owns the laptop fleet" and you get an answer in five seconds: IT. Ask "who owns the CRM" and someone says RevOps or Sales. Ask "who owns the invoice-reconciliation agent that touched 40,000 transactions last quarter and quietly approved a duplicate payment," and the room goes quiet.

That silence is the whole topic. Agents are a new kind of corporate asset, they act, they decide, they spend, and they do it continuously without a human in the loop for most cycles. Yet they're being slotted into org charts built for two things only: people and software. An agent is neither. It behaves more like a junior employee than like a SaaS license, but it gets purchased, provisioned, and forgotten like a SaaS license. The mismatch is where accountability leaks out.

This matters more in the GaaS era because the agent often isn't even yours. You're renting outcomes from a vendor, per task, per resolved ticket, per closed loop. So now "ownership" has to answer a harder question: who inside your company is accountable for something a third party's autonomous system did on your behalf? If you've read the companion pieces on the AgentOps function emerging and why IT and the business fight over agent ownership, this is the foundation underneath both.

What "Ownership" Actually Means for an Agent

People use "own" to mean five different things and then argue past each other. Separate them and the fight mostly dissolves.

• Accountability, whose name is on it when it fails. This is the one that can't be shared. The moment two people are "accountable," nobody is.
• Operational responsibility, who keeps it running, patches it, watches the dashboards, handles the 2 a.m. page.
• Budget, whose cost center the per-task invoice hits.
• Governance, who sets the guardrails: data access, spend limits, what the agent is allowed to decide unilaterally.
• Product/lifecycle, who decides what the agent should do next, when to expand its scope, when to retire it.

A healthy ownership model assigns each of these deliberately. The failure mode isn't that a company picks the wrong owner, it's that it never picks at all, and the five concepts get smeared across whoever happened to run the pilot. Six months later that person changes teams and the agent becomes an orphan: still running, still spending, nobody's job to watch.

The Four Claimants

Four functions will reach for the steering wheel. Each has a legitimate claim and a blind spot.

The Business Unit

The team that uses the agent, support, finance, marketing ops, understands the work the agent does and feels the pain when it does it badly. Strong argument for them holding accountability and product direction. Their blind spot: they consistently underestimate the security surface and the integration debt. A support lead who "owns" a refund-issuing agent rarely thinks about token scopes or audit logging until an incident forces it.

IT and Platform Engineering

IT owns identity, networking, the systems the agent plugs into, and the operational muscle to run things reliably. Natural home for operational responsibility. Their blind spot is the opposite of the business unit's: they'll happily run an agent flawlessly while having no idea whether it's doing the right thing for the business. "It's up 99.9% of the time" is not the same as "it isn't quietly approving bad refunds."

Security, Risk, and Legal

This group has the strongest claim on governance and the weakest claim on day-to-day ownership, and they know it, which is why they often try to govern by saying no. Agents are an identity-and-access problem at heart: each one is a non-human identity with credentials, permissions, and the ability to act. Microsoft's guidance on securing and governing AI agents frames them squarely as non-human identities that need lifecycle management like any other privileged account. The blind spot here is overreach: security that owns operations grinds adoption to a halt.

Procurement and Finance

In a GaaS world this group matters more than people expect, because outcome-based pricing turns every agent into a variable-cost line item that can scale without a new purchase order. Finance owns the budget question and increasingly the vendor-management question once you're running thirty different agents from a dozen vendors. Their blind spot: they treat agents as procurement events (buy it, file the contract, done) when agents are living deployments that drift, expand scope, and accrue risk continuously.

Three Ownership Models That Actually Ship

There's no single right answer, but there are three patterns that work and one anti-pattern that always fails (the anti-pattern: leave it undefined and hope the pilot owner figures it out).

1. Federated, business-owned. Each business unit owns its agents end to end, accountability, product, budget, while a central platform team provides the runtime, identity, and guardrails as a paved road. This scales fastest and matches how most companies already run their software. Risk: inconsistent governance and duplicated effort across units. Works best once you have an internal agent center of excellence setting standards the units must follow.

2. Centralized, COE-owned. A central team owns the entire agent fleet, builds, runs, and governs every agent as a shared service. Tight control, consistent security, easy auditing. The cost is that the central team becomes a bottleneck and the business units feel like they're filing tickets to a black box. Good for highly regulated firms and the early days of a program; it strangles velocity at scale. The trade-off between these two is the entire subject of when to centralize vs. federate agent deployment.

3. Hybrid product-team model. Each significant agent gets a small standing product team, a business owner, an engineer, a security partner, the way you'd staff a real internal product. This is the most expensive per agent and the most robust. Reserve it for agents that touch money, customers, or regulated data; use the federated paved road for everything else.

McKinsey's work on scaling AI agents across the enterprise makes the same underlying point in different language: the bottleneck to agent value isn't model quality, it's the operating model around the agent. Ownership is the spine of that operating model.

The Digital-Employee Model: One Agent, One Manager

Here's the framing that cuts through most of the confusion: treat every production agent like an employee, and give it a manager.

Not metaphorically, operationally. A new hire gets a name, a manager, a scope of authority, system access provisioned through a controlled process, a performance review, and an offboarding when they leave. An agent should get exactly the same, and the single most important of those is the manager: one named human who is accountable for what this agent does.

That person doesn't have to run the agent or build it. A manager doesn't write their report's code or fix their laptop. But they answer for outcomes, they approve scope changes, and they're the escalation point when something goes wrong. This is the idea behind onboarding an agent like you'd onboard an employee and the emerging agent-manager job description, and it solves the accountability-can't-be-shared problem cleanly: every agent has exactly one throat to choke.

The digital-employee frame also fixes the offboarding gap, which is where most of the real risk lives. Companies are good at deploying agents and terrible at decommissioning them. An agent whose human manager left, whose purpose is now handled another way, but whose credentials are still live and whose per-task billing still runs, that's not a hypothetical, it's the default outcome of having no ownership model. If every agent has a manager, then when that manager leaves, the agent shows up in the transition checklist like any other report.

Who Owns a GaaS Agent You Don't Run Yourself?

GaaS complicates this because the agent's brains, and sometimes its hands, live at a vendor. You can't "operate" an agent running in someone else's cloud. So what's left to own?

Plenty, and it's the part that matters legally. You still own:

• The decision to deploy it and the scope you granted it. The vendor built the agent; you pointed it at your data and your customers.
• The credentials and data access you handed over. The agent acts under permissions you provisioned. If it over-reaches, that's your access-control failure, not just the vendor's bug.
• The business outcome the agent is accountable for, and the accountability to your own customers and regulators. Your customer doesn't care that a third party's agent mishandled their refund; they hold you responsible.
• Vendor governance, the SLAs, the audit rights, the kill switch. If you can't pause a GaaS agent within minutes, you don't own it in any meaningful sense, no matter what the contract says.

The trap is assuming "it's a managed service" means "it's the vendor's problem." Outsource the operation, never the accountability. The right internal owner for a GaaS agent is whoever owns the outcome it produces, and that person needs contractual leverage (kill switch, audit logs, liability terms) baked in during the procurement process for buying agents, not negotiated after an incident.

A Practical RACI You Can Steal

If you want one artifact to walk into a meeting with, build a RACI per agent across the five ownership dimensions. A workable default for a mid-stakes internal agent:

• Accountable (one name): the business owner who owns the outcome. Singular. Always.
• Responsible (operations): the platform/AgentOps team for an in-house agent; the vendor plus an internal vendor-manager for a GaaS agent.
• Consulted (governance): security and legal set guardrails, spend caps, and data-access policy. They have veto on scope, not on existence.
• Informed (budget): finance owns the cost center and watches the per-task spend curve.

Two rules make it hold. First, the Accountable cell never contains a team, only a person, because agent governance built from scratch lives or dies on individual accountability. Second, the RACI is reviewed when the agent's scope changes, not filed and forgotten, agents drift, and an ownership model that's only correct on day one is wrong by day ninety.

Insights Most People Overlook

Ownership disputes are usually scope disputes in disguise. When IT and the business fight over who owns an agent, they're rarely fighting about org-chart turf, they're fighting because nobody defined what the agent is allowed to decide on its own. Pin down the agent's decision authority (it can issue refunds under $50, it must escalate above that) and the ownership question often answers itself, because authority and accountability travel together.

The most dangerous agents are the ones nobody fought over. Companies obsess over governing the high-profile customer-facing agent. The real liability is the quiet internal agent some analyst spun up to reconcile a spreadsheet, which now has standing database access and zero oversight. Shadow agents don't come from malice; they come from agents being easy to create and ownership being nobody's default job. The fix isn't more policy, it's making the paved road easier than the side road.

"Owner" and "builder" must be different people, on purpose. There's strong pressure to let whoever built the agent own it, because they understand it best. That's exactly backwards for accountability. The builder is incentivized to defend the agent and expand its scope; the owner needs to be willing to constrain or kill it. Conflating the two means the agent never gets retired, because its own parent decides its fate.

Per-outcome pricing quietly relocates ownership to finance, and that's a problem. When an agent bills per resolved ticket, its cost scales with usage, invisibly, with no new purchase decision. That makes finance the de facto gatekeeper (they see the bill climbing) even though they understand the agent's behavior least. If finance becomes the only function watching the agent grow, you've put your weakest-informed group in the decision seat. The outcome-based model that makes GaaS attractive is the same one that scrambles ownership.

The kill switch is the truest test of ownership. Forget the RACI for a second and ask one question: if this agent started doing something harmful right now, who could stop it within five minutes, and do they know they're allowed to? If the honest answer is "we'd have to email the vendor and wait," nobody owns it. Real ownership is the demonstrated ability to halt the thing, fast, without a committee.

References

• Securing and governing AI agents, Microsoft Learn
• Seizing the agentic AI advantage, McKinsey & Company