Pattern 46
Autonomy has a visible boundary
Grant authority by capability and consequence rather than by personality.
Concrete takeaway
Name capabilities and limits.
Choose an approach
These are editorial decision conditions to validate. Some alternatives are successive states or can be combined; they are not always exclusive choices.
| Alternative | Use when | Tradeoff or requirement |
|---|---|---|
| A · Capability contract | The user grants capability-specific permission | Vague trust is not a permission model |
| B · Bounded run | A task is delegated within a defined scope | Limits and stopping conditions must be enforceable |
| C · Revoke and recover | The user revokes permission or stops a task | State and partial results need review and recovery |
The problem
A friendly agent can receive an ambiguous global permission that extends from drafting into sharing, scheduling or deleting.
The pattern
Name capabilities and limits. Distinguish advice, drafts, approved actions and bounded unattended work. State scope, expiry and stop conditions for standing authority; keep pause, revoke and available recovery visible.
Compare the alternatives
Grant authority by capability and consequence rather than by personality.
A · Capability contract
Users can see what is permitted.
B · Bounded run
A delegated task has enforceable limits.
C · Revoke and recover
A permission remains under user control.
Original wireframe proposals · No live controls · Grey rows represent schematic text, not loading states · Labelled placeholders are not Scripture quotations
Download this wireframe as SVGFailure modes
A single “trust me” switch; unenforced budgets; permissions expanding silently; a decorative stop button that does not stop execution.
Bible and faith considerations
Proactivity should not target grief, fear or private disclosures to increase dependence or sales.
What to validate
Test capability changes, expiry, budget exhaustion and revocation during a run. Compare the permission shown with actual tool and data access.
Research-informed design proposal. These visual alternatives have not been tested with users in this atlas. Source findings, documented behaviour and this proposed adaptation are different kinds of evidence.
Sources and adaptation
This card is an original design synthesis. The following sources inform its content distinctions, interaction approach or review requirements; they do not validate the whole pattern.
- Agentic UX PatternsPublished catalogue overview and example reviewed · The catalogue presents 49 proposals. Their inclusion is not evidence of effectiveness in faith or clinical settings.
- Control the level of automationPattern detail reviewed · Standing authority must be bounded and revocable.
- Suggest Confirm ExecutePattern detail reviewed · Approval thresholds depend on consequence and previously granted permissions.
- AI Interaction AtlasOfficial repository and taxonomy reviewed · A taxonomy, not a prescriptive UI framework. The official repository is available at https://github.com/quietloudlab/ai-interaction-atlas under Apache 2.0.
Common scenarios and flows
- Prepare and participate in an AI-assisted practice — Use bounded adaptation while keeping Scripture, authorship and user choice inspectable.
Design principles in this decision
Editorial application of Missional by Design. These values frame review questions; they do not validate a pattern’s effectiveness.
- Reverence — What does this interaction ask of the person, and can they understand, decline, correct or leave it without penalty?
- Costliness — Who pays for this convenience through time, labour, privacy, risk or exclusion, and can the organisation support its promise?
Compare alternatives using the task and evidence above. Record competing needs instead of treating a principle as an automatic verdict.