The Staged-Autonomy Tracker

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…

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.