Operations, not IT, should own agents in production

The team that answers for a process should own the agent that runs it. Once an agent is in production, the questions that matter are about outcomes: what it may decide, who approves its held work, when it widens, what happens when it gets something wrong. Those are operational questions. IT should own the platform underneath, not the agent's authority.

Why do agents end up owned by IT?

Because IT built them. Most agents start as technology projects: a team evaluates models, connects systems, writes instructions and runs a pilot. By the time the agent reaches production, IT knows it best, so ownership stays where the knowledge is.

It also seems natural because agents are software, and software has always been owned by technology. Operations teams may be happy to leave it there. Owning an agent sounds technical and risky, and nobody in operations asked for the job.

What goes wrong when IT owns the agent?

The questions that come up in production are not the ones IT is set up to answer.

A held queue backs up. Is that a staffing problem, a limit set too low, or the agent proposing poorly? IT can see the queue but cannot judge the work in it. An agent's drafts start getting edited more heavily. Is the agent worse, or have the reviewers changed their standard? IT does not know the standard. Someone proposes widening the agent from drafting to executing refunds. Is the evidence good enough? IT can run the test but cannot decide what level of error the business accepts.

Left with IT, these questions get answered in technology terms: uptime is fine, latency is fine, the model is the recommended version. Meanwhile the outcomes the business answers for drift without an owner who would notice.

Accountability is the deeper problem. When an agent wrongly declines a customer or pays the wrong supplier, the customer, the regulator and the board will look to the business function responsible for that process. If that function did not own the agent, it is answering for decisions it never controlled.

How should ownership be split?

Both teams have essential roles. The split follows what each is accountable for.

Operations owns the agent's authority and outcomes. IT owns the platform's health and the mechanics. Neither can do without the other, but there must be no doubt about who decides what the agent may do. Our explainer on who should own an AI agent in a business sets out the roles in more detail.

When should ownership move to operations?

At the point the agent is approved for production, and planned from the start. The production approval should name the operational owner, confirm they accept the agent's scope and evidence, and confirm they have approvers, queue capacity and a fallback if the agent is suspended. Our playbook on approving a new AI agent for production lists what that sign-off should cover.

Operations should be involved long before that. If the operational owner first sees the agent at the production gate, they are being asked to accept something they had no part in shaping. Pilots that stay with IT throughout tend to stall precisely here, as covered in our guide on moving an AI agent from pilot to production.

What does operational ownership look like in the first weeks?

Closer attention than usual. The operational owner reads the held queue daily, reviews a sample of the agent's allowed actions, watches reviewer edits and is ready to lower depth if something looks wrong. IT stands alongside, ready to fix configuration and supply data from the record. Our guide to running an AI agent's first week in production sets out a day-by-day plan.

After the first weeks, the rhythm settles into the operational routines covered elsewhere: daily queue review, weekly evidence checks, scheduled re-certification and quarterly reporting to risk.

Does this vary by market?

The principle holds everywhere, but local expectations shape how it is documented. Supervisors in many markets expect a named business owner for any process that affects customers, regardless of the technology used. In payments operations, for example, local scheme rules and central bank expectations shape what the owner must evidence. Our brief on agents for payments operations leaders in Nigeria shows how this looks under one market's rules.

What is the trade-off?

Operations teams have to learn new work. Owning an agent means reading evidence, setting depth and handling incidents of a kind they have not seen before. Some will need support, and some will need an agent operations lead to carry the daily load. IT may also resist handing over something it built and understands.

Leaving ownership with IT avoids that learning curve and creates a worse problem: an agent whose authority is managed by people who do not answer for its outcomes. For each agent in production, ask who would decide to narrow it if its decisions started going wrong. If the answer is someone in technology, move that decision to the business function that owns the process, with IT supporting. The deployment model this reflects is set out in our guide to deploying an AI agent: train, shadow, certify, widen.

Where Pryme fits

In Pryme, each agent has a named owner on its record, and capability owners in the business set the customer's own limits, name approvers and review Attest evidence before depth is widened. Technology teams manage connections and identity; the authority each agent holds is decided by the people who answer for the work.