Build the Agent Autonomy Ladder — Written Rungs, Earned Promotions, Automatic Demotions

Workflow area: Policy & Governance · Tier: Advanced · Hands-on time: ~45 minutes

Autonomy creep is the default. An agent starts drafting PRs, someone enables auto-approve for tests, then for lint fixes, then a Friday deploy goes wrong and nobody can say who decided the agent could do that. The ladder exists so that every increase in autonomy is a decision with a name, a date, and evidence attached — and every incident has a pre-agreed rung to fall back to.

When to use — and when not to

• Use it before the first agent gets write access to anythingrepo, ticket tracker, or terminal. The ladder is cheap to write at rung zero and expensive to retrofit at rung three.
• Use it when teams already run agents at inconsistent autonomyone team auto-merging, another hand-approving every edit — and you need one vocabulary before you can have one policy.
• Use it after any agent near-missthe post-incident conversation "what rung was it on, and did that rung's criteria hold?" is infinitely better than "how did this happen?"
• Skip it for autocomplete-style assistancea human accepting inline suggestions is ordinary authorship covered by pb-27; the ladder governs software that acts.
• Skip inventing more than four or five rungsa ten-step ladder is a ladder nobody can remember, and unmemorized policy is unenforced policy.

The ladder

The recipe

1. 1.

   Write the rung definitions into a one-page governance doc. Adapt the four rungs above, then add the two tables that make it real: which code areas cap at which rung (your pb-27 risk tiers map directly — CRITICAL paths cap at rung 2, no-AI zones at rung 0), and which named person can approve a promotion (you, or an EM per team with your review).

2. 2.

   Define rollback triggers per rung — before you need them. Automatic demotion one rung, no meeting required, when any trigger fires: an agent action causes a Sev-2 or worse; any action outside the allowlist; revert rate exceeding baseline for two consecutive weeks; an audit-log gap (pb-30). Write the re-promotion condition next to each trigger so demotion is a reset, not a punishment.

3. 3.

   Map rungs to tool enforcement. Ladders enforced by memory fail. Claude Code permission modes, allowed-tools lists, and hooks; Copilot and Cursor workspace and policy settings; branch protection and environment-scoped credentials — configure each so the tool physically cannot exceed its rung. Have Claude draft the mapping:

   Copy

   Here is our four-rung agent autonomy ladder: [PASTE DOC].
   Tools in use: [Claude Code / Copilot / Cursor / CI system].
   
   For each rung, list the concrete settings that enforce it in each
   tool: permission modes, allowed tools, branch protections, env
   scoping. Mark [GAP] where a rung cannot be technically enforced
   and only process enforces it. Do not invent settings that do not
   exist in these tools.
   

   The [GAP] lines are your risk register — every gap needs a compensating check, usually an audit-log review.

4. 4.

   Run promotions as written decisions. A promotion request is five lines: agent and scope, current rung, evidence against exit criteria, requested rung, approver. Keep them in the governance doc's history. Thirty seconds of writing buys you a complete autonomy audit trail.

5. 5.

   Revisit the ladder monthly for the first two quarters. Agents and their tooling change fast; a ladder written in January governs different capabilities by June. The review is 15 minutes: any triggers fired, any promotions granted, any rung definitions that no longer match reality.

Make it yours

• Small team or startup: one ladder for the whole org, you are the sole promotion approver, and the governance doc is a README in the infra repo. The discipline that matters most is the automatic demotion — small teams are most tempted to "just this once" past an incident.
• Large org or GCC: rungs become platform presets teams inherit (paved-road agent configs at each rung), promotions above rung 2 need a second approver outside the requesting team, and client-scoped work caps at whatever rung the client's AI addendum permits (pb-33).
• Regulated environment: cap production-touching action classes at rung 3 indefinitely, map each rung to your change-management classes so auditors read it natively, and retain promotion records with the same policy as change approvals.

Quality check

• Every running agent has a rung on paperan agent you cannot place on the ladder is at rung unknown, which is the most dangerous rung.
• Exit criteria are counts and thresholds, not vibes"we feel good about it" promotes agents; "20 PRs, revert rate ≤ baseline" promotes evidence.
• A demotion has actually happeneda year of ladder with zero demotions means either flawless agents or unwatched triggers; check the triggers.
• Tool settings match the docquarterly, diff the actual permission configs against each rung's mapping; drift here is autonomy creep in its native habitat.
• The team can recite the ladderask an engineer what rung their agent runs at; a blank look means the ladder governs a document, not behavior.