_AI AGENTS_

# 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.

Javier González · 11 Nov 2026 · 7 min read

## 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](https://www.nngroup.com/articles/state-of-ux-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](https://smashingmagazine.com/2026/02/designing-agentic-ai-practical-ux-patterns/), 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 preview.** The agent says what it will do, on what and with what effect, before doing it.
- **Scoped permissions.** What it can read, what it can write and what is off limits, visible and editable.

**While acting**
- **Visible progress.** Concrete steps and their status, instead of an endless loading indicator.
- **Reason and confidence.** Why it is doing it and how sure it is, in plain language.

**After acting**
- **Action log.** What it did, when and with what data, available to the person who asked.
- **Undo and recovery.** Go 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:

**Bills agent · Proposal**

I’m going to make 3 changes to your account

- Switch the Internet L plan to Internet M from 1 December (Reversible)
- Turn off roaming on your main line (Reversible)
- Cancel the TV option (Not reversible)

Estimated saving: CHF 14 a month

High confidence · Based on your last 6 bills

Approve all 3 · Edit · Cancel

_A fictional example of an intent preview: what changes, what can be reverted, how sure the agent is and what the effect is, before approving._

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.

| Level | The agent… | Use it when… | The design needs… |
|---|---|---|---|
| **1 · Suggests** | proposes and the person executes. | a mistake is costly or trust is not there yet. | Showing the suggestion and its reason. |
| **2 · Asks permission** | prepares the action and waits for approval. | the action matters but can be reviewed. | A clear preview, editing and approval. |
| **3 · Acts and tells** | executes and notifies with an undo option. | the action is reversible and frequent. | An immediate notice and a reliable undo. |
| **4 · Acts alone** | executes within agreed limits and leaves a log. | the impact is low and trust is proven. | Explicit limits, a log and periodic review. |

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.

| | Reversible | Hard to reverse |
|---|---|---|
| **Low impact** | **Acts alone**: Sorting, tagging, preparing drafts. | **Asks permission**: Sending a message, posting a comment. |
| **High impact** | **Acts and tells**: Changing a plan with undo, booking an appointment. | **Only suggests**: Paying, cancelling a contract, deleting data. |

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](https://baguelus.com/en/articulos/contratos-diseno/) 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

1. **Pick one action** an agent could run in your product.
2. **Classify it** by how easy it is to undo and what it costs if it goes wrong.
3. **Write the preview before the prompt:** how you would explain it to a person before they approve.
4. **Set the starting level and how it rises,** with the metrics that justify it.
5. **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. [Download the checklist](https://baguelus.com/recursos/lista-comprobacion-agentes-en.md)