Delegation Is a Design Material

Software now acts on people's behalf. It posts, pays, books, replies, and keeps working after they leave. How much it may do is not a property of the model; it is a design decision made from four materials: the level of autonomy each action gets, the preview that shows intent before the act, the record and undo that follow it, and the escalation that hands the work back.

The grant is the product

For most of the history of software, the person was present when it acted. A click started the action, a command named it, a confirmation dialog stood between the intent and the effect. Even the automations people relied on were narrow and authored by hand: a mail rule, a scheduled transfer, a recurring invoice. The person wrote the rule. The software followed it.

That arrangement has shifted. Systems now take a goal, choose their own steps, call tools across products, and keep going for minutes or hours, sometimes while the person who asked is asleep. The question that matters is no longer whether the system can do the work. It is what the system is allowed to do, and how the person knows what it did.

Delegation is the act of handing over authority for a piece of work while keeping the accountability for it. The person stays answerable. The system receives the right to act inside a boundary. Everything about the experience follows from how that boundary is drawn, shown, and enforced.

Most teams treat that boundary as a switch. A toggle labeled "auto." A mode called "agent." A setting buried three screens deep that either lets the system act or does not. A switch is easy to build and easy to demo. It is also the reason so many delegated features end the same way: the first visible mistake turns the switch off, and it stays off.

A switch gives the whole product one setting. It confirms every action or none. It keeps a log written for engineers, surfaces every stop as a failure, and lets authority drift with each release. A material gives each class of action its own level, sizes the preview to the consequence, keeps a history the person can read and undo, designs escalation as a handoff, and makes every grant explicit, visible, and revocable.

Treating delegation as a material means designing four things with the same care a team gives to layout or copy: the autonomy level of each action, the intent preview before it, the audit and undo after it, and the escalation that returns work to a person. None of them is new on its own. Together they decide whether people can grant a system authority on purpose, or only by accident.

Example: the controller asks for more

Return to the illustrative accounts-payable product. It is a teaching scenario, not a client case or a claim about measured results.

The product already prepares invoices for review. It extracts line items, validates totals against purchase orders, stages uncertain fields, routes exceptions with context, and processes the mailbox overnight with checkpoints and safe retries. A person still approves everything that touches the ledger or the bank.

The controller now asks for more: "Let it post the routine ones. And pay the small ones."

It sounds like one request. It is at least six grants, each with a different consequence, a different reach beyond the product, and a different answer to the question of what happens when the system is wrong. Follow that sentence through the four materials.

Autonomy is set per action, not per product

The idea that automation comes in levels is older than generative software. Human-factors research described automation as applying to four functions (acquiring information, analyzing it, selecting a decision or action, and carrying out the action), each of which can sit anywhere from fully manual to fully automatic.¹ A cockpit could automate the first two heavily and the last one barely. The point was never "how automated is the system." It was "how automated is each function, and what does that do to the person."

The same structure holds for agents. One recent framework describes five levels of agent autonomy by the role the person plays: operator, collaborator, consultant, approver, and observer.² Its central argument is the useful one for product work: autonomy is a design decision, separate from capability. A capable system can be held at a low level of autonomy because the product requires it to consult the person before acting.

Apply that to the controller's sentence. The invoice product does not get one level. Each class of action gets its own:

• Read and extract. The system acts without asking. Nothing leaves the product, and a wrong extraction can be redone.
• Code line items. The system acts and shows its work. Coding stays reversible until posting.
• Post routine invoices. The system posts overnight inside a standing grant: known supplier, matching purchase order and receipt, amount under the controller's threshold, open period. The controller sees the boundary before leaving and the record in the morning.
• Write to a supplier about a missing purchase order. The system drafts; a person sends. This grant reaches someone outside the company.
• Schedule a payment. The system prepares; a named approver releases.
• Change a supplier's bank details. Never delegated, whatever the evidence. The system escalates every time.

The person's role changes from row to row. For extraction they hardly appear: they see the result and can redo it. For routine postings they set the boundary and hear only about what falls outside it. For payments they approve each one. For bank details they do the work, and the system only assists. The framework assigns one level to a whole agent. A product that acts for someone needs a level for each class of action, several of them at once, and the design job is to make each level legible where it applies.

What sets the level is not how capable the model is. It is the consequence of a wrong action, how far that consequence reaches beyond the product, whether it can be undone, and the measured reliability on this class of case. High measured reliability does not raise the level of an action whose authority was never granted. Supplier bank changes stay outside every grant because the organization decided they should, and no amount of extraction accuracy changes that.

Levels also move. A grant should be able to grow on evidence and shrink on failure. Growth should be a decision the person makes, not drift that happens between releases. The product can support that decision: how many prepared postings were approved unchanged over the past quarter, which were corrected, and why. Shrinkage should be immediate and partial. Revoking payment authority should not also stop extraction.

Intent preview: show the plan before the act

A confirmation dialog asks, "Are you sure?" An intent preview answers a different question: "Here is what I am about to do." The first pushes the decision back onto the person with almost no information. The second gives them something they can check.

A useful preview states five things in the language of the domain:

1. the action, named as the person would name it
2. the scope: which items, how many, what total
3. the authority: which grant the action runs under
4. the consequence class: reversible, compensable, or final
5. what the system will not do

For the controller's routine postings, the preview arrives at the end of the day, before the overnight run: "Tonight I will post 38 invoices from 21 known suppliers to October, under your routine-posting grant. Each matches a purchase order and a receipt. Four are held for you: two price differences above tolerance, one new supplier, one possible duplicate. Anything that arrives overnight and falls outside the grant waits for you too. Postings can be reversed until the period closes. Nothing will be paid."

That preview is short because it is sized to the consequence. The 38 routine postings appear as one line. The four held invoices are the actual content. A preview that lists 38 identical rows and hides the four that matter is a confirmation dialog with more steps.

The failure mode is known. When a person has to approve many actions quickly, each approval gets less thought, and approval risks becoming a rubber stamp.³ The answer is not more confirmation. It is fewer, better previews: batch what is routine, surface what is exceptional, and reserve per-item approval for the actions whose consequence deserves it.

Previews also work across absence. When the person is present, the preview can show a specific action. When the person is about to leave, it has to show the boundary as well, because the system will meet cases nobody has seen yet. The published Agent Payments Protocol draws this line. In its human-present flow, the person approves the closed checkout and payment directly. In its human-not-present flow, the person approves a set of constraints in advance and the agent completes the purchase within them; when a merchant or credential provider reports a constraint it cannot resolve, the flow returns to the person for approval.⁴

The standing grant is a preview of the boundary. "Post routine invoices overnight" means nothing until the product shows what "routine" covers tonight: which suppliers, which amounts, which period, which exceptions it will leave untouched. A grant the person cannot read is not a grant.

Audit and undo: the record is a surface

After the act comes the question every delegated system eventually faces: "What did it do while I was away, and can I take it back?"

Engineering logs do not answer it. Logs are written for debugging, in the vocabulary of the system. An action history is written for the person, in the vocabulary of the work. Each entry records what happened, under which grant, on what evidence, what it changed downstream, and which undo class it belongs to. The more aware a person is of what an agent did, the easier it is to notice a mistake and intervene, during the work or after it.³

The history records actions and evidence. It does not replace them with a narrated rationale. A fluent paragraph explaining why the system posted an invoice is not provenance. The purchase order number, the receipt, the matched amount, and the grant it ran under are.

Undo needs the same precision. Three classes cover most delegated actions:

• Reversible. The product can withdraw the effect. A posting can be reversed while the period is open.
• Compensable. The effect cannot be withdrawn, but a second action can correct it. A payment that has settled needs a recovery request or a credit note.
• Final. Nothing restores the earlier state, and no second action repairs it. A message that quotes one supplier's prices to another can be followed by a correction, but the prices stay disclosed.

The history should show the class before anyone needs it, and the preview should have shown it before the act. A person who learns that an action was final only when they try to undo it has been misled twice.

Undo also needs scope. Undoing one posting is not enough when the grant itself turns out to be wrong. If the threshold was set too high last Tuesday, the controller needs to see and reverse everything that grant did since then, not hunt through 200 entries one at a time. The unit of undo should match the unit of delegation.

Where the record lives has changed too. Since January 2026, tools built on the Model Context Protocol can return interactive interfaces that render inside an AI host's conversation. The host runs them in a sandbox, can log every message between the interface and itself, and can require explicit approval for tool calls the interface starts.⁵ The preview your product designs may appear inside a host you do not control. The history may need to answer a question asked in someone else's conversation.

That pushes delegation below the screen. The grant, the preview, and the history have to exist as data the product owns and can render wherever the work is happening. A history that exists only on your settings page is invisible at the moment someone needs it.

Escalation: designing the handback

Escalation is the moment delegated work returns to a person. Most products treat it as an error state. It is the opposite: the point where the system's restraint becomes visible and useful.

At the level the autonomy framework calls approver, the person is involved only when the agent reaches a blocker it cannot resolve alone: a failure it cannot recover from, a credential it was never given, a consequential action that needs sign-off.² At that level, the blocker is most of the interface the person ever sees. It deserves the most design, not the least.

A designed escalation answers five questions.

What triggers it? The action falls outside the grant. The evidence conflicts. The case has no precedent. The budget in time, money, or tool calls has run out. The same correction has repeated. A third party has disputed something the system did.

Who receives it? Not always the person who made the grant. A price difference goes to the clerk who owns the supplier. A bank-detail change goes to whoever the company has made responsible for verifying it.

What comes with it? The source material, the steps already taken, the current state, what is on hold, and the decision needed, phrased as a choice rather than as a status.

What happens while it waits? The system holds the one invoice and continues with the rest, or it stops everything. Either can be right. The person should know which.

What happens if nobody answers? The default leans toward the safe side. An unanswered escalation should expire into a hold, not into an action.

Compare two messages. The first: "Something went wrong with invoice processing. Please review." The second: "Invoice 4471 arrived overnight from a known supplier and lists a new bank account. Bank changes are outside every grant, so the invoice and its payment are held. Last night's 38 routine postings went ahead. Verify the change with the supplier using the phone number already on file, then approve or reject it." The first hands the person a problem. The second hands them a decision.

Escalation also runs the other way. The person needs a way to escalate to the system: to halt a category of action without stopping everything, or to stop the whole run. Interruptibility belongs in the design from the start, both for one class of action, such as revoking payment authority, and for the agent as a whole.³ A stop control that only exists in an admin console is not a control the person has.

Delegation reaches people who never granted anything

The controller made the grant. The supplier did not.

Suppose the grant widens, and the system no longer only drafts supplier messages but sends them and handles the replies. The supplier is now dealing with an AI system acting for someone else. Since 2 August 2026, Article 50 of the EU AI Act requires providers of AI systems that interact directly with people to design them so those people are told they are interacting with an AI system, no later than the first interaction, unless it is obvious to a reasonably well-informed person.⁶ The European Commission names AI agents among the systems it has in mind.⁷

That obligation is a floor. It tells the supplier what they are talking to. It does not tell them on whose authority the message was sent, what the system is allowed to agree to, or how to reach a person who can overrule it. Those answers are design work, and they belong to the same grant the controller made. A delegated action that leaves a third party unable to find the accountable human has delegated the accountability as well, and that was never the system's to hold.

Where delegation fails

Delegation fails in two directions.

Under-delegation looks safe. The system asks about everything, the person approves everything, and nothing the system does ever earns a wider grant. The person becomes a clicker. Their attention goes to approving routine work, so it is spent before the exceptional case arrives. The product has all the cost of autonomy and none of the benefit.

Over-delegation looks efficient. Authority accumulates through defaults, release notes, and settings nobody revisits. The person no longer remembers what they granted. When the first serious mistake surfaces, nobody can say whether the system exceeded its authority or used exactly the authority it had. The usual response is to revoke everything, and the product loses the trust it spent months earning.

The most dangerous grant is the one nobody remembers making.

Both failures have the same cause: a grant that was never designed. The four materials are how a grant becomes designed. The level says what the system may do. The preview says what it is about to do. The history and undo say what it did and how to take it back. The escalation says when it stops and whom it asks.

Framework

Behavior Spec, with its delegation section

The Behavior Spec already holds most of what a delegated action needs. Its eight slots carry the authority, the consequences, the recovery, the visibility, the correction, and the backoff, and delegation changes what each of them has to answer. What it adds is the delegation section: two slots for the autonomy level of each class of action and the intent preview before it.

01 — Trigger

What makes the system eligible to act on its own, and which conditions must stop it?

For delegated work, the trigger includes the grant itself: who made it, when, for which class of action, and when it expires.

02 — Inputs

Which evidence does the action rely on, and how fresh and independent is it?

A standing grant runs on evidence the person never sees in the moment. The spec names it.

03 — Confidence

What measured reliability supports this level of autonomy for this class of action?

Reliability can justify a wider grant. It cannot replace one.

04 — System action

What does the system do for this class of action, and what does it leave untouched?

The delegation section sets the level. This slot says what the level means in practice: which postings, which messages, which payments.

05 — User control

What did the person grant, and how do they widen, narrow, pause, or revoke it?

Revoking one class of action leaves the others running.

06 — Visibility

What does the action history record, and where can the person read it?

The history is written in the vocabulary of the work and travels wherever the work is rendered.

07 — Correction

Is the action reversible, compensable, or final, and what is the unit of undo?

When a grant was wrong, the person undoes the grant's effects, not one entry at a time.

08 — Backoff

When does the system stop and hand the work back, to whom, with what attached, and what happens while it waits?

Escalation is the backoff slot designed as a handoff.

09 — Autonomy level

Which level does each class of action get: observe, prepare, act and show, or act and report? What evidence would widen or narrow it?

Name the level per action class, not per product.

10 — Intent preview

What does the person see before the act, or before they leave: the action, the scope, the grant it runs under, the consequence class, and what the system will not do?

Size the preview to the consequence. Routine work fits on one line; the exceptions are the content.

Footnotes

1. Parasuraman, R., Sheridan, T. B., & Wickens, C. D. (2000). A model for types and levels of human interaction with automation. IEEE Transactions on Systems, Man, and Cybernetics, Part A, 30(3), 286–297. doi.org/10.1109/3468.844354 ↩

2. Feng, K. J. K., McDonald, D. W., & Zhang, A. X. (2025). Levels of autonomy for AI agents. Knight First Amendment Institute; arXiv:2506.12469. arxiv.org/abs/2506.12469 ↩ ↩²

3. Shavit, Y., Agarwal, S., Brundage, M., et al. (2023). Practices for governing agentic AI systems. OpenAI white paper, sections 4.2 (approval), 4.4 (legibility of agent activity), and 4.7 (interruptibility). openai.com/index/practices-for-governing-agentic-ai-systems ↩ ↩² ↩³

4. Agent Payments Protocol (AP2) documentation, "Flow examples": human-present and human-not-present flows. Accessed 2 November 2026. ap2-protocol.org/ap2/flows ↩

5. MCP Core Maintainers (2026, January 26). MCP Apps: bringing UI capabilities to MCP clients. Model Context Protocol blog. blog.modelcontextprotocol.io/posts/2026-01-26-mcp-apps ↩

6. Regulation (EU) 2024/1689 (AI Act), Article 50(1) and 50(5); applies from 2 August 2026 under Article 113. Consolidated text, European Commission AI Act Service Desk. ai-act-service-desk.ec.europa.eu/en/ai-act/article-50 ↩

7. European Commission (2026, July 24). Transparency obligations under Article 50 of the AI Act. digital-strategy.ec.europa.eu/en/faqs/transparency-obligations-under-article-50-ai-act ↩