Direct answer: Agent UX works best when the interface reveals the agent’s goal, available tools, permission boundary, current phase, evidence, committed actions and recovery path — while keeping the user out of low-value micromanagement.
Agent UX is not chatbot UX with more buttons
A chatbot primarily produces responses. An agent may continue working after a message, use tools, change external state, delegate subtasks and return later with a result. That difference creates new interface states that do not fit comfortably inside a linear transcript.
OpenAI’s 2026 Agents SDK work formalizes long-horizon runs, sandboxed execution and resumable state. Anthropic’s work on agent tools, containment and evaluations makes the same architectural reality visible from several directions. Product teams therefore need interface patterns for systems whose behavior is asynchronous, probabilistic and action-oriented.
Pattern 1 — Goal confirmation
Use when: the request can be interpreted in several materially different ways.
Show: a short restatement of the goal, important scope boundaries and expected deliverable. Let the user correct the goal before expensive or consequential work begins.
Avoid: asking for confirmation when the request is already precise and low-risk. Confirmation fatigue teaches users to click through without reading.
Pattern 2 — Tool and data scope
Use when: the agent can access multiple data sources, accounts or tools.
Show: which connectors are active, what data will be read, and which systems can be changed. Scope belongs close to the action, not buried in settings.
Avoid: generic permission copy such as “allow access” when the actual permission spans materially different resources.
Pattern 3 — Plan preview
Use when: the task is multi-step, expensive or difficult to reverse.
Show: a compact plan with key steps, not hidden reasoning. The user should be able to remove or reorder major steps and lock constraints.
Avoid: presenting a verbose pseudo-chain-of-thought as if more text automatically means more transparency.
Pattern 4 — Consequence-weighted approval
Use when: the agent can send, publish, delete, purchase, deploy or otherwise affect external state.
Show: approval at the point of consequence, with the exact action and target visible. Group low-risk reversible steps; isolate high-impact commits.
Avoid: either extreme: approving every tiny tool call or granting permanent blanket autonomy by default.
Pattern 5 — Live phase model
Use when: work lasts longer than a normal request/response interaction.
Show: phases such as preparing, retrieving, editing, waiting for approval, executing and verifying. Each phase should map to something the system can actually observe.
Avoid: fake progress percentages when the product cannot estimate remaining work.
Pattern 6 — Evidence drawer
Use when: the agent makes claims from retrieved documents, web sources or business records.
Show: the source attached to the claim, ideally with the relevant excerpt, timestamp or record identifier.
Avoid: a long undifferentiated source list at the bottom that makes it impossible to verify which evidence supports which claim.
Pattern 7 — Change preview
Use when: the agent edits code, content, configuration or structured records.
Show: a diff, before/after state or explicit set of affected objects before commit.
Avoid: “Done” messages that force users to discover changes manually after they are already applied.
Pattern 8 — Pause and resume
Use when: long-running work can be safely suspended.
Show: whether the current step can stop immediately, which completed work remains, and what context will be preserved for resume.
Avoid: using “cancel” when cancellation merely hides the UI but the external action continues.
Pattern 9 — Failure with state reconciliation
Use when: partial completion is possible.
Show: completed, failed and untouched items separately, plus a retry path that does not duplicate successful work.
Avoid: generic error states that make users repeat the entire workflow and risk duplicate side effects.
Pattern 10 — Action history
Use when: the agent performs consequential work over time.
Show: a durable record of actions, approvals, tool calls that changed external state and who initiated them.
Avoid: treating the chat transcript as the only audit trail. Conversations are optimized for reading, not operational accountability.
How to choose the pattern set
Do not apply every pattern to every product. Start with consequence. If the system only drafts text, lightweight provenance and revision controls may be enough. If it can access private data, spend money or modify production systems, the control surface needs stronger scope, approval, audit and recovery states.
Agent UX should reduce unnecessary supervision without obscuring real risk. The design goal is not “maximum autonomy.” It is maximum useful autonomy inside a boundary the user can understand and control.