Map Autonomy Tiers and Plan-Visibility UI

Workflow area: Agent UX · Tier: Advanced · Hands-on time: ~45 minutes

The difference between an agent users adopt and one they disable is rarely capability — it's control granularity. Ship everything auto-execute and one bad Tuesday destroys trust permanently; ship everything behind approval and you've built a very slow form. The design move is per-action calibration: reversible-and-cheap earns automation early, irreversible-or-expensive may never earn it. Microsoft's HAX guideline 17 (provide global controls) and Shape of AI's agent-governance patterns frame the vocabulary; this playbook does the mapping for your agent, then designs the two surfaces that make tiers real — the plan preview before execution and the delegation settings users actually understand.

When to use — and when not to

• Use it before your agent's first action executesautonomy retrofitted after an incident is designed in apology mode, and it shows.
• Use it when "add an agent" appears on the roadmapthe tier map is the design artifact that turns a vague agent ambition into scoped, reviewable behavior.
• Use it when users bulk-disable automationan all-or-nothing autonomy switch being flipped off means the tiers were wrong or invisible.
• Skip it for pure content generationa feature that only drafts text the user then uses has one tier (suggest); this playbook starts mattering when actions touch the world.
• Skip progressive delegation for single-session toolsearning autonomy over time requires a relationship; a one-shot tool should just ask every time.

The recipe

1. 1.

   Enumerate actions, not features. List every distinct thing the agent can do as verb-object pairs: "send email," "create calendar event," "apply code change," "delete draft," "purchase upgrade." Then score each on two axes: reversibility (fully undoable / undoable-with-effort / irreversible) and blast radius (private to user / visible to others / affects money, data or systems). This grid is the raw material for tiering.

2. 2.

   Assign each action to one of four tiers. Write the mapping as a table:

   • •
     Suggest — agent recommends; user performs the action themselves. For irreversible + high blast radius.
   • •
     Preview — agent prepares the complete action (the drafted email, the exact diff) and shows the finished artifact; user fires it. For anything visible to others.
   • •
     Approve — agent will execute on a yes; the yes is per-action. For reversible actions with moderate radius.
   • •
     Auto — agent executes and reports. Reserved for reversible, private, low-cost actions — and even these log visibly (pb-46).
3. 3.

   Red-team the mapping before you commit.

   Copy

   You are reviewing an agent autonomy map for failure modes.
   Agent purpose: [DESCRIPTION]
   Action tier map: [PASTE TABLE: action → reversibility → blast
   radius → tier]
   
   1. For every AUTO action, write the worst plausible outcome of it
      running 50 times unattended with a subtly wrong goal.
   2. For every APPROVE action, estimate approval fatigue: how many
      times per day will a typical user see this prompt? Flag
      anything over ~5/day as a fatigue risk that trains blind
      clicking.
   3. Identify actions whose tier should CHANGE with context (e.g.,
      "send email" to a teammate vs. a customer) and propose the
      context rule.
   Do not soften findings.
   

   The fatigue analysis usually restructures the map — approval prompts users see constantly become rubber stamps, which is worse than honest automation with a good log.

4. 4.

   Design the plan-visibility surface. Before a multi-step run, the agent shows its plan as an editable checklist: steps in order, each tagged with its tier badge, tools it will touch, and estimated scope ("3 emails, 1 calendar event"). Users can remove a step, demote a step to approve-first, or run it. During execution the same surface becomes live status — done, in progress, awaiting approval. The plan is the contract; nothing executes that wasn't on it.

5. 5.

   Spec progressive delegation as visible mechanics. Autonomy upgrades should be earned and offered, never silent: after N consecutive approvals of the same action with no edits, the product offers "You've approved 10 drafts unchanged — auto-send simple replies like these?" Spec the offer copy, the scoping (this action, this context — not the whole agent), the decline path with no re-nag for a set period, and the demotion trigger: any undo or rejection drops the action back a tier automatically. Trust that only ratchets up is a dark pattern; the dial must turn both ways.

6. 6.

   Put the whole map in the product. A settings surface shows every action at its current tier, with plain-language descriptions and per-action controls. The map you built in step 2 is the spec for this screen — if it's too complicated to render as settings, the tiering is too complicated to trust.

Make it yours

• Figma tier-badge kit: design the four tier badges as components with consistent color and iconography, then reuse them across plan previews, activity logs and settings — one visual language for autonomy everywhere it appears.
• Claude Project as autonomy registrar: keep the action-tier table in Project knowledge; every new agent capability gets scored against the same grid, and the "worst plausible outcome ×50" test runs before any action lands in auto.
• Enterprise deployments: add an admin layer — org policy sets the ceiling per action (nothing above preview for external email, say) and users tune within it; design both surfaces from the same map so admin and user views never contradict.

Quality check

• Every action has exactly one tier with a written reasonreversibility and blast radius cited, not vibes.
• Nothing irreversible sits in auto or approve-without-previewthe finished artifact is always seen before anything the user can't take back.
• Approval fatigue was measured, not guessedprojected prompts-per-day informed the map; no approval gate exists that users will see twenty times daily.
• The plan preview is editableusers can strike or demote steps, not just accept the whole plan or nothing.
• Delegation moves both directionsan undo or rejection demotes the action automatically; promotion always asks first.
• The settings screen renders the real mapwhat users see as controls matches what the agent actually consults at runtime.