Method

Who does the work, who may decide, who answers for it?

A role name tells you little. The work, the decision rights and the answerability must be examined separately.

A framework for examining agent roles through responsibility, authority and accountability, grounded in organisational research and AI governance.

Kind

Editorial

Status

Working

Published

17 October 2026

Revised

27 October 2026

Reading time

About 5 min

Calling an agent a CFO does not tell you whether it compiles a report, recommends which bills to pay, approves the list or sends the money. These are different assignments. Split workflows when authority, external exposure or the consequences of error materially change. To understand an agent’s place in an organisation, start with the role’s purpose and examine the workflows where its authority changes.

This is my synthesis of the research behind this site. It is a way to document and compare delegation, not a validated scoring system or a claim of compliance. Where an agent stops is the picture of where authority sits in my company.

Three questions that must stay separate

These distinctions are my synthesis of organisational and governance research, not definitions attributed to a single author. The glossary gives the published sources for each term.

An agent can hold the first two: it can be given authority and the responsibility for a job. It cannot be given the accountability: a person answers for the outcome. The same person may hold several of these functions. Naming an agent responsible for preparing a report does not tell us who owns the subsequent decision. A human approval step alone does not tell us whether the reviewer has the information, time and ability to intervene.

A terminology trap in the research

Holacracy defines roles through purpose, domains and ongoing duties, which it calls “Accountabilities.” That use of the word concerns work the role must do. Here, accountability means answerability for decisions and outcomes. The Constitution also explicitly separates a domain from spending rights: the latter require a specific grant. We borrow the distinction between purpose, duties and authority without claiming that nullfte adopts Holacracy. Holacracy Constitution 5.0, Organizational Structure

1. Purpose and responsibility

State why the role exists, the ongoing work delegated, and what an acceptable output looks like. Identify who supplies its inputs and who relies on its output. A role that prepares a payment list depends on invoice records and feeds a payment process; it does not own the whole process merely because it produced one useful part.

Our organisational case research asks how much value a unit can deliver itself and how much coordination sits outside it. Apply that question to agents too. Record the handoffs rather than assuming that separate roles operate independently. Could downstream users detect an error? Where an output reaches a client, supplier or external adviser, record whether they know an agent was involved. Disclosure is a question to document here, not a claim that the same rule applies in every setting.

2. Authority, workflow by workflow

For each workflow, distinguish four areas:

• Information: what it may read or retrieve.
• Proposals: what it may prepare or recommend.
• Decisions: which choices it may make without further approval.
• Actions: what it may change or commit in an external system.

These are descriptive fields, not a ladder every agent should climb. For each, keep three records: the authorised scope, the technical capability, and what was actually observed. An instruction forbidding a payment differs from a credential that cannot initiate one. An action that did not occur tells us neither on its own.

Record the identity and credentials used: a separate agent account, a person’s account, or a shared one. For each workflow, record the exposure in amount or scope where known, how an error would be detected and how long that would take, and whether an action can be undone and by whom. Do not assume proposals are harmless or payments are always irreversible; examine the actual consequences and recovery route.

BCG’s harness proposal provides an implementation lens: scope, rules, context, review gates and a record of actions. Its design suggestions do not prove that a particular installation enforces its stated boundaries. BCG, Harness Engineering

3. Answerability and intervention

Identify the output reviewer, the owner of the decision, the executor and the owner of oversight. They may be different people or functions. Record who receives an escalation, can stop the workflow, and is responsible for correction. An unidentified owner is a gap in the account, not evidence that nobody owns the work.

NIST’s AI RMF calls for clear roles, communication and human-AI oversight arrangements. We use that guidance to ask who can intervene and answer for the process. This dossier does not determine legal liability, which depends on the relevant context. NIST AI RMF, GOVERN 2.1 and 3.2

4. Judgment and controls

Separate facts, estimates, assumptions and choices. The prediction-and-judgment literature distinguishes estimating an uncertain outcome from determining how desirable its consequences are. It does not establish a universal rule that machines predict and humans decide. Agrawal, Gans and Goldfarb

In cash-flow work, distinguish recorded transactions, invoice due dates, assumed settlement dates and scenarios. An invoice is not a guarantee of collection. A scenario conditional on late payment is not necessarily a probability forecast.

Record who sets objectives and trade-offs, what needs approval, how missing or conflicting information is handled, and how errors can be corrected. Examine both individual actions and their cumulative effects. A sequence of permitted choices can still conflict with the organisation’s purpose; checking individual limits is not enough to establish alignment.

5. Evidence, economics and changes

Record what was produced, checked, corrected, used and achieved. Keep reports of intended controls separate from evidence of controls working. A useful output, a changed decision and an improved outcome are three different findings.

Where measurements exist, include their period and definition. Count human review, exception handling, integration and coordination alongside model and tool costs. Leave unmeasured benefits unmeasured. Record when responsibilities or permissions change and why; more information access need not mean more decision authority.

A payment-list illustration

Illustration, not a report of an audited operation. Suppose an agent reads received invoices, identifies upcoming payments and proposes a list. It does not execute payments.

• Responsibility: prepare a proposed payment list. Completeness and correctness still need criteria and checking.
• Authority: reading and recommending are described. Approval rights, execution capability and the mechanism preventing unauthorised actions are not established by this description.
• Accountability: identify the decision owner and reviewer. Non-execution by the agent does not name them.
• Judgment: establish whether the list merely follows due dates or proposes priorities using assumptions about cash and consequences.
• Evidence: inspect a real list, corrections, the eventual decision and the actions that followed before claiming a result.

A founder report, not an illustration: The banks are blocking AI agents. I let one in. applies the three records to a bookkeeping agent in my own company, with the limits set in software between the agent and its key rather than in its instructions.

The framework makes the missing facts visible. It should help explain how work is organised, rather than turn a role title into a claim of autonomy.