Designing for AI agents: control, consent and trust
An agent doesn’t only answer: it acts. It buys, cancels, sends, changes. That changes what we design: not just the screen where someone decides, but the limits within which the agent decides on that person’s behalf. These are the patterns I recommend so that trusting an agent is an informed decision and not an act of faith.
What changes when the user delegates
For years we designed interfaces so that a person could do something: fill in a form, press a button, choose an option. With an agent, the person delegates a goal and the agent plans and acts. The screen stops being the place where the work is done and becomes the place where limits are agreed.
That is why designing for agents looks less like designing a flow and more like designing a relationship. Three questions must always have an answer, in plain sight:
- What will it do? Before acting, not after.
- How far can it go? What it can touch and what it cannot, and who decided that.
- How do I undo it? A way back, or a clear notice that there isn’t one.
The context doesn’t invite the opposite. NN/g describes 2026 as the year of AI fatigue. Trust is not earned with magic, it is earned with control.
Six patterns, by moment
A very useful framework is Victor Yocco’s in Smashing Magazine, which organises patterns along the lifecycle of an interaction with an agent. Mine is a shorter version, organised by the moment the person needs each thing.
- Before acting
- Intent previewThe agent says what it will do, on what and with what effect, before doing it.
- Scoped permissionsWhat it can read, what it can write and what is off limits, visible and editable.
- While acting
- Visible progressConcrete steps and their status, instead of an endless loading indicator.
- Reason and confidenceWhy it is doing it and how sure it is, in plain language.
- After acting
- Action logWhat it did, when and with what data, available to the person who asked.
- Undo and recoveryGo back with one gesture, or know clearly what cannot be undone.
There is a seventh case worth solving from the start: what the agent does when it is unsure. The right answer is almost never to guess. It is to stop, say what it is missing and hand the decision to a person, with the context they need to decide.
An example: the intent preview
If you could only implement one pattern, make it this one. It builds the most trust, because it turns “do it” into “approve this”. An example with an agent that reviews your account and proposes changes:
I’m going to make 3 changes to your account
- Switch the Internet L plan to Internet M from 1 DecemberReversible
- Turn off roaming on your main lineReversible
- Cancel the TV optionNot reversible
Estimated saving: CHF 14 a month
High confidence · Based on your last 6 bills
What makes it work:
- It states the action, not a vague intention. “Switch the Internet L plan to Internet M from 1 December”, not “optimise your account”.
- It separates what is reversible from what is not. A clear warning on the action that cannot be undone.
- It lets you edit before approving. Approving all three or only two is more honest than a yes or a no to everything.
- It shows the effect and the confidence. What you gain and how sure the agent is of its proposal.
The autonomy dial
Autonomy isn’t a switch, it’s a dial. The usual mistake is choosing one level for the whole product, when each action may need a different one, and so may each person or each organisation.
Two rules that seem sensible to me. Start low: it is easier to raise the level when there is evidence than to lower it after an incident. And make the level a visible setting for the person who delegates, not a decision hidden in the product.
How to decide how much autonomy to give
Two questions are enough for a first split: how easy the action is to undo and what it could cost if it goes wrong.
It doesn’t replace judgement, but it forces a conversation about each action with product, legal and engineering before launch, and not after the first mistake.
This is where what I wrote in the article on component contracts fits: a good contract can also declare which actions an agent may run and at what level of autonomy.
Designing trust also means measuring it
Which transparency signals make a person comfortable reducing their oversight is still an open question. The answer changes with each product, so it has to be measured:
- Approvals without edits. If almost nobody edits the proposal, they either trust it or don’t read it.
- Use of undo. A heavily used undo says the agent gets things wrong or the proposal isn’t understood.
- Time to first approval. It measures how much it costs to start trusting.
- Escalations to a person. Too many, and the agent isn’t useful; none, and it is probably guessing.
A well-designed agent doesn’t ask for trust: it earns it, action by action.
What worries me
- High autonomy by default. An agent that acts alone from day one gives no chance to build trust.
- Decorative transparency. A log nobody can read isn’t transparency.
- Approving out of habit. If everything has to be confirmed, people end up confirming without reading; the design should ask for permission only when it matters.
- Blurred accountability. When something goes wrong, the person must know who answers for it: “the agent” isn’t an answer.
What I would do this week
- Pick one action an agent could run in your product.
- Classify it by how easy it is to undo and what it costs if it goes wrong.
- Write the preview before the prompt: how you would explain it to a person before they approve.
- Set the starting level and how it rises, with the metrics that justify it.
- Don’t launch without a log and an undo.
Checklist
A Markdown checklist to review an agent action before launch: intent, permissions, autonomy, log, undo and escalation.