Designing Permission

For years, much of interaction design has started from a fairly simple premise: the user decides and the system responds.

We click, choose an option, confirm an action, submit a form. Even when the system automates part of the process, there is usually a clear moment when the person initiates, validates or carries out what is happening.

Artificial intelligence is beginning to change that relationship.

A system no longer has to be limited to waiting for a specific instruction. It can interpret an intention, anticipate the next step, prepare an action and even carry it out without the user having to intervene again at every stage.

And that is where a new design question emerges.

It is no longer enough to ask what an AI can technically do. We also need to decide what it should be able to do without us.

Because capability and permission are not the same thing.

The fact that a system can draft an email does not mean it should send it. The fact that it can rearrange a calendar does not mean it should move any meeting. The fact that it can find a cheaper alternative does not mean it should automatically make a purchase.

In each of these cases, the technology may be capable of completing the action. What changes is the degree of autonomy we are willing to grant it.

That is why designing AI products means beginning to work with a boundary that used to be much simpler: how far the system can proceed before returning the decision to the person.

That boundary will not be the same for every action, every user or every context.

And perhaps one of the most important design decisions of the coming years will not be which capabilities we incorporate into AI, but which of them it can carry out without asking us again.

Suggesting, preparing, confirming and acting are different permissions

When we talk about autonomy in artificial intelligence systems, it is easy to fall into an oversimplification: either the person retains control or the machine acts automatically.

But there are many possibilities between those two extremes.

An AI can simply suggest an action, prepare the next step and leave it ready, ask for confirmation before carrying it out, or act directly when the context allows it.

The difference between one option and another does not necessarily lie in the system’s technical capability, but in the permission it has to proceed.

An assistant can recommend several available times for a meeting. It can also draft the invitation and select the attendees. It can have everything ready and ask for final confirmation or, if certain conditions have already been defined, send the invitation directly.

The technology may be virtually the same. What changes is the point at which the person stops intervening.

And that point does not have to be fixed.

The same AI can act with considerable autonomy in a routine task and, a few seconds later, ask for confirmation for another action with greater consequences. It can rearrange a list without asking, prepare a reply without sending it, and stop before making a purchase.

That is why speaking of “autonomous” systems as a single category can be misleading.

What matters is not deciding whether an AI is autonomous or not, but what degree of autonomy it has in each specific action.

Designing that distinction allows automation not to be a general property of the product, but an interaction decision that can adapt to context, risk and user expectations.

Permission should depend on the action, not the agent

Talking about an AI as “autonomous” may be useful for describing a general capability, but it is too broad a category when it comes to designing the experience.

The same system can behave in very different ways depending on what it is doing.

It can automatically rearrange a list, prepare a response that still needs reviewing, suggest an alternative, or stop before carrying out an action with greater consequences.

That is why perhaps the question should not be how much control the agent has in general terms, but what permission it has for each specific action.

This distinction matters because not all actions carry the same weight.

Changing the order of a few items, amending a booking, sending a message or making a payment may all be part of the same flow, but they should not necessarily share the same level of autonomy.

Designing from the action forces us to look more closely at what happens at every moment: what changes, who may be affected, what consequences it may have and what scope there is to correct it afterwards.

It also avoids a dangerous idea: that once a certain degree of autonomy has been granted to the system, that autonomy should apply equally to everything it does.

Permission can be granular.

A person may be comfortable letting AI resolve certain tasks without intervention while, at the same time, wanting to retain the final decision in others.

That is why the true unit of design is not the agent in the abstract, but the action, its context and its consequences.

When to introduce friction

For years, an important part of digital design has sought to reduce friction: fewer steps, fewer clicks, fewer interruptions.

But when a system can act on our behalf, removing friction does not always improve the experience.

Sometimes, stopping is part of good design.

The issue is not to add confirmations out of caution, but to understand what kind of action is about to be carried out and what consequences it may have.

There are actions where the cost of getting it wrong is practically irrelevant. In others, a decision may involve money, commit another person, alter important information or be difficult to undo.

Reversibility also matters.

An action that can be corrected immediately is not the same as one whose effects are permanent or very difficult to reverse. The less possibility there is of going back, the more sense it makes for the system to reduce its autonomy or request explicit intervention.

Another important factor is whether the action affects only the user or also third parties.

Reorganising personal information may require very little oversight. Sending a message, cancelling a meeting or accepting terms on someone’s behalf introduces consequences that go beyond the interface itself.

And then there is context.

A decision that was valid when a task began may no longer be so a few minutes later. A price may change, availability may disappear, a recipient may be altered or new information may emerge that changes the decision.

That is why designing autonomy also means deciding when it is worth interrupting the flow.

Not all friction is an obstacle. At certain moments, it may be precisely what allows the user to understand what is about to happen, review a decision or retain control when it truly matters.

A good experience will not always be the one that asks the fewest questions, but the one that knows when asking makes sense.

From “Do you confirm?” to conditional permission

Asking for confirmation before every action can be a simple way to retain control, but it also has a limit.

If a system asks constantly, confirmation stops being a conscious decision and can become an automatic gesture.

In many cases, a more useful alternative is to allow the user to define in advance the conditions under which the AI can act.

It is not about granting general permission, but about setting specific limits.

“Do it if it costs less than 50 euros.”

“Book it only if it can be cancelled.”

“Reply automatically only to this type of message.”

“Reorganise my calendar, but do not move meetings with clients.”

This kind of interaction significantly changes the role of the interface.

We are no longer designing only the moment when someone presses “Confirm”. We are also designing the rules that define how far the system can go without asking again.

That requires those conditions to be understandable, visible and easy to modify.

The user should be able to know what they have authorised, under what circumstances it will apply and what exceptions they have defined. Otherwise, autonomy can quickly become difficult to anticipate.

An interesting question also emerges: authorisation does not have to be absolute.

It can depend on an amount, a recipient, a time, a task category or any other element relevant to that decision.

In that sense, designing autonomy is less like activating an automatic feature and more like defining the space within which the system can act freely.

The challenge is no longer simply to ask before doing something, but to allow each person to establish clearly when there is no need to ask them again.

The system must also know when to ask again

Giving an AI permission to act should not mean that permission remains valid indefinitely.

Conditions change.

The price, recipient, level of risk, available information or even the objective that made sense a few minutes earlier may change.

An action that fitted perfectly within certain conditions may no longer do so when the context changes.

That is why an autonomous system not only needs to know when it can act. It also needs to recognise when the permission it had is no longer sufficient.

Imagine that someone has authorised an automatic booking below a certain amount. If the price increases, the cancellation terms change or an additional cost appears, the system should be able to stop.

The same applies to actions that affect other people.

An automatic message may be perfectly acceptable in a familiar context, but perhaps not when the recipient changes, the content becomes more sensitive or the decision begins to have consequences that were not anticipated.

Here, a particularly important design responsibility emerges: defining which changes require the system to return the decision to the person.

It is not about making AI hesitate constantly, but about identifying the moments when proceeding would mean acting under conditions different from those the user accepted.

In that sense, autonomy is not only about proceeding without human intervention.

It is also about knowing when to stop.

A well-designed system does not demonstrate intelligence only when it solves a task by itself, but also when it recognises that the context has changed enough to ask again.

Conclusion

The evolution of artificial intelligence is often measured in terms of capability.

What it can do, how many tasks it can complete, how much context it can interpret or how far it can act without human intervention.

But from a design perspective, perhaps the most important question is another one.

Not how much an AI can do, but under what conditions it should be able to do it without us.

Because as systems gain autonomy, so does the need to define clear boundaries: when they can proceed, when they need confirmation, what conditions they must respect and at what point an authorisation ceases to be valid.

That means designing more than functionality.

It means designing permissions, exceptions, thresholds and moments when control returns to the user.

And that is where an important difference emerges between simply efficient automation and a genuinely well-considered experience.

The former tries to reduce human intervention as much as possible.

The latter understands that there are moments when intervening remains part of the value of the experience.

Designing autonomy, then, is not about removing the user from the flow.

It is about making a considered decision about when they can step aside and when they need to step back in.

Because a system does not show that it is well designed only when it knows how to act on our behalf.

It also does so when it knows how to recognise that the time has come to return the decision to us.

If an AI can complete an action without asking us, have we also designed the conditions that should require it to ask again?