A lot of companies say they want AI agents.

What they usually mean is:

they want the work to happen faster, cheaper, and with less human drag.

Fair enough.

But once the conversation gets past the demo, an uglier question shows up:

who actually owns this thing?

Not who approved the budget. Not who joined the pilot call. Not who got excited in the strategy offsite.

Who owns:

  • the workflow definition
  • the success metric
  • the approval rules
  • the exception queue
  • the downstream damage when something goes sideways
  • the decision to expand, narrow, pause, or kill the system

That question gets skipped all the time. Then the agent goes live, something weird happens, and everybody discovers they bought automation without buying accountability.

That is how you end up with the classic modern operating model:

  • Ops thought Product owned it
  • Product thought IT owned it
  • IT thought the vendor owned it
  • the vendor thought the prompt was the product
  • Legal appears only after the interesting part
  • nobody owns the exception queue on Friday at 4:37 PM

That is not an AI strategy. That is a blame-routing system.

If you are rolling out AI agents, you need a real ownership model before you need a bigger model.

The first mistake: treating the agent like software instead of a workflow operator#

A lot of teams assign ownership the same way they assign ownership for software tools.

They think:

  • IT owns the system
  • Security signs off on access
  • the business team uses it
  • done

That might work for static software. It breaks for agents.

An AI agent is not just a tool sitting politely in the stack. It is a workflow actor. It makes decisions, triggers actions, routes work, creates records, drafts messages, updates systems, and pushes ambiguity into human queues.

That means ownership cannot stop at infrastructure. Somebody has to own the work behavior.

Not just:

  • uptime
  • auth
  • integrations
  • vendor contract

Also:

  • what jobs the agent is allowed to do
  • what “good enough” output means
  • what gets auto-approved versus escalated
  • what gets measured
  • what gets reviewed after failure

If nobody owns that layer, the system will still run. It will just run in the dumbest possible way.

There are really four kinds of ownership#

When people ask who owns an AI agent, they usually compress four different jobs into one vague answer.

That is the bug.

Split them.

1. Workflow ownership#

This is the person or team that owns the business process itself.

Examples:

  • RevOps owns lead routing
  • Support Ops owns ticket triage
  • Finance Ops owns invoice handling
  • Customer Success owns renewal prep

This owner decides:

  • what the workflow is for
  • what outcomes matter
  • what inputs are in scope
  • what counts as success or failure
  • what risks are acceptable

This should usually be the primary business owner. Not the vendor. Not the prompt engineer. Not the random executive who likes the phrase “agentic AI.”

If the workflow owner is unclear, the agent will optimize for noise.

2. System ownership#

This is the technical owner. Usually platform, engineering, IT, or whoever operates the infrastructure.

They own:

  • runtime health
  • integrations
  • secrets and credentials
  • deployment process
  • observability
  • rollback paths
  • access control
  • environment separation

This matters a lot. It is just not the same thing as workflow ownership.

A system can be technically healthy and still operationally stupid.

3. Exception ownership#

This is the one most teams forget. It is also the one that determines whether the agent is actually usable.

Exception ownership means:

who catches and clears the weird stuff?

Examples:

  • ambiguous inputs
  • policy conflicts
  • missing data
  • failed validations
  • external API mismatches
  • partial failures
  • high-risk actions needing approval

If you cannot answer who owns exceptions, you do not have an autonomous workflow. You have a mess generator with a dashboard.

A real exception owner needs:

  • clear queue visibility
  • response expectations
  • authority to resolve or reroute
  • a documented playbook
  • feedback loops into system improvement

If exceptions just “go to the team,” they go nowhere.

4. Outcome ownership#

This is the executive or functional owner who owns the business result.

Not the mechanism. The result.

Examples:

  • reduced handling cost
  • improved response time
  • higher throughput
  • lower error rate
  • faster collections
  • increased conversion rate

This owner decides whether the system is worth continuing. Because a lot of agents technically work while economically failing.

Someone has to be allowed to say:

  • this helped, expand it
  • this works only in a narrow lane, constrain it
  • this creates too much cleanup, kill it

Without outcome ownership, pilots drift into permanent maybe.

One person should not own everything#

That said, everybody owning a slice with no named lead is worse.

The practical model is:

  • one primary accountable owner for the workflow
  • one technical owner for system operation
  • one named exception path for human handling
  • one success metric owner for business review

Sometimes one person wears two hats. That is fine.

What is not fine is the fake matrix-org answer where six people are “involved” and none of them are actually on the hook.

If you need a blunt rule:

every production agent should have one human whose name belongs next to the workflow.

Not because that person does all the work. Because ambiguity needs a gravity well.

The minimum ownership map every agent needs#

Before rollout, write this down in plain English. No enterprise poetry.

1. What workflow does the agent own?#

Be specific.

Bad:

customer support automation

Better:

classify inbound billing tickets, draft replies for simple billing issues, and route refund, fraud, cancellation, and legal-adjacent cases to human review

If you cannot define the workflow boundary, ownership is already broken.

2. Who is the primary workflow owner?#

Use a name, not a department.

Bad:

Ops

Better:

Head of Support Operations

3. Who owns runtime/system health?#

Again: a name or clearly assigned function.

This owner is responsible for:

  • broken integrations
  • failed jobs
  • deployment errors
  • access problems
  • environment drift
  • missing observability

4. Who owns the exception queue?#

This one needs even more specificity.

Define:

  • where exceptions land
  • who reviews them
  • how fast they are expected to respond
  • what actions they are allowed to take
  • what gets escalated further

If the answer is “shared inbox” or “someone on the team will look,” you have built a future outage.

5. Who approves changes to behavior?#

Agents are not set-and-forget systems. Prompts change. Rules change. Thresholds change. Tool access changes. Scope expands.

You need a clear answer for who can approve:

  • new actions
  • wider scope
  • looser approval thresholds
  • new integrations
  • changes to escalation rules
  • higher-risk automation paths

If nobody owns change approval, behavior drifts through convenience. That always gets expensive.

6. Who owns the scorecard?#

Someone has to review:

  • throughput
  • exception rate
  • rework rate
  • false positives / false negatives
  • human review load
  • unit economics
  • customer impact

If no one owns the scorecard, the agent will survive on vibes long after it stops paying rent.

The exception queue is where ownership becomes real#

A lot of agent systems look competent on the happy path. That is easy.

The real test is what happens when the workflow hits uncertainty.

That is why I keep coming back to exceptions. Because the exception queue tells you whether the organization actually designed an operating model or just bought software optimism.

A healthy exception path has:

  • a known destination
  • a known owner
  • severity rules
  • response expectations
  • a way to push learnings back into the workflow

An unhealthy exception path sounds like this:

  • “we’ll monitor it manually for a while”
  • “the vendor is helping during the pilot”
  • “the ops team can probably review those”
  • “we haven’t really decided what counts as escalated yet”

That is not a path. That is a future Friday problem.

Ownership should change as the agent gets more autonomy#

A lot of teams freeze the ownership model from pilot to production. Bad idea.

As the agent gains scope, speed, or permission, the ownership model needs to tighten.

Here is the rough progression.

Stage 1: Shadow / assist mode#

The system drafts, classifies, recommends, or prepares actions. A human approves everything.

Ownership is simpler here. The workflow owner and the approving team can often be the same.

Stage 2: Bounded automation#

The system can auto-handle low-risk cases under clear rules. Exceptions escalate. Humans review edge cases and sampled outputs.

This is where exception ownership becomes mandatory. It is also where outcome ownership starts to matter, because now you can actually measure whether the automation is worth it.

Stage 3: Higher-volume / higher-trust automation#

The system touches more workflows, wider inputs, faster paths, or higher-value actions.

At this stage you need stronger change control around:

  • scope expansion
  • approval rules
  • rollback authority
  • audit review
  • incident response
  • business kill criteria

More autonomy with the same loose ownership model is just faster confusion.

The vendor should never be the real owner#

Vendors can support the system. They can help improve it. They can provide tooling, advice, and maybe even temporary managed service coverage.

They should not be the actual owner of your workflow.

Why?

Because the vendor does not own:

  • your margin
  • your customer relationships
  • your exception priorities
  • your internal tradeoffs
  • your political risk
  • your operational mess

They can help you automate it. They should not be the final authority over what risk is acceptable or what success means.

If the vendor is the only party who understands how the agent behaves, you did not buy capability. You rented dependency.

What good ownership sounds like#

Here is a healthy answer:

Support Operations owns the billing triage workflow. Platform Engineering owns runtime health and integrations. Billing Team Leads own escalated exceptions during business hours. The VP of Support owns the cost-per-ticket and response-time scorecard. Any expansion of auto-send authority requires approval from Support Ops and Platform.

That is boring. That is excellent.

Here is a bad answer:

We’re still figuring that out, but the vendor has been really helpful and everyone’s aligned on the vision.

That is corporate fan fiction.

A simple ownership checklist#

Before an AI agent touches production work, you should be able to answer yes to all of these:

  • Is there one named workflow owner?
  • Is there one named technical/system owner?
  • Is there a defined exception queue with a named human owner?
  • Is there a named owner for the business outcome or KPI?
  • Are change approvals defined?
  • Are escalation rules documented?
  • Is there authority to pause or narrow the workflow quickly?
  • Is there a review rhythm for performance and failures?

If not, you do not need a better model. You need a more adult operating model.

The practical rule#

If an AI agent can take action, then a human must own:

  • the workflow boundary
  • the exception path
  • the scorecard
  • the stop button

That is the job.

Everything else is just implementation detail.

The more companies understand this, the faster they stop buying “autonomy” as a fantasy and start deploying it as an operating system.

That is where the money is. Not in the loudest demo. In the team that can answer, without hesitation:

who owns the work when the AI is involved?

If you want help designing agent workflows with clear approvals, exception handling, and production-safe operating rules, talk to Erik MacKinnon.