Agentic UX
A framework of patterns for designing AI agents that act on behalf of users.
The 7 territories

Assistants answered questions. Agents take actions. The design problems are categorically different: the cost of a wrong answer is embarrassment; the cost of a wrong action is a deleted file, an unwanted charge, or a misrouted customer email.
This framework is the vocabulary for that shift. It defines 36 patterns across 7 territories, each organized around a core question you have to answer before you ship an agent: What can it touch? How do we undo it? How autonomous should it be? What does it cost? Who hands off to whom? When is it listening? And how do we trust what it claims to have done?
Use this as a reference when you scope a new agent surface, review a PR that introduces one, or write a spec for a team that builds them. Every pattern has a definition, a likely anti-pattern, and, where they exist, links into the main pattern catalog for deeper treatment.
Seven questions to answer before you ship
- 01What can the agent touch?→ Permission & consent
- 02How do we undo it?→ Reversibility & rollback
- 03How autonomous should it be?→ Autonomy gradient
- 04What does it cost?→ Cost, latency & budget
- 05Who hands off to whom?→ Cross-app handoffs
- 06When is it listening?→ Ambient & voice agents
- 07How do we trust what happened?→ Trust scaffolding & provenance
Permission & consent#
What can the agent touch, and for how long?
Before an agent acts, it needs a durable, legible answer to what it is allowed to do. The design goal is informed consent that the user can revisit, not a one-time modal buried in onboarding.
Scope disclosure#
in catalog ↗An explicit, plain-language description of which resources, accounts, and actions the agent can reach. Shown at enrollment and on demand inside the surface, not only in a legal document.
When to use
Any time an agent gains a new capability, API key, OAuth token, or file-system access.
Anti-pattern
Blanket "read and write your data" consent screens that bundle dozens of unrelated permissions.
Duration-bound consent#
in catalog ↗Permissions that expire by default (an hour, a day, a session) rather than persisting until explicitly revoked. Users re-authorize on a visible cadence.
Example behaviors
- •Agent permissions expire automatically after a session or short time window and require explicit re-approval before the next high-impact run.
- •When consent nears expiration, the interface surfaces a clear re-auth prompt instead of silently refreshing long-lived access.
- •Temporary grants are scoped to one workflow so standing permissions do not accumulate invisibly over time.
Anti-pattern
Tokens that live forever once granted and silently refresh in the background.
Granular consent#
in catalog ↗Per-capability toggles (read email vs. send email; view calendar vs. book calendar) instead of all-or-nothing grants. Each capability can be revoked independently.
Anti-pattern
Coarse role-based grants that require re-authorizing everything to remove one dangerous capability.
Permission drift indicator#
in catalog ↗A surface that reminds the user which permissions the agent currently holds and when they were last reviewed. Prevents grants from accumulating invisibly over months.
Anti-pattern
Hidden "connected apps" settings pages with no prompts to audit.
Sandbox preview#
A dry-run mode that shows exactly what the agent would do (files touched, emails drafted, calls made) before granting real execution rights. The user promotes from preview to execute.
When to use
First-time use of a new agent capability or after a plan changes materially.
Anti-pattern
Click-through confirmations that describe the action in vague language.
Revocation affordances#
One-click revoke, visible in the same surface where consent was granted. Revocation should be at least as easy as granting, ideally easier.
Anti-pattern
Revocation buried three settings pages deep with a required "are you sure" chain.
Reversibility & rollback#
When the agent is wrong, how do we undo it, and how fast?
The defining property of an agent is that it changes the world. Reversibility is the fundamental safety net. Design the undo before you design the action.
Reversibility marking#
in catalog ↗Every proposed action is labeled by how easily it can be undone: fully reversible (draft), partially (DB row with a backup), or not (sent email, charged card). Users see this before approving.
Anti-pattern
Actions presented as uniformly "safe" when some are irreversible.
Action trail#
A chronological, human-readable log of everything the agent did, with the ability to inspect inputs, outputs, and side effects for each step. The trail is the primary debugging surface.
Blast-radius visualization#
A compact preview of how many records, files, or users a proposed action would affect. The user sees "will rename 412 files across 37 folders" before approving.
When to use
Bulk actions, schema changes, permission changes, or anything fan-out shaped.
Anti-pattern
A progress bar that only shows scope after execution has begun.
Checkpoints and restore#
in catalog ↗Named snapshots before significant actions, with a visible restore button. Works whether the state lives in the app, a codebase, or an external API with a supported undo window.
Example behaviors
- •Before multi-step execution, the system creates a named restore point users can roll back to if the outcome is incorrect.
- •Checkpoint history is visible and restorable from the same execution surface, not buried in separate settings.
- •Each checkpoint is tied to a specific plan run so users can compare before and after states quickly.
Time-delayed execution#
in catalog ↗High-impact actions run on a delay (5s, 30s, 5 min) during which a single click cancels. Trades a moment of latency for a wide margin of user control.
Example behaviors
- •High-impact actions enter a short pending window where users can cancel before changes are committed externally.
- •The interface shows a countdown and a one-click cancel action, making reversibility obvious in the moment.
- •Delayed execution defaults to risky action classes, while low-risk actions can execute immediately.
Anti-pattern
Irreversible actions that commit the instant the user clicks.
Readable action diffs#
Proposed changes rendered as a diff the user can read line-by-line (for text, for settings, for database rows), not just described in prose.
Autonomy gradient#
How independently should the agent act, and who decides?
Autonomy is not a binary. It is a slider, and the slider position should be visible, adjustable, and different for different actions. A well-designed agent gives the user language and controls for the gradient.
Suggest / confirm / execute#
in catalog ↗Three discrete modes, chosen per task or per session: the agent suggests only, confirms each step, or executes end-to-end. The mode is always visible and one click to change.
Anti-pattern
Implicit autonomy that varies by feature without the user knowing the rules.
Per-action autonomy#
in catalog ↗Autonomy set at the capability level, not the app level: auto-send drafts to known contacts but require approval for new ones; auto-commit to feature branches but never to main.
Autonomous mode display#
in catalog ↗A persistent indicator (color, badge, ambient shape) that makes it unmistakable when the agent is acting without asking. Users should never discover autonomy by accident.
Anti-pattern
A single small icon change as the only signal that the agent is now running unattended.
Escalation thresholds#
Rules that auto-demote autonomy when risk crosses a line: dollar amount, user impact, novelty. Crossing the threshold hands control back to the human before execution.
Autonomy budgets#
in catalog ↗Time- or action-count-bounded grants of autonomy: "run unattended for 30 minutes or 50 actions, whichever comes first, then pause for review." Prevents runaway sessions.
Cost, latency & budget#
What does this action cost, in dollars, in time, in tokens?
Agents are the first class of software where a loop can burn unbounded money or wall-clock time in the background. The UI has to make both legible before, during, and after the run.
Pre-task cost estimate#
in catalog ↗A predicted cost range (tokens, dollars, minutes) shown before the agent begins, with the same precision the user is about to spend at.
Anti-pattern
A single "Run" button with no forecast of scope or spend.
Hard budget ceilings#
in catalog ↗User-set caps per task, per day, per account. The agent stops when the cap is hit and asks, rather than billing through it.
Running meters#
in catalog ↗Live counters during execution: tokens consumed, dollars spent, steps remaining. Ambient enough to ignore when fine, obvious enough to notice when off.
Cost transparency (post-hoc)#
After a run, a breakdown the user can inspect: which tool calls cost what, which steps were retries, where the time and dollars went.
Latency expectations#
Honest time estimates for long-running agents (seconds vs. minutes vs. hours), and a way to walk away and come back without losing state.
Cross-session budget#
in catalog ↗Budgets that persist across sessions, users, and devices. Starting a new chat should not silently reset a cap the user cared about.
Cross-app handoffs#
When control crosses a boundary, what travels with it, and what does not?
Most agent value comes from composing across apps: an email agent that books a calendar event, a code agent that opens a pull request, a research agent that writes to a doc. Boundaries are where trust and blame get muddled.
Context portability#
in catalog ↗A clear mechanism for what context moves when the agent crosses an app boundary: credentials, history, files, preferences. Users can inspect and edit the handoff payload.
Per-target tool permissions#
Permissions scoped per destination app, not once globally. Granting Gmail access does not implicitly grant Google Drive access inside the same agent.
Inter-agent handoffs#
When one agent invokes another, the UI shows the chain: who called whom, with what payload, under which permissions. Handoffs are first-class citizens, not hidden plumbing.
Authentication chains#
in catalog ↗Legible auth flows when an agent acts across identity domains. The user sees which identity is performing each step and can revoke any link in the chain.
Responsibility attribution#
in catalog ↗Clear records of which agent (and which human) is responsible for each action across the chain. Essential for audits, incident reviews, and shared accountability.
Ambient & voice agents#
When is it listening, watching, or running, and how do we tell?
Always-on agents break the classical command-response contract. Users lose the sharp signal that something is happening. The UI compensates with durable, glanceable presence.
Activation boundaries#
in catalog ↗Explicit, visible starts and stops for listening, watching, or running. Wake words, hardware indicators, and time-boxed sessions, not an ambiguous always-on state.
Anti-pattern
A single small LED as the only signal that a mic is hot.
Ambient presence displays#
in catalog ↗Low-attention signals (a color, a shape, a sound) that convey agent state without requiring a glance at a screen. Quiet when idle, louder when active.
Interruptibility#
in catalog ↗A single, known gesture to pause or cancel an ambient agent: a word, a button, a hand sign. Works the same way regardless of what the agent is doing.
Voice confirmation for high-stakes actions#
Explicit voice or multimodal confirmation before irreversible actions, not a silent "sure, done that." The user hears or sees the exact action before it commits.
Multi-user awareness#
in catalog ↗The agent knows who is speaking, acts on the right permissions, and can say so. "I heard Alex ask me to pay the bill; Alex does not have billing access." Shared devices demand it.
Trust scaffolding & provenance#
How do we trust what the agent claims to have done?
Trust is not a vibe. It is the sum of small, durable signals that give the user evidence, and a way to audit the evidence later. Treat trust as infrastructure, not decoration.
Agent identity#
in catalog ↗Each agent has a stable name, version, and capability set the user can point at. Distinguishes which agent did what when multiple are in play.
Capability disclosure#
A plain-language "what I can do and what I cannot" surface, kept current as capabilities change. Users should never have to test the limits to learn them.
Failure disclosure#
in catalog ↗Honest signaling when the agent hit a wall: unknown, blocked, rate-limited, low confidence. The failure mode is named, not hidden behind a hopeful paraphrase.
Anti-pattern
Smooth prose that narrates success when the underlying step failed or was skipped.
Action attribution#
Every external artifact the agent produces (commit, email, ticket, message) carries legible attribution. Downstream humans can tell what was agent-authored.
Audit export#
A one-click, user-owned export of agent activity: inputs, tools called, outputs, costs. Works for compliance and for the user reviewing their own history.
Anti-patterns
The degraded forms. Most production regressions are a variant of one of these, so use them as a review checklist.
Opaque autopilot
The agent acts without a durable indicator that it is acting. Users discover autonomy by seeing unexpected results, not by choosing it.
Bundled consent
One "allow everything" modal at setup, with no way to revise the grant later without starting over.
Cheerful failure
Prose narration that smooths over blocked tool calls, empty search results, or low-confidence steps, presenting them as success.
Hidden cost
No forecast before a run, no meter during, no breakdown after. The user only learns the cost when the bill arrives.
Silent handoff
Control passes between agents, apps, or identities without a legible record. Attribution becomes impossible after the fact.
Open problems
The field has not solved these yet. If you are working on one, we want to hear.
- ·Consent UIs for recurring, long-horizon agents (e.g. a monthly rebalancer): the right cadence is unknown.
- ·Attribution across multi-agent chains: who is responsible when agent A delegates to agent B delegates to a tool?
- ·Universal revoke: when a user revokes an agent, how do downstream caches, forks, and copies get invalidated?
- ·Non-visual presence for ambient agents in shared spaces: sound, light, and haptic vocabularies are nascent.
- ·Voice confirmation under adversarial conditions: how do we prevent replay attacks on spoken approvals?
How to use this framework
- 01When scoping a new agent surface, walk the 7 territories in order. If you cannot answer the core question, the surface is not ready to ship.
- 02In design reviews, use the anti-patterns as a checklist. Most production regressions are variants of one of the five.
- 03Treat this as a living reference. If you ship a new pattern we have not named, send it. We version this framework publicly.
Changelog
v1.0
2026-04-17
Initial public release. 7 territories, 36 patterns, 5 anti-patterns, 5 open problems.
Other frameworks
- Livev1.0
Chat UX
A framework of patterns for designing reliable AI conversations.
Explore framework
- Livev1.0
Trust Scaffolding
A framework of patterns for designing calibrated trust in AI systems.
Explore framework
- Coming soonPlanned Q4 2026
AI Onboarding
Teaching users what AI can do without a user manual.

- Coming soonPlanned 2027
Visual AI UX
Generative images, design tools, canvas surfaces.
