Who Owns the AI Agent Inside Your Company?

Who should own an AI agent? Not one person. Three roles: a business owner for outcomes, a technical owner for uptime, and a risk reviewer.

Add an on-call rule and a one-page role description, and the agent has a home. Skip them, and it slowly rots.

Here is how I’d set it up, and what each person does each week.

Why Agents Without Owners Decay

An agent is not a project you finish. It is a system that runs against data, tools, and rules that keep changing.

Google researchers flagged this for machine learning systems years ago. In Hidden Technical Debt in Machine Learning Systems, they found it is common to incur massive ongoing maintenance costs in real-world ML systems. That paper is from 2015. Agents built on language models add more moving parts: prompts, models, tools, and permissions.

Here is how decay looks without an owner:

A model update shifts answers. No one notices for weeks.
A policy changes. The agent keeps following the old one.
Users stop trusting the output and quietly go back to the manual process.
The person who built it moves teams, and nobody knows how it works.

Frameworks say the same thing. The NIST AI Risk Management Framework says roles, responsibilities, and lines of communication for managing AI risk should be documented and clear to individuals and teams throughout the organization. It also says executive leadership should take responsibility for decisions about AI risk. And it expects post-deployment monitoring that covers incident response, recovery, and change management.

McKinsey’s 2025 survey adds a business angle. Of 25 attributes tested, redesigning workflows had the biggest effect on seeing bottom-line impact from gen AI. The survey also found that CEO oversight of AI governance was among the elements most correlated with higher self-reported impact. Someone has to own the workflow, not just the model.

This is the work I describe in AI agent maintenance after deploy. The question here is who does it.

Business Owner

The business owner is accountable for the result. They own the number the agent was built to move.

What does an agent product owner do? In practice, the job is small and steady:

Owns the hero metric. Time saved, error rate, cost per case, or revenue protected. See the KPIs a COO should review weekly.
Owns the workflow. If the process changes, they decide how the agent changes.
Owns the golden set. They make sure the test cases reflect real work. My post on AI agent evaluation explains why.
Reviews a weekly sample. They read real runs and mark them good or bad.
Decides on autonomy. They approve moving from “suggest” to “act”, and moving back.
Handles people. They train users, collect feedback, and tell the team what changed.

Pick someone who runs the process today and has authority over it. A team lead, an operations manager, or a process owner. Do not pick someone from IT just because the project was technical. If the business owner is not the person whose numbers improve, nobody will fight for the agent.

My estimate: a few hours a week for one agent in steady state, more in the first month. That is a guess, not a measured figure.

Technical Owner

The technical owner keeps the agent running and safe to change.

Uptime and performance. Latency, error rates, tool failures, queue backlogs.
Change control. Every change to a prompt, model, or tool goes through review and a test run before release.
Cost. Tracks model and infrastructure spend against the budget.
Integrations. Fixes broken connections and rotates credentials.
Logs and rollback. Every run can be replayed and audited, and the last good version can be restored fast.
Runbooks. Writes down how to diagnose and fix the usual failures.

The technical owner is usually an engineer, platform lead, or a vendor engineer under contract. If a vendor runs the agent, you still need a named person on your side who can read the logs and ask hard questions.

A note on forward deployed engineers

You will see “forward deployed engineer” in job posts. Gergely Orosz, in the Pragmatic Engineer, describes the role as a software engineer who alternates between embedding with customer teams and working on the core product, a role pioneered by Palantir. It mixes implementation, integration, and customer success.

That is a builder-side role. It helps you get an agent live. It does not replace your owners, because when the engagement ends the agent still needs a business owner and a technical owner inside your company.

Risk Reviewer

The risk reviewer asks “should this agent do that?” and has the authority to say no.

This role sits outside the team that built the agent. It might be someone from security, compliance, legal, or internal audit. For a small company, it can be an outside advisor who reviews quarterly.

They:

Review the agent’s permissions, data access, and autonomy level.
Approve high-risk changes, such as new tools that write to systems.
Check logs and audit trails on a schedule.
Own the review of incidents and near misses.
Confirm the agent follows your policies and laws that apply to you.

On the legal side, the EU AI Act’s Article 26 says deployers of high-risk systems must assign human oversight to natural persons who have the necessary competence, training, and authority, and must keep the automatically generated logs for at least six months. Whether your agent counts as high-risk is a question for counsel. Even where the law does not apply, the principle is sound: a named, trained person with real authority.

Keep this role separate from the builder. People rarely find fault with their own work. For a tiered approach to how much review each agent needs, see AI governance in practice.

On-Call and Escalation

Who is on call? Someone must be, and everyone must know who.

Google’s SRE book on being on call is a good model. It describes primary and secondary rotations, where the secondary can catch pages the primary misses. It gives typical response targets of 5 minutes for user-facing or highly time-critical services and 30 minutes for less time-sensitive systems. It also warns about load: its guidance is a maximum of two incidents per 12-hour shift, so people have time to handle each one well.

Most business agents do not need Google-style rotations. Match the on-call model to the workflow. Here is a table with my starting points. They are my opinion, not a standard.

Agent type	Example	On-call model	Response target
Internal, batch, low risk	Nightly report summaries	Business hours, technical owner	Next business day
Internal, daily operations	Invoice coding, ticket triage	Business hours, primary and backup	1 to 4 hours
Customer-facing or money-moving	Refunds, payments, claims	Extended hours or 24/7, primary and secondary	15 to 30 minutes
Regulated or safety-related	Eligibility, clinical admin	24/7 plus risk reviewer on call	Defined in policy

Write the escalation path on one page:

Who gets the alert first. Name and backup.
What triggers a page. Error spike, a policy breach, a wrong action, a data exposure.
Who can stop the agent. Anyone on the list should be able to pause it without asking. Pair this with an incident response runbook.
Who tells the business. Usually the business owner.
Who reviews afterward. The risk reviewer, within a set number of days.

Test the path with a drill: someone pauses the agent and the team practices the handoff to the manual process.

Team Size by Agent Count

How big should the team be? It depends on how many agents you run, how risky they are, and whether you have a platform in place.

Here are my rough starting points. They are guesses to adjust, not benchmarks.

Agents in production	Business owners	Technical owners	Risk review
1	1 named person, part time	1 named person plus a backup	Quarterly review by a named person
2 to 5	One per workflow	1 to 2 engineers shared across agents	A standing monthly review
6 to 20	One per workflow	A small platform team of 3 to 5, handling shared tooling and on-call	A governance group with a regular meeting
20 or more	One per workflow	A platform team, plus agent-specific engineers	A formal governance function

Two cautions. First, on-call math is hard for small teams. The SRE book says that with a primary and a secondary always on call, on weekly shifts, a single-site team needs at least eight engineers so each is on call one week a month. You likely will not have eight. Cut the hours you cover, or buy coverage, instead of burning out two people.

Second, one person should never hold all three roles. The builder, the approver, and the reviewer cannot be the same person.

Where does the agent live in the org chart?

Three common choices:

In the business unit that owns the workflow. Best for accountability. The technical owner is a dotted line to IT or a platform team.
In a central AI or platform team. Best for consistency and shared tooling. The risk is distance from the work.
A hybrid. The business owns outcomes. A central team owns tooling, standards, and on-call. This is what I recommend for most companies with more than a few agents.

Whatever you pick, the business owner reports to the person who answers for the workflow’s results. The agent is not an IT asset. It is part of how the work gets done.

One-Page Role Description

Use this as a starting point. Copy it into your wiki and fill in the names.

Agent name: ____________ Workflow: ____________ Live since: ____________

Business owner: ____________ (backup: ____________)

Accountable for the hero metric: ____________
Reviews a sample of runs weekly and records pass or fail
Approves changes to the workflow, scope, and autonomy level
Maintains the golden test set with the technical owner
Reports results to: ____________ monthly

Technical owner: ____________ (backup: ____________)

Accountable for uptime, latency, and cost against targets
Runs change control for prompts, models, tools, and permissions
Keeps logs, traces, and the rollback path working
Maintains runbooks and responds to alerts inside the agreed window
Reports incidents to the business owner within: ____________

Risk reviewer: ____________

Reviews permissions, data access, and autonomy quarterly
Approves high-risk changes before release
Reviews every incident and near miss within ____________ days
Can pause the agent

On-call: ____________ primary, ____________ secondary. Hours: ____________. Response target: ____________. Who can stop the agent: ____________ Review date: ____________

For the wider path from pilot to production, where I think ownership is usually the missing piece, see getting from experimentation to production.

Bottom Line

Name three owners for every production agent: a business owner for results, a technical owner for uptime, and a risk reviewer who can say no.

Set on-call hours that match the risk, write the escalation path on one page, and make sure someone can pause the agent without asking permission.

Next step: pick one live agent and fill in the one-page role description this week. If you cannot fill in the names, you just found your biggest risk.

FAQ

Who should own an AI agent? Three people share ownership. A business owner is accountable for the outcome, a technical owner for uptime and change control, and a risk reviewer for safety and policy. For a very small internal agent, one person can hold both the business and technical roles. The risk reviewer should stay independent.

What does an agent product owner do? They own the metric the agent was built to move and the workflow around it. They review a weekly sample of runs, keep the test set current, approve changes to scope and autonomy, and train and listen to users.

Who is on call? The technical owner and a backup, with hours that match the agent’s risk. A nightly internal report may need only business-hours cover. A refund or payment agent may need extended hours and a 15 to 30 minute response target. Everyone on the list should be able to pause the agent.

How big should the team be? For one agent, a part-time business owner and a technical owner with a backup is enough. At 6 to 20 agents, plan a small platform team of roughly 3 to 5 people. These are my estimates, so adjust them to your risk and volume.

Where does the agent live in the org chart? Put outcomes in the business unit that owns the workflow. Put shared tooling, standards, and on-call in a central platform team if you have one. The business owner answers for results, so the agent should not sit only in IT.

Is a forward deployed engineer the agent owner? No. A forward deployed engineer is a builder-side role that embeds with your team to get something live. When they leave, you still need your own business and technical owners.

Three Ways to Work With TMA

Need an agent built? We deploy production AI agents in your infrastructure. Working pilot. Real data. Measurable ROI. → Schedule Demo

Want to co-build a product? We’re not a dev agency. We’re co-builders. Shared cost. Shared upside. → Partner with Us

Want to join the Guild? Ship pilots, earn bounties, share profit. Community + equity + path to exit. → Become an AI Architect

Who Owns the AI Agent Inside Your Company? Roles and On-Call