The delegation scale

An AI operating on a user’s behalf: which actions can it perform alone, which with confirmation, and which can it not perform?

The question

Which actions can the system perform alone, which with confirmation, which can it not perform at all?

Why it is a decision

If the decision is not made consciously, the effect still gets determined by how the service was implemented: development decides case by case, with no shared scale.

This is not a passive omission. It is an implicit delegation of the scale to whoever implements the individual feature, who decides on local criteria and without an overall view — and who is not at fault, because nobody gave them a scale.

Blocking every action an AI agent could perform is a legitimate choice, but doing it without knowing is not.

What the literature says

• The three-step model is already in the corpus, with the example: “consulting the catalogue, yes; modifying an order, maybe; cancelling a contract, probably not”. The criteria for moving up a level are reversibility of the action, economic impact, presence of personal or third-party data.
• The architectural constraint: “a function reachable only by walking a hierarchy of menus is not delegable”. In practice, if a function cannot be reached directly, the agent cannot use it; so the delegation scale is not just a policy, it is a requirement on how functions are exposed.
• This card’s three-step model is a simplification of an older, more granular one. Parasuraman, Sheridan and Wickens (2000) propose ten levels of automation, applicable to four distinct functions — information acquisition, analysis, decision selection, action execution — not a single scale but four independent scales that can sit at different levels within the same system. The problem this delegation scale tries to solve also has an established name in the human-factors literature: trust calibration (Lee and See, 2004) — the gap between what an operator believes the system can do and what it can actually do. The two typical failures are misuse (too much trust: an automatic action gets accepted when it should have been checked) and disuse (too little trust: a reliable automation gets switched off). Both are observable with the same behavioural indicators this card proposes further down (cancellation rate, drop-off at confirmation points): they are the measurable symptoms of miscalibration, not standalone phenomena.

What each choice entails

Choosing a rigid approach. Limiting autonomous action prevents an agent’s action from becoming our problem without human confirmation. The cost is that every confirmation can become an exit point and make the system less useful than the expectation already observed.

Choosing a permissive approach. A wide margin makes delegation more convenient and lets the agent do more. Errors become ours without being contractualised: a booking can start on its own but be confirmed too late, or an order can be modified without a clear confirmation point.

Not deciding: the scale gets defined case by case by development, with no shared criteria. Abandonment can also become invisible, because there are no confirmation points left to observe.

Criterion for deciding

Define three levels — autonomous action, action with confirmation, prohibited action — using reversibility, economic impact, and the presence of personal or third-party data. Also verify that functions are exposed directly, because a function reachable only through a hierarchy of menus is not delegable.

The policy must become a verifiable product and engineering constraint: semantic markup, explicit states and labels, structured data, stable selectors and automated agent-task tests. The technical boundary includes sanitisation and prompt-injection protection, separation of agentic and human traffic, task success and an audit trail. Responsibility for authorisation, confirmation, logging and error response remains organisational; it cannot be left to an individual feature.

How it is measured

Cancellation rate after an automatic action: signals a scale that is too wide. Drop-off at confirmation points and share of users switching automation off after a trial: signal a scale that is too narrow, or badly positioned.

Who decides

Product Manager for the scale, Legal / Compliance for the irreversible, Service Designer for the confirmation points and recovery paths. Without the third, the first two produce a list of prohibitions, not a scale.

By when

Action logs, explicit confirmation on irreversible operations and escalation to a human operator are item 5 of the regulatory perimeter. On delegated payments the PSD3 framework is still being defined: there is no date, but there is a constraint.

Where it falls on roles

This is one decision that becomes work in different parts of the organisation. If it is not made, each part decides it independently, using local criteria.

• Leadership & Strategy — Owns the three levels and the agentic policy: permitted actions, authorised parties, responsibility, audit and exit conditions.
• Product & Design — Translates the scale into the interface: confirmation, cancellation, handoff to a person and safety signals. These are the trust-calibration responsibilities that in most teams have no declared owner (see Trust, AI literacy and calibration).
• Research & Information Architecture — Identifies the actions the service must expose; a function reachable only through a menu hierarchy is not delegable.
• Operations & Data — Measures cancellations, confirmation drop-off and automation deactivation, while separating agentic from human traffic.

Related phenomena

• The user expects the system to act — Creates the pressure that makes the constraint operational: only identifiable exposed actions can be delegated.
• Trust, AI literacy and calibration — Provides indicators for calibration.
• The regulatory perimeter — Sets the non-negotiable floor.