Frameworks Library

    AI Governance · Evolved from Access Control & Permissioning

    Agent Autonomy Tiers

    Four declared tiers — T0 Retrieval, T1 Suggestion, T2 Supervised action, T3 Delegated action — governed by a single ship gate: declare the tier, spec the eval for that tier, name who can stop it, and re-attest when tools, prompts, context, or model change.

    Maturity: AdvancedReversibility: LowAI Risk: HighOversight: High
    Steal the kit

    Executive Guidance

    How to hold this framework as a leader

    Autonomy is not a spectrum to be argued case by case. It is four declared tiers. T0 Retrieval fetches and summarizes; it does not recommend and it does not change state. T1 Suggestion recommends; a human must accept before anything happens. T2 Supervised action acts only after a human approves that specific action. T3 Delegated action acts within a documented boundary, requires an executive sponsor and a kill switch, and is a governance event rather than a product update.

    One ship gate governs all four. Declare the tier. Spec the eval for that tier. Name who can stop it. Re-attest when tools, prompts, context, or model change. Pair the tier with The Tool Contract, which fixes what the agent may touch, and The Context Contract, which fixes what it may see, remember, and cite. A tier claim unsupported by those two contracts is a claim, not a control.

    When to Apply

    • Any agent capable of taking action beyond retrieval
    • Customer-facing or regulated workflows involving automation
    • Internal agents with access to sensitive data or systems

    AI-Era Notes

    Autonomy tier is a product decision, not a technical one. It carries governance, liability, and support implications that must be reviewed by legal and executive stakeholders.

    Key Trade-off

    Autonomy accelerates value but expands blast radius; kill-switch authority must be pre-assigned.

    Operating Sequence

    The order in which to install the framework

    1. 01Assign every agent capability a tier — T0, T1, T2, or T3 — before build is scoped.
    2. 02Write the eval set for that tier: success, safety, adversarial, and regression cases proportionate to the actions permitted.
    3. 03Name the person who can stop it, the time-to-rollback, and the executive sponsor required at T3.
    4. 04Bind the tier to a Tool Contract and a Context Contract; the ceiling of both must be at or below the declared tier.
    5. 05Re-attest the tier whenever tools, prompts, context sources, or the underlying model change. Tier transitions are launches.

    Key Artifacts

    The documents this framework produces

    Tier Declaration

    The declared tier (T0–T3) for each capability, with date and declaring owner.

    Owner: Product

    Tier Eval Spec

    Eval set and pass threshold proportionate to the actions the tier permits.

    Owner: Product + AI/ML

    Stop Authority & Rollback Runbook

    Named kill-switch owner, time-to-rollback, escalation SLA, and T3 executive sponsor.

    Owner: Operations + Product

    Operating Checklist

    What "good" looks like when installed

    Declare the tier

    • Every capability carries an explicit T0, T1, T2, or T3 declaration with a date and an owner.
    • T0 capabilities cannot change state; T1 cannot act without human acceptance.
    • T2 approval is per action, not a standing blanket approval.
    • T3 has a documented boundary and a named executive sponsor.

    Spec the eval

    • The eval set matches the tier: broader actions require safety, adversarial, and regression coverage.
    • Pass thresholds are written down and owned before release.
    • Blast radius of a worst-case action at this tier is documented.

    Name who can stop it

    • Kill-switch authority is named and reachable, with a stated time-to-rollback.
    • Escalation events and response SLAs are defined and rehearsed.

    Re-attest

    • Tools, prompts, context sources, and model versions are reviewed on change.
    • The Tool Contract and Context Contract ceilings remain at or below the declared tier.
    • A tier increase is processed as a launch, not a configuration change.

    Common Antipatterns

    • Undocumented tool access granted to agents
    • No defined threshold for human escalation
    • Missing kill-switch authority or runbook

    Boardroom Questions

    • What tier — T0, T1, T2, or T3 — is every customer-facing agent we operate?
    • Which agents run at T3, who sponsored them, and who can stop them today?
    • When did we last re-attest a tier after a model, tool, or context change?

    Pairs With

    Model Evaluation FrameworkRisk & Compliance Checklist