The Interface After Chat: How to Design AI Agents People Can Actually Trust

Language can create a false sense of simplicity. “Book the best option” hides decisions about price, dates, preferences, cancellation terms, payment, and what “best” means.

The design problem after chat is therefore not: How human should the agent sound? It is: How can a person understand, direct, constrain, verify, and correct what the agent is doing?

The best agent experience will not be the one with the fewest interruptions or the most autonomy. It will be the one that gives the user the right amount of control at the right moment.

Chat is an input, not the whole interface

Natural language efficiently expresses goals and context, but chat is a weak container for consequential, multi-step work.

A transcript hides structure: plans, permissions, progress, and important changes compete in one stream. A sentence such as “Done” tells the user almost nothing about what actually happened.

A serious agent product needs additional interface surfaces:

• a clear statement of the interpreted goal;

• a plan that can be inspected or edited when needed;

• visible scope and permissions;

• progress tied to real actions;

• checkpoints for consequential decisions;

• evidence of completed work;

• controls to pause, redirect, undo, or escalate.

The interface should scale with consequence. Drafting meeting notes can remain lightweight. Changing account permissions should not.

A practical interaction loop for trustworthy agents

I use a six-part loop to think about agent interactions:

Intent → Plan → Permission → Action → Evidence → Correction

1. Intent: “Did it understand what I mean?”

Before an agent acts, the user should be able to see the goal it is pursuing—not merely the prompt they typed.

For ambiguous or consequential work, reflect the interpretation in a compact, editable form: objective, constraints, exclusions, and definition of done.

A useful clarification question resolves a decision that materially changes the outcome. An agent should not ask about every detail, but it should pause when the uncertainty concerns user intent, preference, or authority. Anthropic makes a similar distinction in its guidance on trustworthy agents: useful autonomy requires avoiding both constant interruption and silent overreach.

Design pattern: Convert the request into a short task brief. Highlight assumptions rather than burying them in prose.

2. Plan: “What is it going to do?”

Plans help people catch misunderstandings, but they are not proof. Research on plan-then-execute agents found that plausible plans can be convincingly wrong and produce miscalibrated trust.

Plan previews should be operational, not theatrical. Show steps affecting risk, cost, data, or other people, and let users modify meaningful choices.

For low-risk tasks, the plan can be a one-line status. For high-risk tasks, show:

• systems the agent will access;

• records or files it expects to change;

• messages it may send;

• estimated cost or other commitment;

• points where approval will be required;

• stopping conditions and expected result.

Design pattern: Present a staged plan with editable constraints, not a decorative chain-of-thought display.

3. Permission: “What is it allowed to do?”

Agent permissions should follow the principle of least privilege: give the system only the access it needs, for the scope and duration it needs.

Permissions should be specific. “Allow access to email” is broad; “Read this thread for the next hour” is understandable. One-time and persistent permissions should look different.

OpenAI's computer-use guidance recommends confirmation at the point of risk, not prematurely. Blanket approval transfers cognitive burden before the exact action is known. Asking immediately before a deletion, payment, permission change, installation, or external submission makes the decision concrete.

A good confirmation names:

1. the exact action;

2. the target;

3. the material effect or risk;

4. the data that will be transmitted;

5. whether the action can be reversed.

Design pattern: Use scoped grants for capability and point-of-risk confirmation for consequential execution.

4. Action: “What is happening now?”

Long-running agent work needs honest state communication. A generic spinner or endlessly optimistic “Working…” label is not enough.

Show progress as observable events: searching approved sources, comparing three options, preparing a draft, waiting for a system response, or blocked by missing information. Distinguish between planned, in progress, completed, skipped, and failed. If the system cannot estimate time reliably, do not invent a percentage.

Pause and stop should be prominent during tool use. Redirecting the agent should preserve completed work where possible.

Progress is also an accessibility issue. WCAG guidance requires status messages to be programmatically available to assistive technologies without forcing focus changes. Agent activity logs, alerts, and completion messages should be designed for screen-reader and keyboard users from the start.

Design pattern: Use an accessible activity timeline that reports meaningful state changes and exposes pause or stop controls.

5. Evidence: “What actually happened?”

An agent should not claim success merely because it attempted an action. “Email sent” requires provider confirmation. “Reservation booked” requires a booking record. “File updated” requires a visible diff or version.

Evidence can include:

• links to created or changed artifacts;

• source citations for factual outputs;

• before-and-after comparisons;

• receipts, IDs, timestamps, or system confirmations;

• a concise summary of skipped or unresolved items;

• the permissions and tools used.

Google Cloud describes grounding as connecting output to verifiable sources for auditability. The same logic applies beyond answers: completion claims should be tethered to observable results.

Avoid exposing internal reasoning as if it were evidence. A confident explanation of why the agent thinks it succeeded is weaker than a confirmed result from the system where the action occurred.

Design pattern: Pair every consequential completion claim with a verifiable artifact or external confirmation.

6. Correction: “What can I do if it is wrong?”

Users need ways to revise inputs, reject an individual step, retry a failed action, compare alternatives, restore a previous version, or hand the task to a person. The interface should preserve enough context that correction does not mean starting from zero.

Reversibility should influence autonomy. An agent can be allowed to do more when actions are cheap to undo and easy to inspect. Irreversible or externally visible actions need stronger review and approval.

When rollback is impossible, support compensation: cancellation, correction, restoration, support, or human review. Distinguish undo, reversal request, and manual recovery.

Design pattern: Make recovery controls local to the affected step and keep a durable record of changes.

Trust is a product property, not a tone of voice

Friendly copy can make an agent approachable. It cannot make it trustworthy.

Trust comes from the relationship between capability and constraint. The user can see what the agent believes, what it is allowed to do, what it did, and what happens when it is wrong. Anthropic's framework for safe and trustworthy agents groups this problem around human control, alignment with user expectations, secure interactions, transparency, and privacy. NIST's Generative AI Profile similarly treats risk as a system concern that includes confabulation, privacy, information security, human-AI configuration, and the wider component chain.

The interface is where those system decisions become real. Backend permission policy, safety reviews, and model cards do not replace usable in-product controls and feedback.

The agent trust checklist

Before shipping an agent workflow, review it across six areas.

Intent

• Can the user see the agent's interpreted objective?

• Are material assumptions and exclusions visible?

• Does the agent ask when uncertainty affects intent or preference?

Authority

• Is access scoped by tool, data, duration, and action?

• Are high-impact actions confirmed at the point of risk?

• Can the user revoke or reduce permission easily?

Visibility

• Can the user distinguish planned, active, completed, blocked, and failed work?

• Are progress and status updates accessible?

• Can the user pause, stop, or redirect execution?

Evidence

• Are factual outputs grounded where appropriate?

• Are completion claims tied to real artifacts or confirmations?

• Does the result state what was not completed?

Reversibility

• Can users edit, retry, reject, compare, undo, or restore?

• Are irreversible actions clearly identified before execution?

• Is there a recovery or human-handoff path?

Accountability

• Is there a durable record of actions, approvals, tools, and changes?

• Can teams evaluate failures across the model, orchestration, tools, and environment?

• Is responsibility clear when the system cannot proceed safely?

The interface after chat is a control system

Chat compressed AI into a familiar box. Agents bring complexity back as questions of judgment, authority, and consequence. The answer is not to abandon conversation, but to stop treating it as the entire product.

A trustworthy agent interface makes delegation legible. It helps the user form intent, inspect a plan, grant limited authority, observe execution, verify results, and recover from mistakes. It supports autonomy without pretending that autonomy is always desirable.

The goal is not an agent that never asks, never fails, or never needs oversight. The goal is an agent that knows when to proceed, when to explain, when to confirm, and when to hand control back.

That is the interface after chat: not a more charming assistant, but a better-designed relationship between human judgment and machine action.