UI design for agents: principles we’re starting to understand

Actualizado: 2026-05-03

For two years the conversation about how to integrate LLM agents into products reduced to a single answer: a chat with history on the left, a message box at the bottom, and a bubble area in the middle. That was the de facto template, and every new product reused it. Twelve months after industry conversation started questioning that consensus, UI patterns designed specifically for what agents do today are appearing. Some are consolidating quickly. Others are 2025 cycle fashion that won’t survive an honest evaluation.

Key takeaways

• Chat worked while the agent did one task at a time and the conversation fit on a screen; with long tasks, persistent effects and multiple tools, it stops being enough.
• The progress panel pattern (conversation + separate task-state panel) has converged across Claude Code, Cursor, Cline and Aider, suggesting it works.
• The review and approval interface transforms blind confirmation into informed decision using domain visual semantics.
• The execution explorer is the least consolidated but most promising pattern for long-running agents.
• Voice as primary channel, zero-interface agents, and anthropomorphised agents with avatars are fashion that hasn’t settled.

Why chat stopped being enough

Chat worked while the agent did one task at a time and the conversation fit on a screen. As soon as agents started doing background work for minutes, invoking several tools in parallel, and keeping state over files, chat came up short.

Three concrete symptoms repeat across many products:

1. The user hits the stop button because they don’t know if the agent is still working or has hung.
2. After a long run, the user doesn’t know which files changed or which commands were run.
3. When the agent fails, the user has no clear way to see at which step it failed or how to resume.

Those three symptoms point to the same problem: chat as a metaphor isn’t adequate for stateful, long-running, tool-using tasks. Something different was needed.

The progress panel pattern

The first pattern I’ve seen work well is separating conversation from task progress. The conversation stays in one column, and progress is shown in a separate panel listing step by step what the agent is doing: per-tool state, files touched, commands executed, and summarised outputs. The user sees the execution history without having to read the whole conversation.

This pattern has appeared almost identically in several recent products. Claude Code, Cursor, Cline and Aider have variants of the same principle: minimal conversation, rich progress panel. The convergence suggests the pattern works, it isn’t coincidence.

The key to the progress panel is that each step must be collapsible and auditable. The user doesn’t want to read each intermediate output, but they want to open a specific step and examine it when something has gone wrong. It’s the difference between a simple progress bar and a navigable log.

The review and approval interface

The second consolidated pattern is the review interface. When an agent is about to execute an action with side effects — modifying files, running a command, sending an API request — the user should be able to review and approve before it happens.

What works better is showing the exact proposed change with the domain’s visual semantics:

• A side-by-side diff if it’s files.
• A table if it’s database rows.
• A rendered preview if it’s publishable content.

Approval stops being a blind button and becomes an informed decision. This pattern requires the agent to express its intention in a reviewable format before acting, which also makes the system safer and more debuggable. It connects with the agent-executor separation pattern described in prompt injection defense.

The execution explorer

The third pattern, less consolidated but promising, is the execution explorer. An agent operating for hours may have executed dozens of tasks, and the user needs to navigate that history with a clear mental model.

A linear list doesn’t work; a tree view is needed where each task has subtasks and each invocation has inputs and outputs. Products like OpenAI Agent Responses or execution views in platforms like Modal are experimenting with hierarchical structures. There’s no consensus yet, but the direction is clear: the linear log doesn’t scale with current complexity.

Fashion that doesn’t work

Three patterns appeared with a lot of noise but haven’t settled:

• Voice interface as primary channel for work agents. It fits consumer assistants and hands-busy cases but not technical tasks where the user needs to see code, diffs, and tables.
• Zero-interface agents that learn your habits and act without confirmation. This clashes with the reality that models still make mistakes frequently enough that users need control over effectful actions.
• Anthropomorphised agents with avatar and facial mimicry. They generate engagement in demos but noise in habitual use. Teams that have tried it in product have ended up removing it because it distracts.

Principles starting to emerge

Five principles repeat across products that work:

1. Make agent state visible at all times. The user should never doubt whether it’s working, waiting for input, or finished. State ambiguity is the number one problem.
2. Separate conversation from execution. Talking to the agent and watching what it does are two distinct tasks requiring two distinct visual spaces.
3. Preserve reversibility. Every side-effect step should be reversible or at least audited in enough detail to undo.
4. Calibrate trust explicitly. The agent should indicate when it’s doing something routine and when something experimental where the user should review more carefully.
5. Give the user the domain vocabulary. If the domain is code, the UI should speak of files, functions and commits. If support, of tickets and customer conversations. A generic chat UI in a technical domain loses expressive capacity.

How to think about the decision

The question that helps most isn’t which pattern to copy but what tasks users are doing and how long each one takes:

• If the task takes less than a minute and has no persistent effects, chat is enough.
• If it takes more than five minutes or has persistent effects, chat stops being enough and you should think in progress panel, review, and execution explorer.

The other useful question is how much trust the user has in the agent. If it’s new, over-inform: every step visible, every decision auditable, every action reversible. If the user has used it for months and trusts it, you can simplify and hide detail. The same product probably needs two UI modes for the same functionality depending on user maturity level.

Chat will remain as universal input channel, but serious products will have much richer interfaces behind it. The era of the text bubble as the only metaphor for agents is ending, and teams investing now in alternative patterns will have a competitive advantage when user expectations evolve.