Agentic UX: how to design AI agents people trust
An AI agent doesn’t just answer. It acts. That changes the design job from laying out screens to designing a working relationship.
Most AI agents don’t fail because the model is weak. They fail because people don’t trust them enough to hand over real work, or trust them too much and get burned. Both are design problems. Agentic UX is the work of designing how people give an agent a job, see what it’s doing, step in, and fix its mistakes.
What makes agent design different
A chatbot waits for you. An agent takes steps on its own: it searches, writes, books, sends, or changes things. Every one of those steps is a moment where someone can lose track of what happened. So the questions change. Not “what does this screen show?” but “what does the person need to know, and when, to stay in charge?”
Six principles we design agents by
- Start with one job. An agent that does one job well earns the trust to do a second. An agent that promises everything gets judged on its worst moment.
- Make the handoff explicit. People should know exactly what they asked for and what the agent understood. Restate the task before acting on anything that matters.
- Show the work, not the thinking. People don’t need a wall of reasoning. They need to see what the agent did, what it’s doing now, and what it will do next.
- Stop and ask at the right moments. Decide in advance which actions need a yes: spending money, sending something, deleting something. Everything else should just happen.
- Make undo cheap. If people can easily reverse what the agent did, they’ll let it do more. Undo builds more trust than any confirmation dialog.
- Design the failure. Agents will get things wrong. Each failure should say what happened in plain words and give one clear way out.
Measure behaviour, don’t guess it
With an agent, the behaviour is the interface. That means prompts and evals are design work, not just engineering work. We write down what “good” looks like as tests, then grade the agent against them every time the prompt or model changes.
On Firefox Shake to Summarize, “good” was four plain checks: short enough to read at a glance, recipes exactly right, useful on any kind of page, and clean formatting. Simple, written-down checks like these keep a team from arguing about taste and let you see whether a change made things better or worse.
Design and build in one team
When designers hand a mockup to engineers, the agent’s real behaviour gets decided by whoever writes the prompt last. We think the people who design an agent should also write its prompts, its evals and its production code, so what you designed is what ships.
What this looked like on Firefox
Shake to Summarize isn’t a full agent, but it ran into the same trust problems. Before Firefox sends a page off to be summarized, it asks. The opt-in, written with Mozilla’s legal team, says plainly that the page goes to a third party, and in the EU it names the AI. That’s principle 4: stop and ask before anything leaves the person’s hands.
And when a summary can’t be made, the error says what happened and gives exactly one way out. That’s principle 6. Small moments like these are what let wary people try an AI feature at all.