Designing for delegation, and the three patterns it needs

Gartner projects that 40 percent of enterprise applications will contain task-specific AI agents by the end of 2026, up from under 5 percent in 2025.

That is a fast enough change that most of the interface patterns those applications need do not have established conventions yet, and teams are designing them from scratch under delivery pressure.

The shift underneath the numbers is a change in what a user is doing. In a conventional application, a user executes each step and the interface confirms each one. In an agentic application, a user states an outcome and the system plans a path toward it. The interface stops being a set of controls and becomes an account of what the system is doing on the user's behalf. Discoverability and efficiency matter less once the user has stopped clicking through the steps. What matters is whether the user can tell what is about to happen, whether they can stop it, and whether they can recover when the system gets it wrong.

Showing the plan before the action

The first pattern is separating planning from execution. The agent states what it intends to do as a sequence of discrete steps, and the user reviews that sequence before anything runs.

The value is not primarily safety, although it provides safety. The value is that a plan is legible in a way that a result is not. A user who reads seven proposed steps can correct step four, and a user who receives a completed outcome can only accept it or start again. Correction at the plan stage is also where the system learns what the user actually meant, because the gap between the stated goal and the proposed plan is where the misunderstanding lives.

Plans need to be written in the user's vocabulary rather than the system's. A step that reads "reconcile ledger entries for August" is reviewable. A step that reads "execute reconciliation job with parameter set 3" is not, and a user who cannot evaluate a step will approve it by default, which removes the point of showing it.

Signaling confidence honestly

The second pattern is confidence signaling, and it is the one teams most often get wrong. A system that presents every output with identical certainty trains users to either trust all of it or none of it, and both outcomes are bad.

Useful confidence signaling is specific about the source of the uncertainty. "This match is based on a partial name and a matching postcode" tells a user what to check. A percentage does not, because users have no calibration for what 82 percent confidence means in practice and will read it as either high or low depending on their mood. The design consequence is that uncertainty belongs at the level of the individual claim, not at the level of the response. One uncertain figure inside an otherwise sound summary needs to be marked as the uncertain figure.

An agent that acts on a person's behalf will act wrongly. The design question is what happens in the twenty minutes after that.

BrilliantUX editorial principle

Expanding autonomy at the user's pace

The third pattern is progressive delegation. The agent begins with narrow authority and requires approval for each action. As the user approves actions without correcting them, the system widens what it will do without asking, and shifts from an approval gate to a notification.

Practitioner reports on production agent interfaces describe higher adoption from this approach than from offering full autonomy at launch, and the mechanism is straightforward. The user's own approval history sets the pace, so the system earns permission rather than assuming it. Nielsen Norman Group's State of UX 2026 work identifies trust as the dominant design problem in AI experiences, and notes that users who have been burned by a premature AI feature resist adopting later ones. Progressive delegation is a direct answer to that, because it never asks for more trust than the user has already demonstrated.

The autonomy level has to be visible and adjustable at all times. A user who cannot see how much authority the system currently holds will assume the worst case, and a user who cannot reduce that authority will disable the feature.

Designing the undo

The last requirement is recovery, and it is the one that most often gets scheduled into a later release. Every action an agent can take needs a defined reversal, a record of what was changed, and a path from the notification of the action to its reversal that takes one step. Actions that cannot be reversed, such as sending an external email or submitting a filing, need a confirmation gate regardless of how much autonomy the user has granted, because the cost of the error is not symmetric with the cost of the extra click.

Teams starting an agent feature this quarter can get most of the way there by writing the reversal list first. It is a short document, it forces a decision about which actions are irreversible, and it usually changes the scope of what the agent is allowed to do at all.