Delegation and User Control

Delegation is not a button labeled “go.” It is an agreement about what the system may decide, which resources it may use, which actions it may stage or commit, how long the work may continue, and when a person must be involved again.

Bad delegation creates two opposite failures. The system may act with hidden autonomy while the user thinks they are only receiving suggestions. Or it may ask for so many confirmations that the user approves without reading. Both failures remove meaningful control. One hides authority; the other exhausts attention.

Product design has to make delegation feel simple without making it vague. A user should not need to understand the whole agent harness, but they should be able to tell whether they are asking for advice, preparing work for review, authorizing a bounded action, or letting the system continue until an exception occurs.

Thesis

Delegation is usable only when the person can set the task, understand the control envelope, preview material effects, change or stop course, and recover authority without needing to inspect every low-value step.

Product & UX owns the person’s experience of control. Architecture owns the runtime approval, interruption, and handoff states. Security and governance own enforcement and accountability. A beautiful control that the system does not enforce is decoration.

The goal is not to maximize the number of controls. It is to place the right controls where the user has evidence, authority, and time to change the outcome.

Make the delegation contract visible

Before work begins, the user should be able to answer:

• What goal is the system pursuing?
• What counts as a successful result?
• Which resources, accounts, files, data, memories, and tools may it use?
• Which actions may it recommend, stage, or commit?
• How much time, money, compute, or external effort may it spend?
• Which events require approval?
• Which policy, safety, or eligibility limits apply?
• What will happen if the system is uncertain, blocked, late, or over budget?
• How can the user pause, cancel, edit, revoke, or take over?

Expose these as product controls, not policy prose hidden in settings. The interaction may be compact, but the contract cannot be imaginary. A task composer, side panel, command palette, or setup sheet can all work if they bind the same facts to the run.

A useful delegation contract has this shape:

Goal:
Scope:
Allowed resources:
Disallowed resources:
Action authority:
Approval triggers:
Budgets and deadlines:
Evidence expected:
Stop and handback rules:

For recurring or familiar tasks, the product can offer presets. Presets are safe only when they map to real authority and horizon differences:

Mode	Product meaning	Example
Advise	The system recommends; the user acts.	Draft a reply, suggest a plan, compare options.
Prepare	The system gathers and stages work for review.	Fill a form, prepare a pull request, assemble a report.
Execute bounded steps	The system may commit low-risk actions within explicit limits.	Update labels, schedule inside approved windows, close duplicate tickets.
Autopilot with exceptions	The system proceeds within a narrow claim and escalates anomalies.	Resolve eligible low-value refunds under policy.

The names can vary. The important mapping is to path discretion, action authority, operating horizon, and human involvement. Do not call a mode “review required” if the system can still send messages or update records without review. Do not call a mode “autopilot” if the next step requires a user click every minute.

Set goals in terms the system can check

Agentic products often accept natural-language goals. That is useful, but the system still needs structured success conditions. “Improve this deck” may be enough for brainstorming. It is weak for delegated work because neither the system nor the user can tell whether it is done.

Help users turn intent into checkable constraints:

User intent	Product should elicit
“Research this vendor”	Question, comparison criteria, allowed source types, freshness needs, required output format.
“Fix this bug”	Reproduction signal, affected area, test expectation, files or directories in scope, review boundary.
“Handle these tickets”	Eligibility policy, excluded customers, refund or credit threshold, escalation conditions.
“Clean up my calendar”	Calendar scope, meeting types, protected events, message approval, time zone behavior.

The product can infer defaults, but defaults should be visible where they matter. A hidden default is especially risky when it selects recipients, accounts, jurisdictions, memories, cost limits, or authority.

Make scope editable during work

Agentic tasks reveal missing constraints after they start. Good control lets users refine:

• the goal or success criteria;
• included and excluded sources, recipients, files, accounts, or actions;
• tone, format, schedule, priority, or depth;
• spending, time, token, or external-service budgets;
• approval thresholds;
• memories or preferences that should or should not apply;
• whether a partial result is enough; and
• whether the system should continue, narrow, pause, or stop.

Microsoft’s human-AI guidelines recommend supporting efficient correction and dismissal, cautious adaptation, and global controls (Amershi et al., 2019). For agents, correction must change the actual run state. Editing a chat message is not enough if the agent has already staged actions from the old instruction.

Show what a scope edit affects. If a user changes “send this today” to “prepare a draft only,” pending sends, approvals, timers, child runs, and delegated authority should visibly update or be cancelled. If a user excludes a data source, the system should say which claims or artifacts were based on it and whether they need regeneration.

Preview consequential actions

Before a material external effect, show a structured action preview. The preview should answer:

Action:
Target:
Data disclosed or changed:
Authority used:
Reason and evidence:
Policy or validation checks:
Reversibility or compensation:
Cost or deadline impact:
What changed since the last approval:
What happens if rejected:

The preview should come from structured state, not only from generated rationale. Untrusted retrieved content should not be allowed to write the target, amount, recipient, or policy result without validation. Generated explanation can help the user understand the action, but it is not the authority record.

WCAG 2.2 input-assistance criteria require error identification, suggestions, and prevention support for consequential submissions (W3C, 2023). Agent approvals are a similar moment: users need to review, correct, and confirm what will be submitted or changed. That includes keyboard access, accessible names, perceivable status, and error messages that do not rely only on color, animation, or position.

Use approvals sparingly and seriously

Approval is most useful when:

• the action is concrete and consequential;
• the reviewer has authority and enough evidence;
• the choice can still change the outcome;
• the system can bind approval to the reviewed action and state version;
• the action changed materially since the last approval; and
• the number of approvals does not train reflexive clicking.

Do not ask for approval of vague intent such as “let the agent continue” when the next effect is hidden. Conversely, do not interrupt every harmless read, formatting change, or low-risk draft step. Concentrate attention where consequence, irreversibility, uncertainty, novelty, policy, or user preference requires judgment.

OpenAI’s agent-building article treats human intervention as appropriate for high-risk actions and repeated failures (OpenAI, 2026). That engineering trigger needs a product ceremony: what the user sees, which choices are available, and what happens when they approve, reject, edit, or escalate.

Approval should never be confused with verification. A user may approve sending an email; the product still needs evidence that it was sent or not sent. A supervisor may approve a refund; the product still needs reconciliation with the payment system. A reviewer may approve a patch; the product still needs the repository state and test result.

Design attention, not just permission

Human attention is a scarce product resource. If every small step looks equally urgent, users learn not to read. A good delegation design filters attention by:

• consequence and reversibility;
• novelty relative to prior approvals;
• uncertainty or missing evidence;
• policy, security, privacy, or cost thresholds;
• user role and expertise;
• deadline and time sensitivity;
• whether the system can proceed safely without a response; and
• whether a partial result is now sufficient.

This makes approval design a quality problem, not a modal-dialog problem. Test whether users notice seeded errors in previews, not only whether they say they feel in control. Explanations can increase confidence without reducing overreliance; a 2024 empirical study found that AI explanations did not uniformly reduce reliance on incorrect recommendations (Cecil et al., 2024). The design needs evidence that the human-system process works.

Keep stop and revoke controls close

Users need visible ways to:

• pause new work;
• cancel the run;
• reject a proposed action;
• take over manually;
• revoke a tool, account, data source, or permission;
• clear, ignore, or correct a memory;
• reduce scope;
• export the current evidence;
• contact support or escalate; and
• close the task with a partial result.

Report cancellation honestly. “Stopping…” is not the same as “no effect occurred.” If a message was already sent, a write is in flight, or a payment outcome is unknown, say so and show the recovery path. A product that hides in-flight effects teaches users that stop controls are decorative.

Global controls matter too. Google’s People + AI Guidebook emphasizes feedback and control mechanisms so users can correct AI behavior over time (Google PAIR). Agentic products should make persistent settings, memories, connected accounts, automation rules, and default delegation modes discoverable without forcing users through one conversation.

Support several control styles

Different users need different control surfaces.

An expert developer may want a compact diff, command log, failing tests, and a fast reject path. A customer-service supervisor may need policy reason, customer impact, refund amount, audit trail, and escalation controls. A novice may need guided scope choices and plain-language consequences. An operator on call may need an override, timeline, effect status, and incident link.

Support both:

• guided controls for common safe paths;
• inspectable controls for expert review, audit, and exceptional cases; and
• administrative controls for organization-wide defaults, limits, and revocation.

Do not hide all advanced controls behind a transcript. Conversational correction is useful, but some actions need precise UI: checkboxes for resources, sliders or numeric fields for budgets, lists of accounts, diff viewers, approval tables, and clear disabled states. Product controls should be boring where precision matters.

Make control accessible and durable

Control must remain available across devices, sessions, assistive technologies, and interruptions. A delegated task that runs for hours cannot rely on a transient toast. Users should be able to return to a workspace, see what authority remains active, and change it.

Accessibility requirements include:

• controls reachable by keyboard;
• clear accessible names and roles;
• status updates exposed to assistive technology;
• error messages tied to the affected field or action;
• no reliance on color alone for risk or status;
• enough time to review where timeouts exist;
• confirmation for serious irreversible submissions; and
• alternatives to gestures or drag-only manipulation.

These are not separate polish tasks. If a user cannot perceive or operate a stop, approval, or correction control, the product does not provide meaningful control for that user.

Bind product controls to enforcement

Every user-facing control should have a corresponding system behavior:

Product control	Required system behavior
Draft only	Execution boundary rejects send, submit, publish, or write effects.
Exclude source	Context assembly and tool calls omit that source and invalidate derived claims.
Spend limit	Runtime budget prevents further paid work and reports partial state.
Approval required	Consequential action is staged until a bound approval exists.
Pause	New actions stop; timers, child tasks, and in-flight work enter explicit states.
Revoke account	Future tool calls fail closed or route to reauthorization.
Forget memory	Memory is removed or scoped out according to retention and deletion rules.

When the product cannot enforce a control fully, say what the limit is. For example, deleting a memory may not delete already exported artifacts or legally retained audit records. Cancelling a sent email cannot unsend it. The UI should not imply more control than the system can provide.

Failure modes

Hidden autonomy

The UI says “assistant,” but the system can change records, send messages, trigger child tasks, or continue for hours. Users cannot choose appropriate trust or supervision.

Approval fatigue

Every step requires a click. People approve automatically, and the one meaningful request receives no real scrutiny.

Abstract consent

The user grants broad access without seeing the specific action, target, data, authority, or consequence.

Unenforced control

The UI shows a mode such as “draft only,” but the execution boundary does not enforce it. A tool or child agent bypasses the product promise.

No graceful stop

The user cancels, but pending work continues invisibly. Late callbacks then change state after the user believed the work had stopped.

Correction as transcript

The user corrects scope in chat, but old pending actions, approvals, or child runs continue under the superseded instruction.

Expert-only control

The product technically exposes logs and settings, but intended users cannot understand or operate them at the moment of decision.

Fieldbook guidance

1. Make the delegation contract visible before work starts.
2. Offer modes that map to real authority and horizon differences.
3. Turn natural-language goals into checkable success conditions and constraints.
4. Let users edit scope and show the effects of edits.
5. Preview consequential actions with structured facts, not only generated rationale.
6. Use approvals where they can change outcomes; automate bounded low-risk steps.
7. Keep pause, cancel, take-over, revoke, and memory controls near the work.
8. Ensure UI controls are accessible and backed by execution-boundary enforcement.

Checklist

• Can the user see what goal, scope, tools, data, memories, authority, and horizon are delegated?
• Are delegation modes tied to real technical limits?
• Are goals converted into success criteria the system can check or ask about?
• Can users revise scope after work begins?
• Does the product show what a scope edit invalidates, cancels, or preserves?
• Are material actions previewed with target, data, authority, evidence, reversibility, policy status, and changed fields?
• Are approvals bound to the concrete action and state version reviewed?
• Are low-risk steps automated enough to avoid fatigue?
• Can users pause, cancel, take over, revoke access, and export evidence?
• Does cancellation report in-flight and unknown effects honestly?
• Are controls accessible and usable for the intended audience?
• Are product controls enforced outside the model?

References and how they are used

• Cecil et al., “The effects of AI explanations on human decision-making” - peer-reviewed evidence used to caution that approval and explanations must be evaluated as a human-system process.
• Google People + AI Research, “Feedback + Control” - Google People + AI Research design-resource chapter used for feedback, correction, control, and opt-out mechanisms; it is not a formal standard or independent control assurance.
• Microsoft Research, “Guidelines for Human-AI Interaction” - peer-reviewed human-AI interaction paper supporting invocation, dismissal, correction, global controls, uncertainty, and cautious adaptation.
• OpenAI, “A practical guide to building AI agents” - OpenAI product-adjacent agent-building article used for high-risk intervention, handoff, and practical agent control patterns.
• W3C, Web Content Accessibility Guidelines 2.2 - W3C Recommendation used for accessible input assistance, error prevention, status, and operable controls.