Disclose by Stakes: Progressive Disclosure for the Age of Agents
Nov 2026What progressive disclosure really is, where it fails, and what changes when software works for you in the background.
Why this is on my mind
Most AI products I use swing between two bad extremes: a blank prompt box with every capability hidden, or a settings page with everything exposed. Progressive disclosure is the old idea that sits between them, and it's getting a second life.
What's true right now
The definition is crisp. Nielsen Norman Group describes it as showing core features first and moving the rest to a secondary level, which improves learnability, efficiency of use, and error rate. It stresses that you have to get the split between initial and secondary features right. It also separates staged disclosure (wizards, one step at a time) from progressive disclosure proper.
It's old, and it works. Jakob Nielsen's recent piece on progressive disclosure and AI agents notes that Apple's 1992 Macintosh Human Interface Guidelines already devoted a section to it. He also recounts a classic 1984 study where a "training wheels" interface hid error-prone features, and the control group spent nearly a quarter of its time recovering from errors the restricted interface had made unreachable.
It fails in predictable ways. The wrong split is the main one: bury a daily-use feature and every visit pays an interaction tax. Nielsen also warns not to confuse it with adaptive menus that reshuffle options based on recent usage.
Agents change the shape of the problem. In the same article, Nielsen notes that a long-running agent has many phases, such as launch, progress, interruption, partial result, handoff, and resumption. That means disclosure is no longer only about where controls live on a screen. It's also about what you show at each moment in a task's life.
Stakes in a hypothetical agent task
Illustrative: my own sketch, not a sourced fact.
One imagined run. Picture an agent asked to tidy a shared folder and tell the team. It reads files, which is quiet. It proposes new names, which deserves a one-line summary. It moves files others rely on, which should show what moves where. It posts to the team, which should show the message and the audience. Four steps, four levels of detail. I made it up to see whether the rule gives a sensible answer, and it does, though a real workflow will have messier edges than four tidy steps.
What the user sees. Most of that run is a calm stream they can ignore. The interface only gets louder at the two steps where a mistake would reach other people. The user never has to ask for detail, because the screen asks for their attention in proportion to what could go wrong. It is worth noticing what is missing, too. There is no settings page asking the user to decide in advance what they want to see, which is the clutter I was trying to avoid.
Where stakes can go wrong
My opinion, based on the tradeoffs above.
Misjudged stakes. The rule only works if the system classifies steps correctly. A step it calls minor that turns out to be costly will pass silently, which is worse than uniform detail because it also removes the user's habit of checking. I would treat the classification itself as something to review, not assume. That is also the case for testing a planted bad step, as described above. It is the cleanest way to find out whether the silent steps really were safe to be silent.
Stakes are not the same for everyone. Something trivial for one person may matter a lot to another. I do not have a clean answer to that. A cautious default that the user can raise or lower seems the least bad option, though it brings back some of the settings clutter I started out avoiding. Even then, I would want to see how people react when a step they expected to be quiet suddenly gets loud. That could feel helpful, or it could feel like an alarm, and I do not know which.
My hypothesis
This section is my opinion, not a sourced fact.
For agents, the right disclosure rule is stakes, not frequency: show more detail the more irreversible or costly the next step is.
The classic rule says surface the features most people use most often. For an agent, the risk of a step matters more than how common it is. Reading a file can run silently. Drafting a message can show a one-line summary. Sending it, spending money, or deleting something should open up the full detail: what will happen, to whom, and how to undo it.
That gives a simple, testable design principle: the interface's level of detail should scale with the blast radius of the action. Quiet by default, loud when it counts.
How I'd test it
Take one agent workflow with ten steps. Classify each by reversibility and cost. Build two versions: one that shows uniform detail, one that scales detail by stakes. Measure how often users catch a deliberately planted bad step in each.
What would change my mind
If users find variable detail unpredictable and prefer a consistent level of information, the cost of surprise may outweigh the benefit, and a consistent "review before send" gate might be better.
What I would do first on a real product
My opinion, a sketch of a first step rather than a method I have run.
List the irreversible steps. Before building anything adaptive, I would walk through the existing flow and mark every step that cannot be undone or that spends something. That short list is the real design brief, and it is usually shorter than people expect. Doing less at first also keeps the argument honest. If the stakes version wins, it wins on the part I changed, not on a pile of unrelated polish.
Make those steps unmistakable, leave the rest alone. I would resist redesigning the quiet steps at all in the first pass. If the loud moments are clear and the rest stays unchanged, I can compare against the uniform version in the test above without too many variables moving at once. It is a modest step, but the irreversible list is the part nobody argues with, so it is a good place for a team to start agreeing.
References
- Nielsen Norman Group, Progressive Disclosure
- Jakob Nielsen (UX Tigers), Progressive Disclosure: From Training Wheels to Week-Long AI Agents
- UXPin, What Is Progressive Disclosure in UX?