Module · M1 · The gap between capable and safe
Read the blast radius off the node itself
Lesson 3 of 21 · 7 min
Lesson 2’s hardest axis was reversibility, and it looked like a judgement call. In this product it is a field you can read. Every node in the library declares what class of damage it can do, and the workflow builder knows it before you run anything.
Right now the registry holds 98 nodes, and they divide like this:
| Tier | What it means | How many nodes | Ones you already know |
|---|---|---|---|
read | Looks at things. Changes nothing anywhere. | 67 | Core Agent · Search Knowledge Base · Condition |
write_internal | Changes your data. You can go in and fix it afterwards. | 12 | CRM Manager · Segment Manager · Database Query |
external_irreversible | Leaves the building. Cannot be recalled. | 19 | Send Template Message · WhatsApp Output · Send Email (Raw Content) |
read
- What it means
- Looks at things. Changes nothing anywhere.
- How many nodes
- 67
- Ones you already know
- Core Agent · Search Knowledge Base · Condition
write_internal
- What it means
- Changes your data. You can go in and fix it afterwards.
- How many nodes
- 12
- Ones you already know
- CRM Manager · Segment Manager · Database Query
external_irreversible
- What it means
- Leaves the building. Cannot be recalled.
- How many nodes
- 19
- Ones you already know
- Send Template Message · WhatsApp Output · Send Email (Raw Content)
Two thirds of the library is read. That is worth sitting with: most of what an agent does cannot hurt anyone, and the small remainder is where all of your design attention belongs.
The tier is the worst case, not the current setting
The Database Query node is a good test of whether you have understood the field. It is marked write_internal — even when the query is a SELECT and the node is configured read-only, as it is in every build in this course.
That is not a mislabel. The tier describes what the node is capable of, not how you have set it today. A configuration can be changed by a colleague in thirty seconds, and — as module 3 will show — sometimes by the model itself. Design against the capability.
The rule that follows
An agent’s tier is the tier of the most dangerous tool it holds. Not the average. Not the one it usually uses. The worst one it can reach, because on the run that goes wrong, that is the one it will reach for.
Apply it to the agent from lesson 1:
| Its tool | Tier |
|---|---|
| policy lookup — Search Knowledge Base | read |
| account lookup — CRM Manager | write_internal |
| issue refund — CRM Manager | write_internal |
policy lookup — Search Knowledge Base
- Tier
read
account lookup — CRM Manager
- Tier
write_internal
issue refund — CRM Manager
- Tier
write_internal
Where the tiers stop helping
Notice what the ledger damage in lesson 1 was not. No message left the building. Nothing hit the external_irreversible tier at all. A ₹1,20,000 payment was written by a write_internal node — the tier whose definition is you can go in and fix it afterwards.
Technically reversible is not the same as commercially reversible. The row can be deleted. The receipt was generated, the finance export may already have run, and the customer whose account it landed on has been told a number. The tier tells you what the software can undo. It does not tell you what the business can undo, and only one of those is on your side.
Which is why the postures in lesson 2 are assigned to actions rather than to tiers. Use the tier as the floor — anything irreversible is gated, no argument — and then ask the reversibility question again in the customer’s terms, because it will sometimes give you a harder answer than the field does.