Delegation transfers control and responsibility together; its boundary must be stated before the handoff

What it is

When a user hands a goal to an agentive system, they give up more than effort: the system gains control over the steps and takes over the position of responsibility for how the work is done. The delegation boundary—what it may touch, spending limits, permission for irreversible actions—must be visible before the handoff; explanations afterward cannot undo a responsibility transfer that already happened by default.

Why it happens

Delegation creates an authorization relation: the user surrenders control based on expectations about boundaries and capability, and the system acts freely within them. With a fuzzy boundary, users can neither anticipate risk nor distinguish "the goal was wrong" from "the agent overstepped," and accountability blurs. Once users discover unauthorized actions, the trust damage spreads to all later delegations.

Studying it

Experiments can manipulate when and how clearly the delegation is explained: permission list before delegation, revealed only after, or never stated—measuring authorization willingness, detection of overreach, and blame attribution. Log studies count user-initiated aborts of specific steps in real products to locate gaps between boundary expectations and system behavior.

Where it stops holding

"Stating the boundary" does not mean longer legal text: effectiveness depends on users actually reading and understanding it before delegating, and stacked disclaimers do not fix the responsibility structure. Boundaries can be wide for reversible actions; irreversible, other-affecting, or financial delegations need explicit permission. This concerns human-system delegation, not organizational role assignment.

Applying it

• Show a permission inventory at the delegation entry—data readable, operation types, spending or quantity caps—and require explicit confirmation before it takes effect.
• Make irreversible or externally consequential actions a separate permission, never bundled into the general grant.
• On overreach, halt immediately, roll back to the pre-delegation state, and report what crossed the line.
• In acceptance testing, simulate overreach scenarios and verify the system blocks them and users can state what the system may not do.

Related

• Same group: B4.16.1 In instrumental interaction the user controls each step; in agentive interaction the user delegates a goal · B4.16.2 The two modes demand different feedback: tools need immediate response, agents need visible process · B4.16.4 The two modes can coexist in one product, but switching should be the user's decision, not the system's · B4.16.5 Agentifying operations users could do directly removes space for skill expression
• Nearby: O3 Privacy and Authorization · L2 Trust and Transparency
• Search terms: delegation of control · authorization boundary · accountability