Direct answer: Once an AI system can take consequential actions, the interface can no longer behave like a chat transcript with a submit button. It needs to expose intent, scope, permissions, progress, interruption and recovery as explicit product states.
The interface now has to govern action
Chat is a convenient language layer, but it is not a complete control model. The difference becomes obvious when an agent can inspect files, run commands, call tools, update records or keep working across a long-running task. OpenAI’s April 2026 Agents SDK update explicitly moved agent infrastructure toward controlled sandbox execution, state recovery and longer-horizon work. Anthropic has described the same underlying shift from another angle: as agent access expands, products need containment that limits the possible blast radius of a mistake.
For product teams, this changes the design problem. A response can be wrong and still be cheap to ignore. An action can be wrong and leave a changed database, sent email, deleted file or altered configuration behind. The UI therefore has to help a person understand not only what the model said, but also what the system intends to do, what it is allowed to do, what it has already done and what remains reversible.
1. Make inferred intent visible before execution
Natural-language requests are underspecified. “Clean up these files,” “prepare the launch,” or “fix the customer list” all require interpretation. Before an agent crosses from reasoning into action, expose a compact representation of the goal it inferred: the target, scope, major steps and expected outcome.
This does not require showing chain-of-thought. A user needs a product-level plan, not hidden model reasoning. Good intent surfaces are short enough to scan and specific enough to correct. “Archive duplicate invoices in /2025, keep originals, do not send anything” is useful. “I will help you with your files” is not.
2. Match permission to consequence
Constant confirmation destroys the value of automation; blanket permission destroys control. The better pattern is consequence-weighted approval. Low-risk, reversible steps can proceed with lightweight consent. Irreversible, external or high-impact actions should surface a clear approval checkpoint when the consequence becomes real.
Anthropic’s 2026 work on agent containment and safer permission modes is useful evidence for this direction: more autonomy is viable when the environment constrains what can go wrong. Interface permissions are one layer of the same system. They should communicate which resources are in scope, whether the permission is one-time or persistent, and what exact action will follow approval.
3. Treat progress as a trust surface
A spinner is acceptable when a user waits two seconds for a deterministic request. It is weak when an agent may work for minutes, branch into subtasks, call several services and encounter partial failures. Users need a model of progress that answers four questions: what is happening now, what has completed, what is blocked, and whether I can interrupt safely.
This is especially important because real-world agents increasingly run for longer periods. Anthropic reported in February 2026 that the longest Claude Code sessions had increased substantially in autonomous working time over a three-month period. Long-running behavior turns progress design from polish into core product infrastructure.
4. Show the boundary between proposed and committed changes
Agent interfaces should make state changes legible. A useful pattern is to separate planned, in progress, committed and reversible work. This reduces a common ambiguity in chat interfaces: users often cannot tell whether the system is describing an action, preparing it or has already executed it.
For code, that may mean a diff before apply. For CRM, a preview of records to be changed. For email, a draft plus recipients before send. The representation should fit the domain, but the product principle stays constant: consequence should become visible before it becomes irreversible whenever possible.
5. Interruption needs an explicit design
“Stop” is not enough if the user does not know what stopping means. Can the current tool call be cancelled? Will completed subtasks remain? Will a partial transaction roll back? Does the agent keep permissions after the run ends?
A robust interruption state explains what has already changed and what will happen next. This is a key difference between interface control and conversational tone. Reassuring language is not recovery. Recovery is an observable system state.
6. Recovery must tell the user what is still true
Agentic systems will time out, lose external access, receive conflicting tool responses and produce ambiguous outcomes. The recovery message should therefore describe four facts: what failed, what completed, what did not complete, and the safest next action.
“Something went wrong” pushes diagnosis back to the user. “Three of five records updated; two failed before write; no emails were sent; retry only the failed records” gives the user a trustworthy next move.
A practical control-surface checklist
- Intent: Is the interpreted goal visible and correctable?
- Scope: Can the user see which resources, accounts or records are involved?
- Permission: Is approval proportional to risk and consequence?
- Preview: Can important changes be inspected before commit?
- Progress: Can the user distinguish active, complete and blocked work?
- Interrupt: Is stopping behavior predictable?
- Recovery: Does failure explain the resulting state, not just the error?
- Auditability: Can the user later see what the agent actually did?
The design test
Ask one question at every consequential step: if the model is wrong here, can the user see the mistake early enough to prevent, limit or reverse the consequence? If the answer is no, the product is hiding too much state.