Who Is in Charge When an AI Agent Acts?

An operations agent reconciles exceptions across several systems overnight. It collects missing information, routes unusual cases and leaves prepared decisions for the morning team. At first, someone checks each step closely. As the workflow becomes familiar, the checks become quicker. A few months later, the team relies on the agent without thinking much about how the work is divided between its instructions, the connected systems and the people who approve the outcome.

Then an integration fails. The agent cannot complete its usual run, and the morning team has to work through the exceptions itself. It can see the cases but cannot easily reconstruct why some were routed, why others were set aside or which rule the agent applied last night.

This plausible scenario locates the governance question. When an agent performs part of a business process, who has given it authority, what exactly has been delegated, and can the organisation still understand and continue the work when the agent is unavailable?

Authority can accumulate inside a workflow

Most organisations know how to describe the authority of a person. A role has an owner, access rights, approval limits and an escalation path. Conventional software also tends to have a defined purpose and an accountable team, even when the documentation takes some finding.

An AI agent can blur these arrangements because its work crosses several of them. A customer-service agent might read a record, draft a reply and update a case. An operations agent might gather information from multiple systems before preparing a decision. The risk changes when it can alter an authoritative record, send a message to a customer or move money. Someone has delegated authority at that point, whether or not the organisation has described the change in those terms.

I would start with one real or planned deployment and put its authority on a page. What business outcome is it meant to support, and who owns that outcome? Which systems and data can it use? What may it do without a person, and where must it stop? How can its actions be reconstructed? Who can suspend or revoke its access?

The page is useful partly because people will disagree while completing it. The technical team may understand the permissions but have no mandate to own the customer outcome. The business owner may assume that a person reviews exceptions, while the workflow has quietly removed that step. Everyone may agree that the agent can be stopped until someone asks who can actually do it on a Sunday morning.

Those disagreements reveal decisions that were previously hidden inside an apparently smooth process.

A policy is only part of the instruction

Authority also depends on the rules the agent is expected to follow. Consider a policy requiring “appropriate approval” before an unusual payment is processed. An experienced employee may know which approver is meant, what evidence is sufficient and when Compliance should become involved. The sentence works because people supply several decisions around it.

Putting that policy into a retrieval system does not give an agent the same judgement. It may find the right paragraph while missing a later exception, using an outdated version or treating a discretionary judgement as a rule it can execute.

The agent needs an operating instruction tied to the authoritative policy. It should say what starts the task, which information may be used, what actions are permitted, what evidence must be retained and where a person must decide. The human policy still carries purpose, context and room for professional judgement. Its operational counterpart translates the parts that can be made explicit.

Maintaining both introduces work. If the policy changes while the agent instruction does not, staff may follow this quarter’s rule while the agent continues to apply last quarter’s interpretation. The link between them therefore needs an owner and a review whenever the source changes. Some ambiguity should remain a reason to escalate rather than an invitation for the agent to improvise.

This exercise can improve the human process too. It exposes assumptions that colleagues have carried informally for years: who “appropriate” means, why one exception is acceptable and another is not, and where a rule yields to judgement. An agent makes those gaps harder to ignore.

Continuity tests whether the organisation kept the capability

The overnight reconciliation example has another side. Suppose a supplier changes a service or the agent has to be withdrawn from a sensitive process. The team may be able to restart it quickly. That is a technical recovery test. The operational test is whether people can continue the work during its absence and supervise whatever replaces it.

We ask comparable questions about critical human roles: who can take over, where the knowledge sits and which access rights must change. The analogy has a firm limit. An agent has no legal responsibility or duty of care; those remain with people. It can still become operationally important as teams depend on it to prepare decisions, answer customers or move work between systems.

If the team has gradually stopped understanding the workflow, its data and its exceptions, a technical outage can expose a loss of organisational capability. A useful continuity review asks whether recent actions can be reconstructed, which knowledge and controls must remain within the organisation, who can take over, and how the work will proceed while a model, integration or supplier is replaced.

This does not require building every component in-house or keeping people busy repeating work that automation already performs. It requires a conscious decision about which capabilities the organisation cannot afford to surrender.

Keep the threshold proportionate

A reasonable objection is that this sounds like another governance ceremony. Local teams need room to experiment, and a small prototype should not wait for an enterprise committee to approve a page of boxes. Excessive control can prevent the organisation from learning anything useful.

The threshold should follow the consequences of the agent’s actions. A prototype working with test data and no external effects can be explored locally. Once an agent can affect customers, authoritative records, payments or material risk, its authority needs shared visibility. The map, policy link and continuity review should then be part of the decision to use it in routine operations.

Larger organisations will need common controls for identity, permissions, monitoring and lifecycle. A one-page map cannot provide those controls. It can reveal whether the design gives them something definite to control.

I would begin with an agent already close to production. Ask its business owner and technical team to complete the authority map together. Walk through one normal case, one exception and one failure. Check the policy source the agent uses, then stop the agent in a rehearsal and see what the team can still do. If the answers are unclear, the uncertainty belongs in the deployment decision before it becomes part of daily operations.

The aim is for delegated work to remain understandable. An agent can perform more of it as the technology improves, while people retain the ability to explain its authority, challenge its decisions and carry on when it is gone.