Who Is Accountable When an Approved Agent Output Turns Out Wrong

An agent drafted something, a person approved it, it went out, and it was wrong. Now three parties are looking at each other: the person who clicked approve, the manager who owns the process, and the company that sold you the software.

The workable split is this. The approver is accountable for what a reasonable person could have caught. The process owner is accountable for whether the review was possible at all. The vendor is accountable for the system behaving as described. Most disputes happen because nobody wrote that down before the incident.

The approver is not automatically at fault

The instinct after an error is to look at whoever approved it. It is the most visible action and the easiest to point at.

But an approval is only meaningful if the approver had what they needed. Ask three things before assigning blame there: did the screen show them the thing that was wrong, did they have the source information to check it against, and did they have time to look?

If a pricing error was buried in the twelfth field of a long form, or the approver was clearing sixty items in an hour, the failure is upstream of them. Holding an approver responsible for a check the system made impractical produces one outcome: people stop wanting to be named approvers, and you lose the control entirely.

What the approver is fairly accountable for is the obvious. A wrong recipient, a figure that contradicts something they know, an output that plainly does not match the request. If it was visible and checkable, that is theirs. Some of it should never have reached an approver at all, which is why it pays to settle what an agent should never be allowed to email before the workflow goes live.

The process owner carries the design

The process owner is whoever decided this workflow would run this way. They are accountable for the conditions the approver worked under.

That includes how much is presented for review at once, whether the riskiest information appears where someone will see it, whether volume is compatible with real attention, and which approval pattern the workflow should have been on in the first place, including whether it needed a hard stop rather than an approval.

It also includes escalation. If an approver had doubts and had nowhere to take them, that is a design gap. Every approval step needs a "send it back" path that costs the approver nothing socially, and the process owner owns whether that exists.

The vendor is accountable for the description

Vendor responsibility is narrower than people expect and worth being precise about.

A vendor is accountable for the system doing what the documentation says. If a control was described as blocking an action and did not block it, if permissions were described as scoped and were not, if output was described as requiring approval and something shipped without it, that is a product failure.

A vendor is not generally accountable for the content of a model's output being wrong, because that is the nature of the technology and every reputable supplier says so. Read your agreement rather than assuming, since terms differ, and check what it says about data handling and indemnity while you are in there.

Where a product is designed so a human approves agent output before it ships, as SicherOne is, the vendor's obligation is that the approval gate works and is recorded. Whether the human looked properly is not something a supplier can be responsible for.

Wording to settle it in advance

Put this in the workflow documentation, not in a policy nobody opens. Four sentences will do.

• Named approver. "Approval for this workflow sits with the person holding role X. Approval means they have checked the fields listed below against source." Then list the fields. Two or three, not fifteen.
• Process owner. "The owner of this workflow is Y. They are responsible for the review screen showing the listed fields, and for volume remaining within the stated limit."
• Volume limit. "If more than N items per day require approval, the workflow pauses and is redesigned." A number here prevents the slow slide into rubber stamping.
• Escalation. "An approver may return any item without explanation. Returns are recorded and reviewed monthly by the process owner."

That last one is the sentence that does the most work, because it makes refusing cheap.

Do the analysis before the blame

When something goes wrong, resist naming a responsible party in the first meeting. Establish instead what the approver saw, what they had to compare it against, and how many items they handled that day.

Those three facts usually make the split obvious without argument. They also produce the fix, which the blame conversation never does, and the fix often belonged much earlier, in testing the agent before it touched live records.

Accountability is not the same as fault

One distinction worth keeping. Accountability is about who answers for the outcome and who fixes the process. Fault is about whether someone behaved unreasonably.

You can be accountable without being at fault, and treating those as the same thing is why organisations end up with controls that everyone quietly avoids owning. Separate them clearly and people will still put their name against an approval, which is the only way any of this works.