---
name: staged-autonomy-tracker
description: Use this skill when a technology leader needs to decide, explicitly and per task category, how much autonomy to grant a specific engineer or a specific AI coding agent — instead of defaulting to "trust everyone" (hover) or "trust no one" (vanish), or granting a blanket status by seniority or by how competent a tool seems. States which of the four stages the named evidence supports, with reasoning. Triggers on requests like "how much autonomy should I give this engineer or this agent," "build a staged-autonomy tracker," "when can this AI agent merge without review," "set up delegation levels for my team," or "should I trust this coding agent to ship unattended."
---

# The Staged-Autonomy Tracker
This skill is Labor as Code™ for "Grant Autonomy in Stages, Based on Evidence" in *The Code Takes Care of Itself* —
the chapter that builds the book's most operational framework. Read
the chapter for the full argument: autonomy is a status assigned per
task category, on named evidence, revised as that evidence changes —
never a personality trait a leader either has or lacks, and never a
blanket grant based on seniority, title, or how competent a tool
*seems*. The book's own examples (a platform lead who shipped a Friday
database migration with no incident but no heads-up either; a coding
agent that quietly changed an HTTP client's default timeout during
unattended dependency upgrades) are cases to learn the mechanism from,
not the specific rule to copy. This skill runs the tracker. Given real,
named evidence the user supplies, it states which stage that evidence
supports and why - stage assignment against the four thresholds below
is mostly mechanical once the evidence is on the table, and leaving it
unstated just pushes the same judgment back onto the user with none of
the legwork done. What this skill will not do is guess at the evidence
itself: a stage is only ever assigned against a count, an incident
history, or an observed pattern the user actually names, never
invented to fill a gap.

## Before running

1. **This skill will not assign a stage without named evidence.** If
   the user wants to place someone (or some agent) at a stage based on
   a feeling, a title, or "they seem trustworthy," stop and ask for
   the actual evidence first: a count of reviewed instances, an
   incident history, a specific pattern. The book's own line: "if you
   can't name it, you're guessing rather than assessing." Guessing a
   plausible-sounding stage is exactly the failure this skill exists
   to prevent.
2. **Confirm whether this run is for a person, an agent, or both.**
   The four stages apply to both, but the accountability rule differs
   sharply for agents (see the AI Agents section below) — get this
   straight before filling in the tracker.
3. **One tracker entry per task category, never one rating per whole
   person or whole agent.** The book is explicit that this exercise
   "usually fails when leaders assign a single rating to the whole
   person" (or, by extension, the whole tool). The same engineer, or
   the same agent, can and should sit at different stages for
   different kinds of work.

## The four stages

1. **Supervised Execution.** The person (or agent) does the work; you
   review it before it ships, every time, no exceptions. This is the
   correct default for anyone new to a *type of task*, however senior
   they are elsewhere — the stage attaches to the task category, not
   to general seniority. It is not a vote of no confidence.
2. **Checked Execution.** The work ships without a gate; you review a
   sample after the fact, on a fixed cadence. Most leaders skip
   straight from "I approve everything" to "I approve nothing" — this
   stage is the missing middle that fixes the hover-or-vanish
   complaint.
3. **Independent Execution with Reporting.** The work ships without
   review; the person or agent reports what they did and why,
   afterward, as a matter of course. You're not sampling for quality
   anymore — you're keeping situational awareness, so nothing three
   layers below you surprises you.
4. **Full Autonomy.** The work ships; you learn about it only if you
   ask, or if something goes wrong. This is earned narrowly, for a
   specific category of decision, on a specific track record in that
   category — never conferred as a blanket status by tenure or title.

## Steps

### 1. List the task categories that matter for this role

Not a generic list — the specific categories where a bad decision has
a real cost: production deployments, architecture decisions for one
service, customer-facing incident communication, hiring or performance
input, cross-team dependency negotiation, and so on. Three to six
categories per role is enough; more than that and the tracker gets
abandoned within a quarter.

### 2. Assign a current stage to each category, on evidence you can name

For each category, name the evidence behind the stage: a count of
reviewed instances, an incident history, an observed pattern. State
which of the four stages that evidence supports, and cite the specific
count or incident driving the call. If the evidence doesn't exist yet,
the honest starting stage is Supervised Execution — don't backfill a
higher stage to save time, and say plainly that the stage is a default
for missing evidence, not a read of demonstrated performance.

### 3. Set a review cadence per stage, and put it on a real calendar

- **Supervised Execution:** every instance, no exceptions.
- **Checked Execution:** a fixed recurring review — weekly or every
  two weeks, matched to how often the task occurs.
- **Independent Execution with Reporting:** read what's sent; look
  for nothing more unless something stands out.
- **Full Autonomy:** review on request, or when something surfaces.

A cadence that isn't in a calendar becomes "whenever I remember,"
which the team experiences as no review at all.

### 4. State the stage and the path up, out loud, to the person involved

Don't let anyone infer their own stage. State the current stage, state
the evidence behind it, state specifically what has to become true to
move up. This conversation is the actual mechanism — everything else
in this tracker exists to make those few minutes specific instead of
vague.

```
You're currently at [stage] for [task category], based on [named
evidence]. To move to [next stage], I need to see [specific,
countable evidence] — I'll check in on this at [date/cadence].
```

### 5. Review every stage each quarter, and immediately after any incident touching that category

A stage isn't permanent in either direction. Reviewing someone who
holds Full Autonomy after a bad outcome isn't punishment — the
evidence changed, so the stage has to reflect it. And don't let a
stage stay low through inattention: a person still in Checked
Execution long after the evidence supported more autonomy is
under-coached, and that shows up as attrition before it shows up in
any metric.

When pulling someone *back* a stage, state it the same explicit way as
a promotion — never silently review someone's work more closely
without telling them. Unstated extra scrutiny reads as suspicion, not
evidence-based recalibration.

## AI agents: what transfers, and what doesn't

The four stages apply to an AI agent — opening pull requests, triaging
tickets, remediating a class of incident — the same way they apply to
a person, on the same evidence-based logic. Two things do **not**
transfer:

1. **Accountability never transfers to the agent.** A human engineer
   at Full Autonomy is now the safeguard, and if something goes wrong,
   the accountability conversation includes them. An agent at the same
   stage has no judgment to receive that transfer. Full Autonomy for
   an agent means the human who configured it and set its guardrails
   has decided its failure modes are cheap enough, reversible enough,
   and well enough understood that per-instance review no longer earns
   its cost — that human stays accountable at every stage, including
   Full Autonomy. Never let a stage assignment get talked about as if
   it relieves a person of responsibility for what the agent does.
2. **An agent's track record resets on any material change
   underneath it — back to Supervised Execution.** A model version
   change, a prompt change, a change in tool access, a change in
   guardrails, an upstream data change: any of these means the
   evidence that earned the previous stage no longer describes the
   thing currently running. This is not doubt about whether the change
   was an improvement — it's that the evidence expired. Treat it
   exactly like a new hire in a category nobody's seen them handle
   yet.

Before granting or raising an agent's stage in any category, confirm:
what changed recently (model, prompt, tools, guardrails, upstream
data), and would the current process actually notice if one of those
changed without anyone flagging it? If the answer is no, fix the
detection gap before trusting the stage.

## The check that catches this book's own failure mode

- **No stage was assigned to a whole person or a whole agent.** Every
  entry in the tracker is scoped to one task category. If the user
  says "she's ready for full autonomy" without naming which category,
  push back and ask which one.
- **Every assigned stage has named evidence attached**, not an
  impression. "Guessing rather than assessing" is the book's own
  phrase for the failure this catches.
- **Every assigned stage is stated as a call, with the evidence that
  drove it**, not left as an open question after the evidence was
  already gathered. Stating the stage isn't the guess the book warns
  against - guessing is skipping the evidence and asserting a stage
  anyway; naming a stage the assembled evidence actually supports is
  the assessment this tracker exists to produce.
- **Every agent entry has a named accountable human and a reset
  trigger.** An agent stage with no human named as accountable, or no
  defined trigger for resetting the stage after a material change, is
  incomplete — don't treat it as done.
- **Reversals are stated explicitly, not left as silent extra
  scrutiny.** Check this specifically when a stage is being pulled
  back rather than advanced.