Why IT and the Business Fight Over Who Owns the Agents

Table of Contents

• The Fight Nobody Scheduled
• Why Agents Don't Fit the Old Org Chart
• What IT Is Actually Worried About
• What the Business Is Actually Worried About
• The Five Flashpoints Where the Fight Erupts
• Why the GaaS Model Makes This Worse
• How to Actually Split Ownership
• The RACI That Works for Agents
• Insights Most People Overlook
• References

The Fight Nobody Scheduled

Here's how it usually starts. A revenue operations leader signs up for an agentic service that handles lead qualification, priced per qualified lead, not per seat. It works. It books meetings while the team sleeps. Three weeks in, the agent makes a wrong call on a major account, fires off an email it shouldn't have, and someone in security finds out a tool with write access to the CRM was provisioned without a ticket, a review, or anyone in IT knowing it existed.

Now the meeting happens. IT wants to know who approved the data access. The business wants to know why IT is trying to slow down something that's already producing pipeline. Both walk away convinced the other doesn't get it.

This scene is playing out in thousands of companies right now, and it's worth being honest about why. The fight over agent ownership isn't a personality problem or a sign of a dysfunctional org. It's a structural mismatch. Agentic AI sold as a service, the GaaS model, created a category of thing that no existing ownership framework was built to hold. When you don't have a box for something, two departments reach for it at once.

Why Agents Don't Fit the Old Org Chart

For thirty years, enterprises sorted technology into two clean categories. Software was a tool: IT procured it, secured it, patched it, and supported it. People were headcount: a manager hired them, set their goals, reviewed their work, and owned their outcomes. Every responsibility in the company hung off one of those two hooks.

An agent is genuinely neither. It's not a tool, because it acts on its own, it makes decisions, takes actions in live systems, and produces work product the way an employee does. But it's not headcount either, because it runs on infrastructure, consumes API budget, holds credentials, and can be cloned a hundred times by Tuesday. It behaves like a worker and deploys like software.

That hybrid nature is the root of the entire dispute. The business looks at an agent and sees a digital employee, something it should manage, because it manages the workers who do that job today. IT looks at the same agent and sees a privileged service account with autonomy and network access, something it must own, because it owns everything that touches production data. They're not disagreeing about facts. They're applying two valid mental models to an object that fits both and neither.

This is the same tension that shows up across the GaaS adoption literature, in who owns the agents inside a company, in the emergence of an AgentOps function, and in the internal agent center of excellence debates. The ownership fight is the seed from which most of those later org questions grow.

What IT Is Actually Worried About

It's easy to caricature IT as the department of "no." That's lazy. When you sit with the people running security and platform teams, their concerns about business-owned agents are specific and, frankly, well-founded.

Standing access that nobody scoped. An agent that does a real job usually needs broad permissions, read and often write access to a CRM, a data warehouse, an email system, maybe a payments tool. A human gets that access gradually, with oversight. An agent gets it on day one, frequently through an OAuth flow a business user clicked through without reading. IT is the team that gets breached if that token leaks.

No audit trail by default. When the business stands up an agent on its own, there's rarely logging IT can see, no record of what the agent did, and no way to answer "what happened" when something goes wrong. Security frameworks like the OWASP guidance on agentic AI threats make the point bluntly: autonomous agents expand the attack surface in ways traditional app security wasn't designed for.

The 2 a.m. problem. When the agent breaks, and it will, who gets paged? If the business owns it but can't fix it, the incident still rolls downhill to IT, except now IT is debugging a system it never designed and doesn't understand. Ownership without operability is just a delayed handoff.

Sprawl. One agent is manageable. The danger IT sees coming is the same one it watched unfold with SaaS: every team buying its own, no inventory, no standards, and a governance scramble eighteen months later. That's not paranoia, it's pattern recognition from the shadow agents problem IT lived through with shadow IT.

What the Business Is Actually Worried About

The business side has an equally legitimate case, and dismissing it as "they just want to move fast" misses the point.

They bought an outcome, not a system. The whole appeal of GaaS is that it's sold per task or per result. The business didn't sign up to run infrastructure, it signed up for qualified leads, resolved tickets, or closed books. The moment IT inserts itself as the owner, the business fears the outcome it paid for gets buried under a six-month integration project and a change-advisory board.

They understand the job; IT doesn't. An agent doing collections, or sales development, or claims processing is doing the business's work. The people who know whether the agent is doing it well, whether its judgment is sound, its tone right, its edge cases handled, sit in the business, not in IT. Handing operational ownership to a team that can't evaluate the output feels like handing the keys to someone who can't drive.

Speed is the entire value proposition. McKinsey's research on agentic AI has been clear that the value comes from reimagining workflows, not from layering agents onto old processes and old approval chains. The business reads IT ownership as a guarantee that the workflow redesign never happens and the agent gets neutered into a glorified macro.

Accountability follows ownership. If the business is on the hook for the number, pipeline, CSAT, cost-to-serve, it wants control of the thing now driving that number. You can't hold a VP accountable for results produced by a system someone else controls.

The Five Flashpoints Where the Fight Erupts

In practice, the dispute concentrates around five recurring decisions. Knowing where they are lets you defuse them before they detonate.

1. Provisioning and credentials

Who grants the agent its access, and at what scope? This is flashpoint zero, because it's where business-led adoption most often bypasses IT entirely.

2. Budget and the cost meter

GaaS pricing is consumption-based, which means a runaway agent is a runaway invoice. When per-task costs spike, IT and finance want a kill switch; the business wants the volume that's generating the spend. Whose budget line, and whose authority to throttle?

3. Incident response

When the agent does something wrong, sends a bad email, mis-classifies a transaction, takes an action it shouldn't, who owns the cleanup, the customer apology, and the fix? This is where "the business owns it" quietly collapses.

4. Vendor relationship

Who manages the GaaS provider, contract, SLA, escalations, the roadmap conversation? IT runs vendor management as a discipline; the business has the context on whether the agent is actually delivering.

5. Performance evaluation

Who decides if the agent is good enough to keep, expand, or kill? IT can measure uptime and latency. Only the business can judge whether the work is acceptable. Split that judgment and you get an agent nobody will either fully back or fully retire.

Why the GaaS Model Makes This Worse

If these agents were built in-house, the ownership question would still be hard, but at least one team would have unambiguous technical control. The as-a-service model deliberately removes that. With GaaS, the actual agent runs on the vendor's infrastructure, on the vendor's models, under the vendor's update cadence. Neither IT nor the business built it, which means the usual tiebreaker, "the team that built it owns it", doesn't apply.

It gets thornier. Because GaaS is so easy to buy, a credit card and an OAuth grant, it lowers the activation energy for business-led adoption to almost zero. That's the whole pitch, and it's a genuine strength. But it also means the agent is frequently live and producing value before IT is even aware it exists. You can't negotiate ownership of something one side doesn't know is there. By the time IT discovers it, the business has a working system, a number to defend, and every incentive to resist a handoff.

The outcome-based pricing twists the knife one more turn. When you pay per seat for software, IT naturally owns the license and the relationship. When you pay per resolved ticket, the thing you're buying is indistinguishable from labor, and labor is the business's domain. The pricing model itself nudges the agent toward the business side of the ledger, even as its technical guts pull it toward IT.

How to Actually Split Ownership

The companies getting this right have stopped asking "who owns the agent?" as if it were a single, indivisible thing. It isn't. An agent has at least three distinct layers of ownership, and the trick is to assign each layer to the team genuinely best equipped to hold it.

The platform layer, IT owns it, non-negotiable. Identity, credentials, network access, logging, the kill switch, the security posture, and the audit trail. This is plumbing, and plumbing is IT's job. The business should never be provisioning standing access to production systems, full stop. Gartner's analysts have argued that as agents proliferate, identity and access for machine actors becomes a first-class governance problem, treating an agent's credentials as casually as a SaaS login is how you get the breach.

The work layer, the business owns it. What the agent does, how well it does it, what "good" looks like, when to expand it, when to kill it. The business sets the goals and judges the output, exactly as a manager would for a human in that role. This is the part IT should keep its hands off.

The operations layer, shared, and this is where the discipline lives. Monitoring, performance tuning, incident response, vendor management. This is the layer that needs an explicit, written agreement, because it's where ownership is genuinely joint and therefore where every fight happens. The emerging answer is a dedicated AgentOps practice, a small cross-functional function that sits in the seam, much like DevOps once bridged developers and operations.

The single most useful move is to stop treating the agent as one object and start treating it as a stack. IT owns the bottom, the business owns the top, and the middle gets a contract.

The RACI That Works for Agents

Abstractions are nice; a working team needs specifics. Here's a RACI split that holds up under real conditions. Treat it as a starting template, not gospel, adapt the names to your org.

• Provisioning & access: IT is Responsible and Accountable. The business is Consulted (it specifies what the agent needs to reach). The business should never be Accountable here.
• Defining the agent's job & success criteria: Business is Accountable. IT is Consulted on what's technically feasible.
• Day-to-day output quality: Business is Responsible and Accountable. This is the business's worker.
• Security & compliance posture: IT is Accountable. Both are Informed when posture changes.
• Incident response: This is the hard one. Make IT Responsible for technical containment (kill, isolate, revoke) and the business Accountable for the business consequence (customer comms, decision to resume). Splitting it this way prevents the "not my problem" gap where incidents go to die.
• Cost & budget: Business Accountable for the spend it drives; IT Responsible for the throttle and the alerting that catches a runaway before finance does.
• Vendor relationship: Shared, IT owns the contract and SLA, the business owns the "is this vendor actually delivering" judgment. Co-sign the renewal.

Write it down. The single biggest predictor of whether the ownership fight stays civil is whether somebody documented this before the first incident, not after. A RACI drafted in a calm conference room reads very differently from one negotiated in the wreckage of a bad customer email.

Insights Most People Overlook

The fight is a feature, not a bug, if you catch it early. A turf war over an agent is actually a signal that the agent is doing something real enough to be worth fighting over. The agents nobody fights about are usually the ones producing nothing. The failure mode isn't the conflict; it's resolving it by avoidance, letting the business keep its shadow agent because confronting it is awkward. Surface the fight on purpose, early, while the stakes are still a single agent and not a fleet of thirty.

Whoever owns the kill switch holds the real power, regardless of the org chart. You can write any RACI you like, but the team that can technically stop the agent has the final say in every dispute. That's almost always IT. Smart business leaders stop fighting for nominal "ownership" and instead negotiate for guaranteed responsiveness on the kill switch, an SLA on how fast IT will act, and a rule that IT can't unilaterally kill a revenue-producing agent without the business in the room. Control of the off switch is the ownership question that actually matters.

The vendor is a silent third party in the fight, and usually rooting for the business. GaaS vendors design their products to be bought and run by the business, because that shortens their sales cycle and raises their stickiness. Their onboarding flows, their dashboards, their docs, all subtly route around IT. When IT and the business fight over an agent, the vendor's entire product design is quietly tilting the table toward the business. Recognizing this lets IT push back where it counts: demand enterprise admin controls, SSO integration, and audit exports as procurement requirements, not afterthoughts.

Agent ownership and human accountability can't be cleanly separated, and pretending otherwise creates a liability gap. When an agent makes a consequential error, "the agent did it" is not a defense your legal or compliance team will accept. Some human is accountable for every agent action, and if ownership is muddy, that accountability is undefined at exactly the moment you need it. The ownership fight is, underneath, an argument about whose name is on the agent's decisions. Resolve it before a regulator or a customer's lawyer resolves it for you.

This problem doesn't scale linearly, it scales with the square of your agent count. One agent has one ownership conversation. Thirty agents from a dozen vendors, touching every department, have a combinatorial mess of overlapping access, conflicting owners, and orphaned systems. The companies that wait until they have a fleet to figure out ownership are the ones that end up with the agent sprawl problem. The cheapest time to settle the ownership model is when you have exactly one agent and the fight feels almost too small to bother with.

References

• OWASP Top 10 for Large Language Model Applications
• McKinsey & Company, The Next Frontier of Generative AI: Agents
• Gartner, Information Technology Insights