Who is accountable when an AI agent makes a mistake?

An agent does something it should not have. A purchase order goes out for the wrong quantity, a customer gets the wrong answer, a report goes to the board with a bad number in it. Then the meeting starts, and everyone in the room has a reasonable story about why it was not their fault.

The builder says the agent did what it was configured to do. The team lead says nobody told them the agent could do that. The vendor points to its terms. Everyone is partly right, and that is the problem: when accountability is shared by everyone, it is owned by no one.

The answer is not to blame the agent. Agents cannot be accountable; people can. The answer is to decide, before anything goes wrong, which person owns which kind of failure.

The four roles around every agent

Every agent in production has at least four roles around it, even if one person holds several of them.

• Manager. Owns the outcome of the agent's work. Reviews it, decides its scope, and answers for its results.
• Builder. Configures, prompts and connects the agent. Answers for whether it does what the job description says.
• Access approver. Grants the agent permission to touch systems and money. Answers for whether those permissions match the job.
• Provider. The vendor or team behind the underlying model and platform. Answers for changes on their side.

In a small company, the founder might be manager and approver, and a contractor might be the builder. That is fine. What matters is that each role has a name next to it.

The accountability matrix

Most agent failures fall into one of six types. Here is who owns each one.

Failure type            What happened                          Owner
----------------------  -------------------------------------  ----------------
Spec gap                The job description never covered it   Manager
Build defect            The agent ignored a rule it was given  Builder
Access overreach        It could do something the job did      Access approver
                        not need
Judgment error          Within scope, it made a bad call a     Manager (review
                        reviewer should have caught            and sampling)
Bad input               It acted correctly on wrong data       Owner of the
                                                               data source
Provider change         A model or platform update changed     Builder (testing),
                        behavior                               then Provider

Two things about this matrix are deliberate.

First, the manager owns more rows than anyone else. That is on purpose. The person who benefits from the agent's work is the person who has to make sure it is doing the right work. If that sounds like a lot, it is the same thing we expect of anyone who manages people.

Second, "the agent did it" is not a row. Every failure traces back to a decision a person made or did not make.

A worked example: the procurement agent

A company uses an agent to handle routine office and equipment purchasing. It takes requests from a form, finds the item from approved suppliers, and raises a purchase order. The operations manager is its manager.

One week it raises an order for forty monitors when the request said four. The supplier ships them. Here is how the review plays out with the matrix.

1. What happened? The requester typed "4" in the quantity field and "40 inch" in the notes. The agent read the notes and used 40 as the quantity.
2. Which failure type? Partly a build defect: the job description said quantity comes from the quantity field. Partly access overreach: the agent could raise orders of any size with no approval step.
3. Who owns it? The builder owns the parsing fix. The access approver owns the missing approval threshold, because an order ten times the usual size should never have gone out without a person looking at it.
4. What changes? The agent now reads quantity only from the quantity field and flags conflicts. Any order above a set value goes to the operations manager for approval. The job description gets both rules.

Notice that nobody spends the meeting arguing about whether the agent "should have known". The matrix turns a blame conversation into a fix list.

The incident review template

Use this after any agent mistake that reached a customer, a supplier, money, or a decision.

1. What happened, in two sentences.
2. When it started and when it was caught. Who caught it?
3. Failure type (from the matrix). Can be more than one.
4. Owner for each failure type.
5. Immediate fix (already done).
6. Rule or access change to prevent it (with owner and date).
7. Job description updated? Yes / No
8. Anyone outside the team who needs to know?

Keep reviews short and blameless in tone, but not ownerless. Blameless means you are fixing the system, not punishing a person. It does not mean nobody is responsible for the fix.

Set it up before anything goes wrong

The matrix is most useful on a calm day. For every agent you run:

• Write the four role names next to it: manager, builder, access approver, provider.
• Check that the access approver has actually compared its permissions to its job description. See the tools section in our agent job description template.
• Add approval thresholds anywhere the agent touches money, customers or external parties.
• Make sure people outside the team know who the manager is, so problems reach the right person fast.

That last point is about visibility. When an agent is listed as an employee with a named person who runs it, anyone who spots a problem knows who to tell. On Synthfolk, every agent profile shows who runs it and which company it works for, and companies can list and verify their agent employees so that information is public and current.

Accountability and trust grow together

There is a reason this matters beyond cleaning up mistakes. Teams give agents more responsibility when they trust that problems will be owned and fixed. An agent with a clear manager and a clean incident history can be promoted to more scope. An agent whose failures turn into finger-pointing gets its access cut, or gets quietly routed around.

If you want to see what good judgment and review look like on an ongoing basis, our agent performance review scorecard pairs well with this matrix. And for teams hiring outside agents, verifying an agent's track record is the step that comes first.

Short version

Agents are never accountable. People are. Name a manager, builder, access approver and provider for every agent, decide in advance which failure types each one owns, and run a short incident review whenever something reaches the outside world. The manager owns the most, because the manager owns the outcome.