Can autonomy controls stay distinct rather than collapse into one toggle?

AI UX Playground names "Agentic UX" as a category to "Use when the product can take actions (send, spend, edit, delete) and you need to decide how much authority is safe," and lists a set of distinct patterns for setting that authority rather than a single switch: "Autonomy Budgets: Time- or action-bounded unattended runs," "Human in the loop: Require human approval before AI acts," "Suggest / Confirm / Execute: Three autonomy modes for AI agents," and "Per-Action Autonomy: Autonomy scoped per capability, not per app." Alongside these it lists a parallel set of patterns for bounding cost rather than action: "Cost Transparency," "Running Meters," "Processing Time Estimates," and "Hard Budget Ceilings."

Each named pattern is pitched as its own interface element — a time or action limit, an approval gate, a mode selector, a per-capability scope setting, a running cost meter, a hard ceiling — rather than facets of one autonomy dial. The library's own phrasing for "Per-Action Autonomy," scoped "per capability, not per app," states directly that autonomy is a setting attached to each thing an agent can do, not a single property of the product as a whole.

This supplies an implementable UI vocabulary for what Can we design AI autonomy separately from capability? argues conceptually: both treat autonomy as something set per capability rather than fixed to a product or model, with user role (approving, confirming, or letting the agent run unattended) as the lever. It also gives concrete interface shape to How can autonomous agents act safely within defined boundaries? — the Spec's ending condition and cost/time limits map onto this library's Autonomy Budgets, Running Meters, and Hard Budget Ceilings patterns, and its default ban on high-risk action without explicit authorization reads as a system-level instance of Human in the loop. Where the Spec warns that an over-narrow scope could habituate the user to automatically confirming all requests, this library's Suggest/Confirm/Execute names the middle mode between unattended autonomy and per-action confirmation that such habituation would otherwise erode.

The excerpt is a pattern library's naming and one-line definitions, not a study: it gives no evidence that these patterns are used together in shipped products, that users distinguish per-action scoping from per-app scoping in practice, or that naming a pattern as "Hard Budget Ceilings" or "Human in the loop" makes it any less vulnerable to the habituation or oversight-erosion problems named elsewhere in this library's neighboring material. What it establishes is a shared vocabulary of separately implementable autonomy controls, not a demonstration that naming them resolves the design problem.

• Should agent control be one setting or several separate controls? — Evidence for A's claim: aiverse independently splits autonomy control into separate patterns rather than one setting
• Should agent autonomy be a continuous slider or fixed levels? — Contradicts A's composable controls by proposing one continuous slider instead of several separate toggles