Who Manages the Agents? The Org Chart Question Nobody Answers Until Something Breaks

A client called me last year about an agent that had been producing wrong output for around six weeks. Nothing crashed. No alert fired. The finance team had been quietly correcting its work and had assumed that was normal, because nobody had told them what normal was supposed to look like.

When we traced it back, the cause was mundane: an upstream system had changed a field format in a release, and the agent had adapted to the change in the worst possible way, by producing plausible output from bad input.

The interesting question was not the bug. It was that when I asked who owned this agent, I got four names and none of them were confident. The engineer who built it had moved teams. The product manager who sponsored it had left. The finance team used it but did not consider themselves responsible for it. IT ran the infrastructure it sat on.

That gap is the most common operating failure I see, and it is not a technology problem at all.

Agents fail differently, and org design has not caught up

Traditional software fails loudly. It throws an exception, the page fails to load, the job errors out, somebody gets paged. The whole discipline of on-call is built around that failure shape.

Agents mostly fail quietly. They produce output that is well-formed, plausible, and wrong. They drift as the world around them changes: a source system alters a format, a policy document is updated and the agent is still working from the old one, a new category of input appears that nobody anticipated. Nothing errors. The numbers just stop being right.

That means the monitoring you have does not cover the failure mode you have. Uptime is 100%. Error rate is zero. Quality has fallen off a cliff and nothing in your stack knows.

Detecting that requires someone whose job includes looking, with a defined idea of what good looks like, on a schedule. That is a role, not a side effect of having deployed something.

The two owners every agent needs

The model that works, and I have now seen enough of both to be fairly confident, is two named owners per production agent.

The business owner is the person whose work the agent affects. They define what correct output means, they sign off on changes to its scope, and they are the escalation point when it does something contentious. Crucially, they own the quality bar. Not IT. The person who would have done the work.

The technical owner keeps it running: the integrations, the model version, the cost, the logs, the deploys. They are on call for it in the ordinary engineering sense.

Both names go in a registry, alongside what the agent does, what it can access, and a review date. When either person leaves or moves, the handover is an explicit event rather than a silent gap.

This sounds bureaucratic written down. In practice it is a row in a table, and it is the difference between an agent that gets noticed when it drifts and one that runs for six weeks producing careful nonsense.

The escalation queue is a real job with real headcount

Here is the budgeting mistake I see most often.

An agent is proposed to handle a process that takes four people. The business case says it will handle 85% of volume, so the saving is 85% of four people. The plan is approved on that basis.

Then it goes live and the arithmetic falls apart in two places.

The 15% the agent hands back is not a random 15%. It is the hard 15%, the ambiguous cases, the ones with missing information or conflicting instructions. It takes longer per case than the average case did before, and it requires more experienced people, because the easy work that used to give juniors context has been automated away.

And reviewing the agent's work is itself work. Somebody has to spot-check output, investigate the odd result, and decide whether a borderline case was handled acceptably. If nobody is allocated to it, either it does not happen, which is how you get six weeks of wrong numbers, or it happens invisibly, absorbed by people who now have two jobs.

I would plan for the escalation and review load at somewhere around 25 to 35% of the original team for the first two quarters, dropping as the agent improves and as you learn what actually needs looking at. That is still a strong saving. It is just not the number on the original slide, and it is much better to say so up front than to discover it in month three when the team is drowning.

What changes for the managers

The subtler shift is what happens to management practice in a function where part of the work is done by software that makes judgment calls.

Managers have always defined quality implicitly. You review someone's work, you say this bit is not right, they adjust, and over months they internalise a standard nobody ever wrote down. That mechanism does not work on an agent. You cannot correct it in a one-to-one and expect it to remember.

To manage an agent you have to make the standard explicit enough to be measured. What are the categories of case. What is a correct outcome for each. What is the acceptable rate of each kind of error, because it is not zero for humans either and pretending it is for agents leads to bad decisions. Which errors are recoverable and which are not.

Most managers have never had to do this and find it genuinely hard, which is not a criticism. It is a skill nobody needed before. The managers who do it well end up with something valuable beyond the agent: a written definition of good work in their function, which turns out to help with hiring, training, and their own performance conversations.

The other change is that a manager's team now has a cost curve instead of a headcount. Volume rises and the agent costs more, immediately, rather than the team quietly absorbing it until somebody asks for a hire. That is more transparent and considerably less comfortable, and it takes people a while to get used to being asked why last month's spend was up 30%.

Where the function should sit

I get asked whether agent operations should be a central team or distributed into the business units. Both fail in predictable ways when done purely.

Fully central, and you get a team that owns fifteen agents across eight functions and does not understand the domain of any of them. They can tell you the agent is running. They cannot tell you the output is wrong, because they do not know what right looks like for an insurance claim or a purchase order.

Fully distributed, and every function reinvents monitoring, evaluation, logging, and cost tracking, badly, and nobody can answer an organisation-wide question about what is deployed.

What I have seen work is a small central platform group that owns the shared machinery, identity issuing, the registry, tracing and evaluation infrastructure, cost reporting, security review, and the standards everyone builds to. Then business ownership of individual agents sits with the function whose work they do. Central owns how, local owns what.

The size of that central group is smaller than people expect. Three to six people covers an organisation with dozens of agents, provided they are building platform rather than operating each agent.

The review cadence that actually catches things

Concretely, what should someone be doing on a schedule.

Weekly, the technical owner looks at volume, cost per completed task, failure and escalation rates, and the median step count of a run. Those four numbers moving is almost always the first sign of something changing, before anyone notices quality.

Monthly, the business owner samples output. Not a dashboard. Actual cases, chosen randomly, read properly. Twenty cases takes an hour and it is the highest-value hour in the whole operating model. Every quiet degradation I have seen was visible in a random sample weeks before it was visible anywhere else.

Quarterly, both owners review scope. Is the agent still doing what it was scoped to do. Has anyone extended it informally. Does it still need all the access it has. Is it still worth running, which is a real question and occasionally the answer is no.

Annually, or on any material change, revisit the risk assessment. New tools, new data sources, and new downstream consumers all change the blast radius.

None of this is heavy. It is maybe three hours a month per agent across two people. The organisations that skip it are not saving three hours, they are deferring an incident.

The uncomfortable part

There is a version of this conversation that gets avoided, and I think it is worth being direct about.

When you automate 85% of a function, the remaining team is smaller, more senior, and does harder work. That is a real change to real people's jobs, and how it is handled determines whether the agent gets a fair evaluation. Teams that believe an agent is there to eliminate them will find its failures and report them enthusiastically. Teams that believe it removes the work they hate will find its failures and report them constructively. Same failures, opposite outcomes.

I do not have a clever answer for this beyond being honest early. The projects I have seen go badly at the human level were the ones where the plan was known at the top and vague in the middle, and where people worked out the shape of it from context rather than being told.

The technology part of agent operations is well understood. The part that determines whether it works is who is responsible, whether they have the time, and whether the people around it are being told the truth.

We help teams put this operating model in place alongside the builds, because we have watched too many good agents degrade in the absence of one. If you have agents running and cannot name their owners, start there, and let's talk if you want help.