Agentic UX Design Patterns

Bottom Line First

The core UX challenge with agentic systems is not capability — it is trust. Users have to trust something they cannot fully observe. The agent might be doing the right thing, or it might be about to delete a folder, send an email to the wrong person, or go down a four-step reasoning path that leads nowhere. The user has no window into any of it.

Chat UX has a simple trust contract: the user sees every output immediately, evaluates it, and decides what to do next. The human is always in control. Agentic UX breaks that contract. The agent runs for seconds, minutes, or hours. It touches real systems. It makes decisions autonomously. By the time the user notices something is wrong, the action may already be done.

Every pattern in this article is a technique for rebuilding trust under those conditions — making the agent’s behavior legible, interruptible, and recoverable without making the user babysit every step.

Why Agent UX Is Fundamentally Different

Long-running and multi-step

A chat response is instant. An agent task might take thirty steps over ten minutes. The UX surface area is enormous by comparison. Users need to know what is happening, in what order, and why — without reading a wall of logs.

Real-world consequences

When a chat model gives a wrong answer, the user reads it and moves on. When an agent takes a wrong action — submits a form, commits code, sends a message, charges a card — the consequence is real and potentially irreversible. The asymmetry between “hard to undo” actions and “easy to undo” actions has to be surfaced explicitly.

Non-deterministic behavior

Agents that call tools, make planning decisions, and recover from failures will not follow exactly the same path twice on the same input. That variability is often a feature. It is also terrifying to users who cannot predict what the agent will do next. UX patterns that expose the agent’s reasoning model reduce this fear.

Escalating scope

A chat model answers the question asked. An agent given a vague goal will interpret scope. “Clean up my inbox” might mean archiving a hundred emails. “Refactor this module” might mean touching forty files. Users who don’t know what they signed up for will not trust the output even when it is correct.

The Patterns

1. Task Brief

When to use: At the start of any non-trivial agent task. Especially when the task has ambiguous scope, real-world consequences, or is hard to interrupt once started.

The Task Brief pattern requires users to define the goal, any explicit constraints, and the stopping conditions before the agent begins. It is a structured intake form rather than a freeform prompt.

A well-designed brief forces the user to confront scope: “apply to all files in the project” is a meaningful choice, and making it explicit before the agent starts prevents post-hoc surprise. It also gives the agent a clear contract to operate against — a misunderstanding caught at brief time is cheap. A misunderstanding caught after forty tool calls is not.

Implementation notes: Render the brief as a structured form with sensible defaults, not a blank text field. Validate at input time — if the user references a path that doesn’t exist or a resource the agent can’t access, surface that before the task starts. Devin does this well: before a coding task begins, users confirm the repo, branch, and objective. Lindy’s workflow builder requires explicit scope on every trigger.

2. Progress Narration

When to use: Any task that runs longer than a few seconds. Any task the user cannot monitor directly.

A spinner is not a UX. Users watching a spinner for two minutes have no idea whether the agent is working, stuck, or about to surface an error. Progress Narration means the agent emits a natural-language description of each step it takes — not internal debug logs, but a human-readable running commentary.

The goal is to make the agent’s internal monologue accessible without overwhelming the user. “Searching for relevant files… found 12 matches. Reading the three most relevant ones. Drafting a response.” This is not post-hoc summarization — it is live narration as the agent executes.

Implementation notes: Stream narration tokens in real time rather than buffering complete step descriptions. Collapse completed steps into a summary to avoid vertical sprawl on long tasks. Claude’s computer use interface surfaces each action (click, type, scroll) as a narration event. Cursor agent shows each file read and edit as it happens. The bar is legibility, not verbosity — one sentence per step is usually enough.

3. Checkpoint Approval

When to use: Before any high-stakes, hard-to-reverse action. Sending emails, committing to main, billing operations, deleting records.

Checkpoint Approval is a mandatory pause inserted into the agent’s execution plan at predefined step types. The agent surfaces what it is about to do and waits for explicit user confirmation before proceeding. This is not the same as asking the user to approve every step — that degenerates into a worse chat interface. The checkpoints are pre-defined on action type, not on every action.

The design question is what counts as a high-stakes action in your domain. In a coding agent: committing to a shared branch, modifying infrastructure config, deleting files. In an email agent: sending externally, unsubscribing, marking as spam at bulk scale. In a data agent: writing to production tables, triggering billing events.

Implementation notes: Define a tiered action taxonomy at product design time: read-only, reversible write, irreversible write. Checkpoints apply automatically to the irreversible tier. Devin gates deploys to production. The GitHub Copilot coding agent requires confirmation before any pull request is created. Keep checkpoint UI minimal — show the action, the target, the consequence, and two buttons. Adding explanation text at checkpoint time (“this will send to 3,412 recipients”) significantly reduces user anxiety.

4. Rollback Breadcrumb

When to use: Any agent that takes write actions. Especially useful in coding, file management, data transformation, and content workflows.

A Rollback Breadcrumb is a chronological trail of every action the agent has taken, with each action individually reversible. It is not undo in the traditional sense — it is a structured history that the user can traverse and selectively reverse.

This pattern is what enables users to trust agents with consequential actions. The agent is not a black box that did something — it is a transparent trail of discrete, attributable steps. A user who can roll back any single step without losing the others will allow the agent much more latitude.

Implementation notes: Each entry in the breadcrumb should include: the action type, the target (file path, record ID, API endpoint), a snapshot of the pre-action state (or a diff), a timestamp, and a rollback affordance. Cursor’s edit history treats each agent edit as a discrete checkpoint with per-file undo. Git-backed systems get this partially for free — each agent commit is naturally reversible. The hard part is breadcrumbing non-git-backed actions: API calls, database writes, email sends. For those, you need an explicit action log with stored pre-state.

5. Confidence Gate

When to use: In any domain where guessing wrong is worse than stopping and asking. High-stakes decisions, ambiguous instructions, novel situations.

A Confidence Gate is a mechanism by which the agent stops and escalates rather than proceeding when its confidence in the correct next action falls below a threshold. Instead of making its best guess and moving on, the agent surfaces the uncertainty to the user and asks for clarification.

This pattern runs counter to the natural pressure to maximize agent autonomy. The temptation is to let the agent guess and recover. The right call depends on the cost of a wrong guess. In a coding agent that might modify the wrong function: stop and ask. In a research agent that might include a slightly less relevant source: proceed and annotate.

Implementation notes: Confidence gates are not just model confidence scores — those are noisy and poorly calibrated. More useful gates are structural: the agent has hit a decision branch where both paths have meaningful downstream consequences; the agent is about to modify something it has not read; the agent is operating on ambiguous user identity (which “John Smith” in the address book?). Lindy surfaces ambiguity at decision time with a simple escalation card. Claude will explicitly say “I’m not sure which interpretation you intended” rather than picking one. Design the escalation card to be a single-question prompt, not a freeform conversation restart.

6. Scope Visualization

When to use: Before any agent task that operates on a defined resource set — files, contacts, records, repositories, accounts.

Scope Visualization renders what the agent can and cannot touch before it starts working. It answers the user’s implicit question: “what is this thing allowed to do to my stuff?”

This pattern addresses a specific anxiety: the agent might be more powerful than the user thinks. A user who hands an agent access to their Google Drive may not realize that means all 10,000 files, including the archived ones. Showing the scope explicitly — and allowing the user to constrain it — reduces post-task surprise and enables informed consent.

Implementation notes: Render scope as a navigable tree or list, with counts and size indicators. Surface the default scope and allow users to narrow it before starting. Cursor’s agent shows which files are in context before making edits. Claude computer use shows the desktop environment the agent will operate on. Lindy’s integrations screen shows exactly which accounts and permissions are connected. The visualization should be interactive: users should be able to exclude directories, record types, or accounts before the task begins.

7. Async Delivery

When to use: Tasks that take longer than the user’s attention span — anything over two to three minutes for most users. Background research, batch processing, multi-file refactors, overnight scheduled tasks.

Async Delivery reframes the agent interaction as fire-and-forget: the user defines the task, closes the UI, and gets a notification when the result is ready. This pattern accepts that users will not watch a progress bar for ten minutes and designs for that behavior explicitly.

The UX challenge with async delivery is not the notification — it is re-entry. When the user comes back, they need to quickly understand what happened, why, and what (if anything) requires their action. The delivery artifact is as important as the notification.

Implementation notes: Notifications should be actionable, not just informational: “Your refactor is ready — 14 files changed, 2 require review” with a direct link to the review view, not a link to the dashboard. The re-entry view should surface the most important artifacts first: what changed, what succeeded, what needs review, what failed. Devin sends Slack notifications on task completion with a link to the session replay. Lindy tasks run in the background and surface results in a structured card. For long tasks, send a midpoint notification if something requires user input rather than waiting for full completion.

8. Collaborative Replanning

When to use: Long-running or complex tasks where user goals may shift mid-execution. Research tasks, multi-step code changes, planning workflows.

Collaborative Replanning allows users to redirect the agent mid-task without restarting from scratch. The agent accepts a course correction, reconciles it with work already done, and continues from a reasonable state rather than discarding all progress.

This pattern makes agents feel less like batch jobs and more like collaborators. Users who know they can steer mid-course are more willing to kick off ambitious tasks, because the cost of a wrong initial direction is much lower.

Implementation notes: The key constraint is state reconciliation — the agent needs to understand what it has already done, what still needs doing, and how the new direction affects both. Not all redirects are cheap. “Focus on the auth module instead of the payment module” is a clean pivot. “Actually I want this in TypeScript not Python” after forty steps of Python code is a near-restart. The UX should communicate replanning cost: “This change affects 8 of 12 completed steps. I’ll redo those — the other 4 can stay.” Cursor agent handles file-scope pivots well. Claude generally supports mid-conversation goal shifts gracefully. The hard part is agents with long execution graphs where replanning requires explicit state management.

9. Failure Explanation

When to use: Every time an agent task fails or partially fails. No exceptions.

Failure Explanation means that when an agent stops without completing the task, it tells the user exactly what went wrong, at which step, why it could not continue, and what the user can do to resolve it.

“An error occurred” is not a failure explanation. “I couldn’t complete step 4 because the function processPayment takes three arguments but I only had two — I need the currency parameter. You can either add it to the function signature or tell me which currency to hardcode.” is a failure explanation.

Implementation notes: Failure explanations should be structured: location (which step, which file, which tool call), cause (what specifically failed), state (what was completed before the failure and whether it was rolled back), and resolution path (what the user can do to continue). Avoid technical stack traces in user-facing failure cards — translate them. Devin’s failure summaries include a diff of what was attempted and a hypothesis about the root cause. The agent’s failure explanation quality is often more important to user trust than its success rate — users can forgive failures, but not opacity.

10. Sandboxed Preview

When to use: Before any large-scale or hard-to-reverse batch operation. Database migrations, mass file edits, bulk email sends, configuration changes.

Sandboxed Preview shows the user what the agent is about to do before it does it, in a safe environment that does not affect production state. The user reviews the plan, optionally edits it, and then approves execution.

This is the equivalent of --dry-run in CLI tools, promoted to a first-class UX feature. The preview is not a text description of the actions — it is the actual output of executing against a sandbox, which reveals real behavior rather than intended behavior.

Implementation notes: The most important property of a sandboxed preview is fidelity: if the preview shows X but execution does Y, you have made things worse by adding false confidence. Prefer running the actual agent code against a snapshot or staging environment over generating a synthetic preview. Show the preview as a structured diff: what will be created, modified, deleted — with before/after for modifications. Cursor’s agent shows a multi-file diff before applying changes. Database migration tools like Atlas and Flyway use dry-run output as the primary UX before any migration applies. For irreversible side effects with no staging equivalent (email sends, payment charges), build an explicit mock mode that runs the full pipeline with all outbound calls stubbed.

Composing the Patterns

These patterns are not mutually exclusive. Most well-designed agent products compose several of them into a coherent flow:

1. Task Brief captures goal and constraints
2. Scope Visualization shows what the agent will operate on
3. Sandboxed Preview optionally shows planned actions before execution
4. Progress Narration keeps the user informed during execution
5. Checkpoint Approval gates irreversible actions
6. Rollback Breadcrumb records every action for recovery
7. Confidence Gate escalates uncertainty rather than guessing
8. Async Delivery handles long-running tasks with clean re-entry
9. Collaborative Replanning allows mid-course correction
10. Failure Explanation surfaces actionable information on failure

The minimal viable set for any agent with real-world consequences is: Task Brief, Rollback Breadcrumb, and Failure Explanation. Without these three, you have an agent that users cannot start with confidence, cannot recover from mistakes with, and cannot diagnose when it breaks.

The patterns that require the most investment are Sandboxed Preview (sandbox environment) and Rollback Breadcrumb (action log with pre-state snapshots). Both are worth building early, because retrofitting them into an agent that has been running in production without them is genuinely hard.

The Trust Flywheel

Agent UX is ultimately about building trust incrementally. Users who have seen an agent narrate its work, pause at checkpoints, recover cleanly from a failure, and accept a mid-course correction without drama will give that agent much more autonomy over time. That expanded autonomy is what makes agents genuinely valuable — not the raw capability of the underlying model.

The patterns in this article are not a checklist for launch day. They are the building blocks of a trust flywheel. Ship the ones that matter most for your domain first, observe where users lose confidence, and add the patterns that address those specific friction points. The goal is an agent your users are willing to let run.