A customer support agent has been allowed to approve refunds up to a modest limit without a human in the loop. It works well for a month. Then, one Monday, a change to the returns policy reaches the website but not the agent, and it spends the morning cheerfully refunding orders that no longer qualify. By the afternoon there are three meetings about it, in three different parts of the building, and each one concludes that the problem belongs to somebody in one of the other two.
IT says the agent behaved exactly as configured. Operations says IT did the configuring. Finance says it never approved a refund budget for a piece of software in the first place. Everyone is correct, and the refunds are still gone. That afternoon is a preview of an argument most companies have not yet realised they are about to have.
An agent does not fit in any of the boxes
For decades, the question of who owns a tool had a boring answer. Software belonged to IT, which bought it, secured it and kept it running. Work belonged to the business, which decided what got done and judged whether it was any good. Spending belonged to finance. The boxes did not always get along, but at least everyone knew which one they were standing in.
An agent sits awkwardly across all three. It is software, so it needs integration, access control and someone awake when it falls over. It does a job, so it needs someone who understands the work well enough to say when the output is wrong. And it spends money in a way traditional tools never did, both directly through usage costs and indirectly because it now sits in every conversation about whether a role gets backfilled. A useful way to put it: an agent is a piece of software with a job description. Our org charts have a place for each half and no place for the whole.
Each department is half right
IT's claim is the oldest and the most defensible on paper. An agent that can read the order system and issue refunds is, from a security point of view, a privileged user that never sleeps. Somebody has to decide what it may touch, rotate its credentials, keep logs and switch it off in a hurry. Letting each team wire up its own agents with a personal API key is how you end up with a long list of things nobody remembers creating.
Operations has the better claim on the work itself. The support lead knows that the returns policy has three unwritten exceptions, that one product line always generates disputes, and that customers who write in capitals are usually right. None of that is in a ticket. An agent tuned without that knowledge will be technically sound and wrong in ways only the floor will notice.
Finance arrives last and talks loudest, because agents change the shape of cost. A licence is a fixed line you negotiate once a year. Usage-based pricing grows with success, and an agent that people actually like will cost more every quarter. Add the creeping habit of asking whether a vacancy should go to a person or a machine, and finance starts to see agents as headcount by another name. It wants the budget, because whoever holds the budget gets to ask the questions.
Whoever builds it, it will look like them
Conway's law says systems end up mirroring the communication structure of the organisation that builds them. With agents, the mirror is unusually clear, and you can often tell who won the turf war just by using the thing.
An agent built by IT tends to be secure, well logged, carefully permissioned and slightly useless. It answers questions nobody on the floor was asking and refuses the ones they were. An agent built by operations is the reverse: genuinely helpful, adored by the team, and held together with a spreadsheet, a shared login and the goodwill of one analyst who is about to go on parental leave. An agent built under finance's eye is costed to the penny and so throttled that people quietly go back to doing the task by hand, which, to be fair, also keeps the costs down.
None of these failures comes from bad people. Each department is optimising for what it is measured on. The agent simply inherits the incentives of its parent, the way a teenager inherits a surname.
The budget fight is the real fight
Most ownership arguments sound like they are about governance. Listen a little longer and they turn out to be about money, specifically about who absorbs the bill when an agent turns out to be popular.
The Jevons paradox applies here with some force. When a task gets cheaper, people do more of it, so the total spend goes up. A procurement team given an agent that drafts supplier comparisons will not produce the same number of comparisons for less money. It will start comparing suppliers it never bothered to compare before, which is probably good for the business and certainly bad for whoever owns the cost centre.
That creates a perverse incentive. If usage lands on the budget of the team that deploys the agent, the most successful deployments become the most punished. Teams learn to keep their agents modest and their adoption quiet. If usage lands centrally, nobody has a reason to stop a wasteful one. Neither arrangement survives contact with a real quarter, which is why the argument keeps coming back.
Decide who gets blamed before you decide who gets credit
The way out is less exotic than it sounds. Treat each agent the way you would treat a hire who happens to be software, and split the parental duties along the lines each department is actually good at.
The business owner is the manager of the function where the agent works. That person answers for its output, the same way they answer for their team's. IT acts as the landlord: it provides the platform, the permissions and the off switch, and it is accountable for the agent being safe rather than for it being useful. Finance acts as payroll: it sets the budget envelope with the business owner and agrees in advance what happens if success pushes the cost through the ceiling.
Then write it down on one page, before launch. What the agent may do, and the limits on it. Who it reports to. Who reviews its work and how often. What it costs and who pays. How it gets switched off, and who is allowed to do that at three in the morning without asking anyone first. That last line matters more than it looks: when something goes wrong, the most expensive minutes are the ones spent working out who has permission to act.
Go back to the refund agent. With a page like that, the Monday looks different. The support lead owns the output, so the policy change reaches the agent through the same channel it reaches the team. IT has a kill switch and a named person holding it. Finance agreed the refund ceiling in advance and can see it being hit before lunch, not at month end.
So before the next agent goes live, try one small exercise. Write down the name of the person who will be in the room when it makes its first expensive mistake. If three departments each write a different name, or none at all, the agent is not ready, however good the demo was.
