L8Lesson 5

Define the Blast Radius

After this, you'll be able to classify any task into one of three risk tiers, add appropriate approval gates for higher-risk operations, and describe exactly what would happen if an unsupervised step went wrong.

Before you start

Before diving in, complete Build the Checkpoint and Replay so you can calculate the real recovery cost for each tier before you decide where to place approval gates.

The idea

You build a GitHub integration for your agent: it can create issues and post comments. You run a loop overnight to triage 50 backlog items. Monday morning: 50 GitHub notifications sent to your teammates, each tagged with an automated comment. The integration worked exactly as designed. You forgot to add a gate.

Blast radius is the maximum damage a single bad step can cause before you can intervene. There are three tiers. Tier 1: read-compute-write on your own codebase. Worst case: a bad file change that git reverts in 30 seconds. Run freely, no gates. Tier 2: external API calls. Sending emails, creating issues, pushing to a remote branch, calling a paid API. Worst case: an action visible to other people, a cost you did not intend, a state change you cannot easily undo. Needs an explicit approval gate before each external action. Tier 3: shared state or production. Database writes, production deploys, messages to real users. Worst case: data corruption or user-facing impact that may be irreversible. Requires a human in the loop, full stop.

Here is the before and after: a five-skill harness has refactor-code (Tier 1, no gate), run-tests (Tier 1, no gate), create-github-issue (Tier 2, approval gate before POST), send-slack-message (Tier 2, approval gate before send), and update-database (Tier 3, never run in a background agent). Each Tier 2 step prints the planned action and waits for an explicit confirm response before executing.

Most harnesses start entirely in Tier 1. Then one integration adds a Tier 2 step, and a loop that runs 50 iterations now calls an external API 50 times. The gate is what separates a useful tool from a Monday-morning incident.

Try it (18 min)

Watch out for

Classifying API reads as Tier 1. Any call to an external API, even a read, can hit rate limits, trigger logging, or expose credentials if the call is malformed.
Forgetting that loops multiply blast radius. A step that calls an API once is different from that same step inside a loop that runs 50 iterations.
Approval gates that just print 'about to do X'. An approval gate requires a response before execution, not just a log line.
Putting Tier 3 operations in background agents. Any step that modifies production state or sends messages to real users must have a human in the loop.
Treating git push as Tier 1. Pushing to a shared branch is shared state modification. That is Tier 2 at minimum.

Paste this into Claude:

I want to classify the blast radius of my current agent setup. Here are the tasks or skills I run with Claude: [list 3-5 tasks or skills you use regularly, e.g. 'refactor code', 'create GitHub issues', 'send Slack messages', 'update the database', 'run tests']. For each one, tell me: (1) Which tier (1, 2, or 3) does it fall into? (2) What is the worst-case outcome if this step runs with bad input? (3) What approval gate, if any, should be added? Then rewrite the riskiest skill to include an explicit approval gate that shows me the planned action before executing it.

What good looks like:

You classified each task into Tier 1, 2, or 3 with a specific worst-case scenario
At least one of your tasks moved from 'no gate' to 'approval gate' based on the classification
The rewritten skill shows the planned action and waits for confirmation before any Tier 2 or Tier 3 step
You can state the blast radius of your entire harness in one sentence
You identified any task you assumed was Tier 1 that is actually Tier 2 or 3

What a good response looks like:

Blast radius classification for a 5-skill harness:

1. refactor-code: Tier 1. Worst case: bad file change. Git revert in 30 seconds. No gate needed.
2. create-github-issue: Tier 2. Worst case: 50 duplicate issues created by a loop. Gate required: show planned issue title+body and wait for confirmation before POST.
3. run-tests: Tier 1. Worst case: test run exits with errors. No external state modified. No gate needed.
4. send-slack-message: Tier 2. Worst case: message sent to wrong channel or 20 times in a loop. Gate required: show recipient + message text, wait for confirmation.
5. update-database: Tier 3. Worst case: wrong rows updated with no rollback. Human required. Do not run in background agent ever.

Rewritten create-github-issue with gate:
```
step 3 (create issue):
  BEFORE executing: display planned action:
    "About to create GitHub issue in [repo]:
    Title: [title]
    Body: [first 100 chars]...
    Labels: [labels]
  Type 'confirm' to proceed or 'cancel' to abort."
  WAIT for response before calling GitHub API.
```

Blast radius of entire harness: Tier 2 (GitHub + Slack integrations with gates).

When this breaks

Breaks when loops multiply a single Tier 2 step because one external call becomes fifty without re-passing the gate, and the integration that worked once now produces a Monday-morning incident.
Breaks when an approval gate only prints the planned action because nothing actually waits for a response, and the agent proceeds before you ever see the message.
Breaks when a Tier 3 operation runs inside a background agent because the human-in-the-loop boundary disappears and an irreversible action runs without anyone watching.

Claude can do it for you

Say to Claude: 'Here are the steps in my harness: [list steps]. For each step, classify it as Tier 1 (own codebase), Tier 2 (external API), or Tier 3 (shared state or production). For every Tier 2 and Tier 3 step, write the approval gate that shows the planned action and waits for confirmation before executing.'

You can now

Classify each task in your harness into Tier 1, 2, or 3 with a specific worst-case scenario, and rewrite at least one Tier 2 or 3 step to wait for an explicit confirm response before executing.

Key takeaways

Know the blast radius before you remove the supervision. Tier 1 can run free. Tier 2 needs a gate. Tier 3 needs a human. Misclassifying one step is how incidents happen.

Tier 1 is your own codebase. Tier 2 is external APIs. Tier 3 is shared state or production.
An approval gate is a pause that waits for an explicit response, not a log line that announces an action
Loops multiply blast radius. A Tier 2 step inside a 50-iteration loop is fifty external actions, not one.
Tier 3 operations never belong in background agents. Human in the loop is the safety boundary.

Go deeper

I want to classify the blast radius of my current agent setup. Here are the tasks or skills I run with Claude: [list 3-5 tasks or skills you use regularly, e.g. 'refactor code', 'create GitHub issues', 'send Slack messages', 'update the database', 'run tests']. For each one, tell me: (1) Which tier (1, 2, or 3) does it fall into? (2) What is the worst-case outcome if this step runs with bad input? (3) What approval gate, if any, should be added? Then rewrite the riskiest skill to include an explicit approval gate that shows me the planned action before executing it.

Blast radius classification for a 5-skill harness: 1. refactor-code: Tier 1. Worst case: bad file change. Git revert in 30 seconds. No gate needed. 2. create-github-issue: Tier 2. Worst case: 50 duplicate issues created by a loop. Gate required: show planned issue title+body and wait for confirmation before POST. 3. run-tests: Tier 1. Worst case: test run exits with errors. No external state modified. No gate needed. 4. send-slack-message: Tier 2. Worst case: message sent to wrong channel or 20 times in a loop. Gate required: show recipient + message text, wait for confirmation. 5. update-database: Tier 3. Worst case: wrong rows updated with no rollback. Human required. Do not run in background agent ever. Rewritten create-github-issue with gate: ``` step 3 (create issue): BEFORE executing: display planned action: "About to create GitHub issue in [repo]: Title: [title] Body: [first 100 chars]... Labels: [labels] Type 'confirm' to proceed or 'cancel' to abort." WAIT for response before calling GitHub API. ``` Blast radius of entire harness: Tier 2 (GitHub + Slack integrations with gates).

Say to Claude: 'Here are the steps in my harness: [list steps]. For each step, classify it as Tier 1 (own codebase), Tier 2 (external API), or Tier 3 (shared state or production). For every Tier 2 and Tier 3 step, write the approval gate that shows the planned action and waits for confirmation before executing.'