The Autonomy Slider
We've been designing agents as if autonomy were a property of the system. It isn't. It's a control — and most products haven't shipped one.
I've been sitting in product reviews for agent features lately, and there's a question I've started asking that nobody seems to have a good answer for.
"How much is this agent allowed to do on its own?"
The team will look at me, glance at each other, and walk me through what their agent does. They'll show me the demo. They'll trace the happy path where the user asks and the agent answers and the answer is correct. I'll ask again, slightly differently. "Sure — but how much is it allowed to do? Where's the line between suggesting and acting? Who set the line? Can the user move it?"
What I get, almost every time, is a kind of polite shrug. The agent does what it does. There's a system prompt somewhere that limits some things. The Pro plan unlocks more. Beyond that — the question hasn't really been answered, because nobody framed it as a question.
That's the thing I want to talk about. We have been designing agents as if autonomy were a property of the system. It isn't. It is a control. And until we treat it as one, we will keep shipping products where the most consequential decision about the user's experience — how far the system is allowed to go without checking in — is the one nobody actually made.
The Binary We Keep Defaulting To
The dominant shape of AI products in 2026 is a binary. There's an "agent mode" where the system runs and the user watches, and there's an "assistant mode" where the system suggests and the user accepts. Two presets. Two product surfaces. Two pricing tiers, often.
That's not an autonomy spectrum. That is two settings on a control that should be continuous.
Michael Albada's Building Applications with AI Agents names this directly. He calls it the autonomy slider, and the framing is simple: users shouldn't be forced to choose between full manual control and full autonomous execution. They should be able to give the system as much freedom as the context justifies. Sometimes that's suggest and wait. Sometimes that's do and tell me. Sometimes it's a middle setting — do, but stop before anything irreversible. Sometimes it's per-action: read freely, write only with approval.
You read it and think: of course. We've been doing this in software forever. Confirm before delete. Auto-save but ask before send. The browser doesn't decide for you whether links open in a new tab — you configure it. The terminal doesn't decide for you whether rm prompts — you set it.
Then you look at agent products and find almost none of them expose autonomy as a control. Either the system runs and the user observes, or it suggests and the user accepts. The slider is missing because the design conversation never produced it. Trust got treated as a marketing problem instead of an interface problem.
Three Things I've Stopped Treating as Settings
These used to feel like settings problems — switches a power user might find buried in preferences. They're not anymore. They're the actual shape of the product, and treating them as anything less ships a product that's quietly making a decision for the user that should have been theirs.
1. Autonomy is per-action, not per-product
The first move I've started insisting on, and that I think the whole industry will be making within a year, is unbundling autonomy from the product surface and binding it to the action.
The instinct is to set autonomy at the system level. The agent is either trusted to run or not trusted to run. You pick a tier in onboarding, or the SKU decides for you, and that setting applies to everything the agent might do during the session.
That setting is wrong on its first action. A coding agent that's trusted to read files freely is not the same agent that should be trusted to push to main. A scheduling agent that can suggest a meeting time isn't the same one that should be allowed to book on the CEO's calendar without confirmation. The level of trust isn't a property of the agent. It's a property of what the agent is about to do.
The model that works, the one Albada keeps circling back to in different forms, is to bind autonomy to the action class. Reads — wide latitude. Reversible writes — moderate latitude, summary after. Irreversible writes — confirmation before. External communication — almost always confirmation before. Spending money — always. Deleting things — always.
This is not a UX framework. It is a policy. And the policy is the product. A team that hasn't written it down has a product where the agent improvises the policy in the moment based on whatever the model felt like, and the user finds out which actions need confirmation only by being surprised by ones that didn't.
The exercise that's changed the most agent products I've seen this year is the one where you sit with the team and, for every action the agent can take, place it on the slider. Read this. Edit that. Send. Schedule. Pay. Each action gets a default level, an explicit reason, and a path for the user to change it. Most of those actions have never been categorized. They've been left to vibes. Until they're written down, the autonomy of your product is whatever the model decided to do last.
2. Trust is calibrated, not given
The second move is harder to operationalize, but it's the one users feel most.
The standard pattern is to ship the agent with a default autonomy level — usually one set by what felt demo-impressive in the boardroom — and then let users complain it down. They turn off the agent feature. They cancel the auto-approve. They write angry posts about how the system did something they didn't ask for. The product team interprets this as adoption friction and tries to lubricate the experience. The autonomy stays put. The complaints get louder.
The pattern that works is the opposite. Start the slider low. Let trust earn the user up.
Albada calls this trust calibration, and it works because it matches how humans actually decide to extend authority. We don't grant new employees full latitude on day one and revoke it when something goes wrong. We give them small, observable assignments and watch what they do. Their successes earn them more rope. Their misses cost them some. The autonomy gradient is the record of their performance against our expectations over time.
Agent products that get this right have three properties. They start at a setting where the agent is more cautious than the user wishes. They make it cheap and obvious for the user to grant more autonomy when a category of action proves itself. And they preserve the user's ability to reset — to walk the slider back down after a miss, without losing everything else.
The agent products that get this wrong all share one feature: they treat autonomy as a feature flag set at install. You either trusted the system enough to install it or you didn't. There is no record. There is no gradient. There is no way for trust to compound.
I now believe that the trust gradient — the artifact that records what level of autonomy this user has granted this agent for this class of action over time — is going to be the most important data structure in the agentic UX of the next five years. It is the thing that lets the system grow into doing more, instead of having to fight for its initial level of trust every session.
3. Reversibility is the natural gradient
The third move is the one that lets you actually draw the slider's shape, instead of having to negotiate every action separately.
The instinct is to sort actions by impact. How important is this thing the agent is about to do? Important things require approval. Unimportant things don't. That's the rule. It sounds correct. It does not work, because impact is a property the agent can't reliably estimate. The agent doesn't know that this meeting is the board meeting; doesn't know that this file is the contract. Impact is contextual. The agent will guess, and it will guess wrong sometimes.
The thing the agent can reliably know is whether what it's about to do is reversible.
Reversibility is structural. The agent can know if it's writing to a database that has soft-delete versus one that doesn't. It can know whether it's calling an idempotent API. It can know whether the message it's about to send is in draft or in an outbox that flushes immediately. Reversibility isn't a property the agent has to estimate. It's a property of the operation itself.
If you draw the autonomy slider against reversibility instead of importance, the policy almost writes itself. Fully reversible actions — wide latitude, no confirmation, full undo. Reversible-with-effort — wide latitude, summary after, easy revert. Reversible-only-by-apologizing — confirmation before. Irreversible — confirmation before, with a beat of friction proportional to the consequence.
This is, by the way, the move that explains why "agent mode" feels safe inside a sandbox and unsafe outside one. The sandbox is making everything reversible. The autonomy was never the variable. The reversibility was.
A team that hasn't categorized its actions by reversibility doesn't know what its autonomy slider should look like. It can't. The slider's shape comes from the structure of the operations underneath it. Drawing the slider before you've done that work produces a slider that's pretty in mockups and incoherent in production.
The Failure Mode I Watch For
The thing that worries me most about all of this isn't bad action. Bad action is obvious. The agent does something visibly wrong, the user notices, the team learns.
It's plausible action. The agent takes a step that looks reasonable at a glance and is wrong in ways the user discovers later. It sent the message to the right person but with the wrong commitment. It moved the meeting but only some of the attendees got the update. It updated the record but to a value that's just slightly off-policy. It paid the invoice for the right amount to the wrong vendor.
Plausible action is what plausible output was for content generation, except worse, because the artifact isn't a paragraph the user can reread. It's a state change in the world. The reread happens when someone else notices something is off. By then, the autonomy that produced the bad action is buried under three more layers of action that the user also didn't review, because the system trained them not to.
The fix isn't more review. We will not out-review the rate of agent action. The fix is making the policy unambiguous enough that the wrong action is structurally harder than the right one. Tighter reversibility classes. Higher friction at the irreversible edges. Lower friction in the reversible middle, so the user spends their attention budget where it actually buys something.
Every action without an explicit autonomy class is a place the agent will improvise. Every irreversible operation that lives behind the same affordance as a reversible one is a place the user will eventually click through what they shouldn't have. Every "trust me, I'm an agent" UX is borrowing against a future apology.
The boring conclusion of all of this is that the most important agent design work right now is not a more delightful chat surface or a more clever tool selection. It is classifying every action your agent can take by reversibility, binding the autonomy slider to those classes, and giving the user a path to walk the slider in both directions.
That is structural work. It is unglamorous. It is also the work that determines whether your agent product becomes something users grant more authority to over time, or something they uninstall after the first apology.
What I'm Practicing
The thing I do differently now, on every project where there's any chance an agent will be taking action on a user's behalf, is this.
Before I sketch a screen, before I open Figma, I sit down with the team and ask four questions about the agent we're designing.
What can the agent do? Not "what should it be able to do," not "what's our long-term vision." What are the concrete actions, today, in scope. If the answer comes back as a category — "manage the user's calendar" — I push until we have verbs. Read. Suggest. Create. Update. Delete. Send. The category was the assumption that produced the ambiguity. The verbs are what we can actually design against.
For each action, what's its reversibility class? Not "is this important?" — not yet. Can it be undone, and at what cost? Some of these answers will surprise you. Most teams discover at least one action they thought was safe that turns out to write through to something they can't pull back. Those are the actions where the slider needs to default to ask.
What's the default level for each class, and what's the path to change it? The default is the thing the user will actually live with for the first three months. If we set it where the boardroom demo feels best, we'll be revising it after the first incident. If we set it where the cautious user feels safe, we'll have a product the eager user can ask for more from. The path to change is what makes the slider a slider instead of a setting buried in preferences.
Where will the agent get wronger over time if no one is watching? Action sprawl. Default drift — the team quietly nudging the slider toward more autonomy because complaints went down and adoption went up, without noticing the silent failures climbing. New actions getting added to the system without being classified, defaulting to whatever's nearest. Trust extended by the user for one action quietly applying to actions they would not have approved. Every agent product has these. Most teams don't track them. Naming the leak is the first step toward plugging it.
These are not UX questions. They are policy questions, dressed in design clothing. They are also, almost word for word, the questions a serious operations leader would ask about a new piece of automation entering their stack. The frames transfer. The discipline transfers. What's new is that we're applying them to something the rest of the industry is still calling just the AI.
The hardest part of accepting that autonomy is a control is what it does to the marketing of agent products. Marketing wants a clean message. Our agent does this for you. The slider is structurally hostile to that message, because the slider says: it does some of this for you, some with you, and some only when you say so — and where the line falls is your call to make.
That's harder to put on a billboard. It's also the truth. The products that win the next several years of agent UX are going to be the ones whose teams are willing to put that complexity in front of users — and design it so beautifully that the complexity feels like control, not friction.
If autonomy is going to be the central variable of the next decade of product design — and it has very little choice now — the question is whether the people who understand the user design the slider deliberately, or whether someone downstream defaults it under pressure. The ones who understand the user are us. The slider is right in front of us. It just doesn't look like the work we've been calling design.