Who Owns a Process You Run With an Agent?

An insurer paid a claim it should never have paid. The agent had pre-approved the case with the full file attached; the person who signed the final approval checked the amount, not the cause. When risk asked who had decided to pay that claim, IT said the agent only recommends, operations said the person signs whatever lands on their desk, and nobody else wanted to answer.

Carlos Andrés Ramírez · 2026-09-18

An insurer paid a claim it should never have paid. The agent had pre-approved the case with the full file attached; the person who signed the final approval checked the amount, not the cause. When risk asked who had decided to pay that claim, IT said the agent only recommends, operations said the person signs whatever lands on their desk, and nobody else wanted to answer.

The same thing happens in contract review, credit approval, screening candidates before an interview: any process where an agent runs the first pass and a person signs at the end. Nobody cares who owns the process while it works. The problem shows up the day something goes wrong and someone needs a name with authority over the whole result, not just their own stretch of it.

The instinct is to split responsibility by function: IT owns the agent, the business owns the final call. It reads clean on an org chart and says nothing about the real process, because the process does not live inside one function. It lives in the handoff between the two, and that handoff is exactly the point nobody ever named as anyone's property.

The symptom

Who owns a process when a person and an AI agent run it together?

Most companies answer that the process belongs to the person, because the person signs it. That answer worked when the person did the whole job and the signature summarized a decision already made. It stops working the moment the signature turns into a formality on top of work someone else, the agent, already did almost entirely. Signing is not the same as deciding, and confusing the two is what leaves a process without a real owner the day someone has to explain what happened.

• The agent builds the full case and the person checks only the final number, without looking at the cause again.
• When something goes wrong, IT says the agent only recommends and the business says it only signs what lands on its desk.
• Nobody wrote down, before splitting the work, exactly where the agent's part ends and the person's part starts.
• Two people on the same team describe the process with different owners, and neither of them is entirely wrong.
• The process manual describes what the work looked like before the agent arrived, and nobody updated it once who did what changed.

The problem underneath

The process has a handoff. Ownership doesn't.

A process shared between a person and an agent is not a process with an owner and a helper. It is a process with a handoff point, the exact moment work passes from one to the other, and that point almost never shows up in any document. It got decided technically, whoever configured the system's workflow, but never organizationally: who answers for the full result if the handoff fails.

And it fails in ways that don't look like an agent mistake. The agent does exactly what it was asked to do. The person reviews exactly what the process puts in front of them. The failure lives in the middle, in the part nobody designed on purpose: what happens when the agent hands over something ambiguous and the person approves it out of habit, not because they actually checked it.

A process without an owner isn't a process without errors. It's a process where the error takes longer to find whoever has to fix it.

BECOME

The framework

What does a shared process need to have a real owner?

The pieces below get defined before splitting a process between a person and an agent, not after a case goes wrong and someone asks who was answering for it.

Named owner, not inherited

The process has one named person with a title responsible for the whole result, not "the team" or "the department." That person answers even when the agent ran most of the work.

Written handoff point

The exact moment work passes from the agent to the person, or back, is described in a document anyone can read, not just configured somewhere inside the system.

Record of who decided what

Every case gets tagged with what the agent decided, what the person decided, and whether the person approved the agent's proposal without changing it. Without that record, nobody can reconstruct afterward what happened.

Tie-break rule set in advance

When the agent and the person disagree, it is already written down who has the final word. Deciding it in the moment is exactly why two people describe the same process with different owners.

Accountable for the failure, not just the result

The process owner also answers when something goes wrong weeks later, not only when the number looks good on the day someone checks the dashboard.

None of the five pieces require redesigning the process or distrusting the agent. They require someone with authority to sit down with the full map of the process and decide, before it happens again, at exactly which step they start answering for the result.

Take a process a person and an agent currently run together, and ask who owns it. If the answer is "the team" or "it depends on the case," that process has no owner. It has two functions splitting the work, and neither one answers for the whole.

Let's define who owns your shared process