Who is accountable when an AI agent does the work? Write four names for each agent.

When an AI agent does the work, a person is still accountable for the result. The company is accountable to the customer and to the law. Inside the company, one named person must answer for each agent task. Make this clear before the agent goes live. For each task that an agent does, write four names: who directs it, who reviews it, who controls its access and who owns the result. Leave no line blank.

This method comes from a simple idea in a short video from 2026. List each task that an AI does. Write four names beside it. Then ask: “If this AI made a costly mistake tomorrow, whose name would be on it?” If you cannot answer, you have an ownership gap.

Courts have already answered part of this question. In 2024, a Canadian tribunal decided that Air Canada was responsible for wrong information that its chatbot gave about a fare policy. The company argued that the chatbot was responsible for its own words. The tribunal did not accept this. The company is accountable. The question for you is: who inside the company?

Why is agent accountability different?

A normal software feature does what the code says. When it fails, you find the bug and the developer who owns that code.

An agent is different in three ways:

• It makes choices. The model selects which tool to call and with which input. The same request can lead to different actions.
• It acts on other systems. It sends email, changes records, creates orders or runs code.
• Its instructions come from many places. The prompt, the user, the documents that it reads and the results of tools. Some of these sources are not under your control.

For these reasons, “the engineering team owns it” is not a sufficient answer. Many people contribute to what an agent does. Each part needs an owner.

What are the four roles?

One person can have more than one role for a small agent. But each role must have a name. In a larger company, separate the “controls access” role from the others. The person who wants the agent to do more must not be the only person who decides what it can access.

How do I make the ownership list?

Follow these steps. For a company with a few agents, this takes less than one day.

1. List each agent. Include agents inside third-party tools, for example AI features in your CRM or ticket system that take actions.
2. List each task for each agent. A task is one type of action. For example: “reads incoming invoices,” “creates purchase orders,” “sends confirmation email to suppliers.”
3. Write the four names for each task. One person per role. Not a team, not a department.
4. Write the risk level for each task. Low, medium or high. High means money, customer communication, legal effect or data deletion.
5. Write the review method for each task. For low risk: weekly samples. For high risk: approval before each action.
6. Review the list with each named person. Each person must agree to the role.

Here is an example of the result:

What must the “controls access” person do?

This role is often missing. It is very important for agents.

• Give each agent its own credentials. Not a developer’s key, not a shared admin account.
• Give the minimum access. If the agent only reads orders, it cannot change them. One short video put it well: give your agent one key, not the whole key ring. An agent does whatever its access allows.
• Limit high-risk tools. Tools that send money, delete data or send external messages need extra limits or human approval.
• Review the access each quarter. Remove access that the agent no longer needs.
• Be able to stop the agent quickly. One switch that removes all access.

The prompt injection guide explains why access limits are the most important defense. An attacker can hide instructions in a document or an email that the agent reads. If the agent has limited access, the damage is limited too.

What must the “reviews” person do?

The review method depends on the risk.

Low risk: Read a random sample each week. Count the errors. Report the error rate to the result owner.

Medium risk: Read a daily report of all actions. Look at the unusual ones. Have a way to reverse an action.

High risk: Approve each action before it happens. The agent prepares, the human decides.

The reviewer must have the time to review. If the review takes more time than doing the task by hand, the design is wrong.

What must the “owns result” person do?

This person answers to management. The person:

• Knows the error rate and the cost of the agent.
• Decides to continue, change or stop the agent.
• Answers to customers or regulators when something goes wrong, with the help of the others.
• Reports the result each month.

This must be a manager with authority over the process. It must not be the engineer who built the agent.

What happens when something goes wrong?

Write an incident procedure for agents. It can be short.

1. Stop. The “controls access” person stops the agent or removes the access for the affected task.
2. Contain. The “reviews” person finds all affected actions in the logs. Reverse them where possible.
3. Inform. The “owns result” person informs management and, if necessary, customers.
4. Find the cause. The technical owner reads the traces. Was it the prompt, the data, a tool, an attack or a missing rule?
5. Fix and test. Add the case to the eval set. Fix the cause. Run the evals.
6. Restart. The “owns result” person approves the restart.

Without the four names, step 1 alone can take hours. People ask: “Who can turn it off?”

What logs make accountability possible?

Accountability needs evidence. Log these items for each agent action:

• The request: who or what started it.
• The instructions and the context that the agent had.
• Each tool call, with the input and the output.
• The final action and its result.
• The cost of the run.
• Any human approval, with the name of the person.

Keep these logs for the period that your policy or your regulator needs. The EU AI Act, for example, gives deployers of some AI systems obligations for monitoring and log retention.

What are the common mistakes?

Watch for these mistakes when you make the ownership list.

• A team instead of a name. “The data team reviews it” means nobody reviews it. Write one person. Add a backup person for holidays.
• The builder owns everything. The engineer who built the agent directs it, reviews it, controls its access and owns the result. This person cannot check their own work objectively, and has no authority over the business process.
• Owners who do not know. A name is on the list, but the person never agreed. Ask each person to confirm the role in writing.
• No review time. The reviewer has the role but no hours for it. Reviews stop after two weeks.
• The list is never updated. People leave or change jobs. Review the list each quarter and each time a person on it leaves.
• Only new agents. Old automations and AI features inside existing tools are not on the list. Include them.

How does this connect to regulation?

Regulators increasingly ask who is responsible for an AI system. For example, the EU AI Act gives obligations to deployers of high-risk AI systems. These obligations include human oversight by competent people, monitoring of operation and logs. Even when your agents are not high-risk under the law, the same structure helps. An auditor, a customer or a court will ask the same question: who was responsible, and what did they do?

The four-role list answers that question. The logs show what happened. Together, they show that the company had control.

How many companies have this today?

Few. A short video in 2026 cited a survey of executives and security staff. The survey said that more than 90% of companies had no named person accountable for what their AI agents do. The same survey said that fewer than half of agents were actively monitored. I did not verify these numbers. But they match what I see: companies add agents quickly and add owners later.

What about agents inside tools that I buy?

Many software products now include agents. Your CRM, your ticket system or your accounting tool can take actions with AI. These agents also need the four names.

For a third-party agent:

• Directs: the person who configures the feature.
• Reviews: a person in the team that uses it.
• Controls access: the admin of the tool, and the person who approves the vendor’s data access.
• Owns result: the manager of the process.

Read the vendor’s documentation. Find out which actions the agent can take, and turn off the ones that you do not need.

What about agents that call other agents?

Some systems use one agent to give work to other agents. This makes accountability more difficult. Each agent in the chain can add an error.

Keep these rules:

• Each agent in the chain has its own four names.
• The agent at the top has a limit on the total cost and the total number of actions.
• The logs show the full chain: which agent asked which agent to do what.
• High-risk actions need human approval, even when another agent asks for them.

Next step

Make the ownership list for your agents this week. Start with the agent that can take the most expensive action. If you cannot fill a line, do not expand that agent until you can. For monitoring, read how to monitor AI agents in production. For security, read how to protect agents against prompt injection. For help with the design of human approval steps, read the article on human-in-the-loop design bugs.