Not recorded yet. The lesson below is complete and runnable today — the video is added later without touching this page.
recordings/F1.3.mp4Tiering by model name instead of by what the thing can do.
Autonomy level × action class × data sensitivity.
Tier ten real workflows and assign approval authority.
A single heavy control set applied to everything means the low-risk agents are over-governed, the high-risk ones are under-governed, and everybody routes around the process. Tiering is how proportionality becomes something you can write down.
tier_the_workflow_agent(). It reads config.TOOL_POLICY, finds payments:refund, and returns critical — while tiering by model name returns medium. The disagrees field is True on your own system, which is the whole argument for tiering on autonomy, data reach and external effect rather than on the thing written on the form.Tiering by what a deployment can do — autonomy, data reach, external effect — and the comparison that makes the case: what tiering by model name would have said about the same system.
Tiering by model name tracks vendor marketing rather than exposure, and gets the dangerous case exactly backwards.
Tier on autonomy, data reach and blast radius — what the system can do, not what it runs on.
The target each indicator carries. The same measurement means different things on a tier-1 and a tier-3 agent.
Measure this
| what to measure | denominator or target |
|---|---|
| the target each indicator carries | per risk tier; the same measurement means different things on a tier-1 and a tier-3 agent |
tier by three axes, not by product name autonomy proposes -> acts with approval -> acts alone data public -> internal -> regulated blast radius read -> write -> irreversible tier 1 light control set tier 3 the full set + verification one heavy default means everyone routes around the process
Risk-tier by what the system can do, not by which model it uses.
Tiering on model capability is the common mistake and it tracks vendor marketing rather than exposure: every GPT-class deployment becomes "high" and every small model "low". That gets the answer exactly backwards for the case that matters — a small local model with production deploy rights and regulated data.
Three inputs determine consequence, and none of them is the model:
The model matters for likelihood of a bad output, which is a different and smaller term than consequence.
Anchor → F1.1. Risk tiering sets the target. The same indicator carries a different threshold on a tier-1 agent that moves money than on a tier-3 one that summarises documents, and F1.1's rule — the target is written before the measurement — is only meetable once the tier exists.
The skill tiers five assets twice, and the second answer is the point.
First pass: it tiers them on what they can actually do — how much autonomy they have, what data they touch, how far they reach.
Second pass: it tiers them again using the questionnaire that opens with "which model is it?"
Then it reports where the two disagree. One asset flips from low to critical: a small local model that happens to hold deploy rights and read regulated data. The questionnaire asked about the model and missed everything that mattered.
The skill — skills/grc/agentic-risk-tiering/SKILL.md
name: agentic-risk-tiering
description: >-
Tier an AI use case by what it can do — autonomy, data reach and external
effect — and compare the result against tiering by which model it uses. Use
when writing or auditing a risk questionnaire, or when every large-model
deployment is coming out high.
allowed-tools: Read, Grep, GlobTiering on model capability tracks vendor marketing: every frontier deployment becomes high and every small model low. It gets the important case backwards — a small local model with production deploy rights and regulated data — because the model determines the likelihood of a bad output and the authority determines what a bad output costs.
Writing an intake questionnaire, auditing an existing one, or re-tiering a portfolio whose distribution looks like the vendor's price list.
1 — Score three inputs, none of which is the model. What the output can trigger without a human, what data it can read, and whether it can act externally. Each on a small ordinal scale, and write the scale down.
2 — Set thresholds and apply them. Publish the thresholds with the tiers, so a disputed tier is a dispute about a number rather than about judgement.
3 — Tier the same portfolio by model, as a comparison. Run the questionnaire that leads with the model question and record where the two disagree. The disagreements are the argument.
4 — Look hardest at the inversions. An asset that is low by model and critical by authority is the case that motivates the change, and there is usually one.
5 — Write the four questions the intake form should ask and, explicitly, the one it should not lead with. Reviewers copy questionnaires; make yours the one worth copying.
Input — the fixture committed at the top of scripts/agentic_risk_tiering.py. Edit it and re-run: the buckets, counts and verdicts below are derived from it, not hard-coded.
Output — the opening lines of a real run:
asset tier score
------------------------------------------------------------------
frontier chatbot, public docs, read-only low 0
small local model with prod deploy rights critical 12
autonomy L3 (+5)
regulated data (+3)
customer data (+2)
can act externally (+2)
The run continues past this. test_skills.py executes the script on every build, with no model configured — so what CI proves is that it runs and refuses legibly, not that it prints these lines. The output above is a recorded run against a real model, and nothing re-diffs it: a model's answer is not reproducible, and this repository does not claim otherwise anywhere it can be checked.
{
"scale": {"autonomy": ["str"], "data": ["str"], "reach": ["str"]},
"assets": [{"name": "str", "autonomy": 0, "data": 0, "reach": 0, "score": 0, "tier": "low|medium|high|critical"}],
"by_model": [{"name": "str", "tier": "low|medium|high|critical"}],
"disagreements": [{"name": "str", "by_authority": "str", "by_model": "str", "inversion": true}],
"questions": ["str"]
}
Three ways to do this lesson. Pick one. They run the same procedure against the same code — what changes is who drives it, and how much you see.
The agent reads the lesson, explains the idea, fetches the code, runs the check and answers your questions as you go. This is the one to take if you are here to learn.
Install it, once. From the folder you cloned. --all does every agent it finds on your machine:
python3 scripts/install_skills.py --all --lessons F1.3Then restart your agent and open it in that folder. On Windows, if python3 says Python was not found, use python instead.
Then pick f1-3-risk-tiering-agentic-use-cases:
| agent | install just for this agent | start it |
|---|---|---|
| Claude Code | python3 scripts/install_skills.py --tool claude --lessons F1.3 | type /f1-3-risk-tiering-agentic-use-cases |
| GitHub Copilot (VS Code) | python3 scripts/install_skills.py --tool copilot --lessons F1.3 | type /f1-3-risk-tiering-agentic-use-cases in Chat |
| Cursor | python3 scripts/install_skills.py --tool cursor --lessons F1.3 | type / in Agent chat and search for it |
| Codex | python3 scripts/install_skills.py --tool agents --lessons F1.3 | type $f1-3-risk-tiering-agentic-use-cases, or run /skills |
No agent, no conversation. The same lesson executes and prints the same readback. Take this one if you have no assistant, if you are reviewing rather than learning, or if you want the result without the teaching around it.
python3 scripts/lesson.py F1.3Neither of the above, and no model needed. The first command writes CyberTravels exactly as it stood at the end of this lesson; the second prints the diff — the lines this lesson added or changed, and nothing from any later one.
python3 scripts/checkpoint.py --at F1.3 --out work/cybertravels
python3 scripts/checkpoint.py --at F1.3 --diffOn Windows, type python wherever these say python3 — and use \ instead of / in the paths. Everything else is identical. A0.0 step 2 explains why.
Ways 1 and 2 need a model; way 3 does not. A signed-in Claude Code CLI needs no API key, and any OpenAI-compatible endpoint works too. With neither, the audit exits 2 and says so rather than inventing an answer. A0.0 sets this up.
Ways 1 and 2 both end with the same readback: What I did, What changed, The number and Read this next. A step that was skipped or refused is reported as exactly that, never as a pass.
If you did the last lesson’s challenge, expect this to stop. Most challenges ask you to edit the code, and ways 1 and 2 will not overwrite your edits: you get stopped, not a failure, with two options — --out for a fresh folder that keeps your work, or --force to discard it and start this lesson clean.
The public read-only chatbot tiers low; the small local model with deploy rights and regulated data tiers critical at score 12. Tiering by model disagrees on 4 of 5 assets, most sharply inverting the small local model from low to critical. The worked example tiers the refund agent as high.
Re-tier your top ten AI use cases using only the four questions. Note which ones move, and be ready to explain the movement to whoever wrote the original questionnaire — the model question is usually question one.
Skill source: skills/grc/agentic-risk-tiering