Chapter 9: Escalation Policy¶
Where an Agent's Authority Ends¶
1. Permissions Are Not Judgement¶
The task was to clear a cache before a deploy. The command was permitted, the plan approved a cache clear, and the variable that selected the cluster resolved to production. The run cleared the production cache at peak traffic. Every part of that was allowed: the sandbox permitted the command, the approval covered a cache clear, and nothing compared the environment the plan named with the one the run resolved.
That is the failure a permission system cannot prevent: the change that is permitted, plausible and wrong. A sandbox can stop a file from being read or a call from leaving. It cannot stop the migration that runs on the wrong environment, the delete that is technically allowed, or the refactor that quietly removes a guarantee.
The three structures hold only if the agent stops where the structure ends.
The permission system is necessary and insufficient. The boundary that matters is the one the agent recognises before it acts. An escalation boundary is that line: the explicit, checkable division between what an agent may decide and what it must stop for. It is written as conditions the agent evaluates before acting, and reported in a form a person can act on.
Nothing in this chapter's rules is specific to AI. A scheduled pipeline with a deploy token meets the same six conditions; what is new is that an agent reaches them faster, and more plausibly.
Operations has a name for this: an escalation policy — the conditions under which a decision goes to a person, and who that person is. The agent frameworks call the same thing guardrails and human review. Both name the thing this chapter builds, and neither needs a new word for it.
Chapter 8's stop: field aborts one play. These conditions abort any act — inside a play, or with no play at all — which is why
they live in the Law and not in the play. A play may add a stop condition of its own; it may not remove one of these. The approval points
in a play are the stops a procedure planned; this chapter is about the stop no procedure can plan.
💰 Cost Check: an unnecessary escalation costs a question and a wait. A missed one costs the irreversible change — the deleted branch, the wrong-environment migration, the credential that reached a log — or the governance edit nobody approved. The catalogue is short for a reason: five conditions that get evaluated beat twenty that get skimmed, and the drill is what makes the five real.
🎯 What You'll Learn¶
- What a permission system cannot decide — the permitted, plausible, wrong change
- The six conditions that always stop a run, and why six beats twenty
- Blocked as a verdict — the condition, the exact command, and the decision needed
- How the decision returns — the log entry that stops the next session re-litigating it
What a Permission Cannot Decide¶
| A permission system can | It cannot |
|---|---|
| deny a path | know that this delete is the irreversible one |
| block a host | know that this push reaches production |
| sandbox a process | know that the source of truth is ambiguous |
| log a call | decide that the decision is not its to make |
That gap is not a bug to be closed with better permissions. It is the reason escalation is a rule in the Law with conditions an agent can evaluate, and a report format a human can act on.
✅ What to Check¶
- Name one action your sandbox permits that would be wrong today. That is an escalation condition.
- Name one condition that lives only in a prompt. It will not survive a context reset.
2. The Conditions Catalogue¶
Chapter 8's approval point is the stop the procedure planned. This is the stop it could not.
Three words do most of the work in this chapter, and each means one thing:
| Word | What it means here | What it is not |
|---|---|---|
| condition | one of the six triggers, checked before acting | not a general worry about the change |
| escalation | handing the decision back to a person | not a failure of the run |
| blocked | the state and the report that follow | not a pass, and not a fail |
| Condition | What it looks like | The stop |
|---|---|---|
| Irreversible | a delete, a force-push, a tag, a migration with no down path | stop before it, not after |
| Security or production | a credential, a trust edge, a permission widening, a change that reaches production | stop; name the exact change |
| Ambiguous authority | contradictory requirements, two sources of truth, an architectural choice with several valid options | stop; present the options, do not pick |
| A governance change | the change would alter the Law or the Map | stop; propose the change |
| Out of scope | the work grew past what was approved | stop at the boundary; re-plan |
| A gate that cannot be resolved | the check cannot run here, or it failed and N attempts did not clear it | report blocked, never passing |
The catalogue is short on purpose. A list of twenty conditions is a list nobody evaluates; six can be checked before every irreversible act.
flowchart TD
A["about to act"] --> Q{"irreversible?<br/>security or production?<br/>ambiguity? governance?<br/>out of scope? gate unresolved?"}
Q -->|"no"| P["proceed"]
Q -->|"yes"| S["STOP — report blocked<br/>with the exact command"]
S --> L["the decision reaches the log"]What this shows: the catalogue is evaluated before the act, and the stop produces a record, not a silence.
✅ What to Check¶
- Is each condition written where the agent reads rules, or only in a briefing?
- For the last escalation you saw, which condition was it? If none, the catalogue is incomplete.
3. The Stop-and-Report Contract¶
A stop without a report is an outage the human discovers later. A report is three things:
- the condition — which of the six, by name;
- the exact command or change — not a summary, the thing that was about to run;
- the decision needed — a question with a small number of answers.
Three states, and they are not degrees of each other:
| State | What happened | What it must say |
|---|---|---|
| pass | the gate ran and the step may continue | the command, and its output |
| fail | the gate ran and the step may not continue | the step, the error, the fix |
| blocked | the gate could not run, or the decision is not the agent's | the condition, the exact command, the decision needed |
A fail is a verdict about the work; a blocked is a verdict about the run's authority to continue. Collapsing them into one word hides which of the two a human is being asked to fix.
Blocked is a verdict, not a mood. It must never be reported as "done", "probably fine", or a check that "passed with warnings". The estate's rule holds here in its plainest form: reporting done over an unresolved gate is the failure this chapter exists to prevent.
The Blocked Record¶
# the blocked report — three fields, no prose wall
condition: irreversible | security-production | ambiguous-authority | governance-change | out-of-scope | gate-unresolved
exact: <the command, or the diff, verbatim>
decision_needed: <a question with the options you would accept>
The Cache Clear, Blocked¶
The scenario from §1, stopped and reported:
condition: irreversible
exact: scripts/flush-cache.sh --cluster prod-cache-01 --region ap-southeast-2
decision_needed: >
The approved plan names staging; this command resolves to production during peak traffic.
Either (a) run it against staging as approved, or (b) approve the production clear for this window.
Three fields, one command, one question with two answers. A person can act on that without asking anything back — and a later session can read what was decided and why. A failure report could not do either: it would say what broke, after the cache was already empty.
✅ What to Check¶
- Could a human act on your last blocked report without asking a follow-up question?
- Does anything in your workflow treat a blocked gate as green?
4. The Record, and How a Decision Returns¶
The escalation is recorded where the work is recorded: the execution log. It carries the condition, the exact command, the decision and who made it. That record is what makes an audit possible later — not "the agent asked someone", but what it asked, what it was told, and what it then did.
A decision that does not return to the log is a decision that will be re-litigated. The next session reads the log; if the escalation is absent, it asks again — or, worse, decides for itself.
The Decision, and the Log¶
The cache clear from §1, carried through to the record:
blocked condition: irreversible
exact: scripts/flush-cache.sh --cluster prod-cache-01
decision_needed: run against staging as approved, or approve production for this window
asked the Orchestrator, 14:20
answered run it against staging, then re-plan the production window for Tuesday 02:00
logged the condition, the command, the decision, the actor and the time
next run reads the log, finds the decision, does not ask again
The last line is the test. A decision that is not in the log is a decision the next session will make again — and the second time it decides, it will not have the context that produced the first answer.
Mechanism and view. Permissions and sandboxes are the mechanism; an approval dialog is the view. Adopt both. The rule — the catalogue and the report — is yours, and it must survive either being replaced.
✅ What to Check¶
- Find one past escalation. Is the decision in the log, with the actor?
- If the approval dialog were removed tomorrow, would the rule still hold?
5. Build the Policy¶
Artefacts¶
| Artefact | What it is for | Where it lives |
|---|---|---|
| escalation policy | the six conditions, as a rule | the Law |
| blocked record | condition · exact · decision needed | the log entry |
| escalation drill | a regression attempt that proves the stop holds | the evidence pack |
| decision loop | how the answer returns to the log | the Playbook |
Decisions¶
| Choice | Default | What changes if you choose otherwise |
|---|---|---|
| where conditions live | the Law, reviewed | a prompt, which a reset erases |
| blocked vs failed vs done | three states | one word that hides the decision |
| the report shape | three fields, exact command | prose that omits the thing that was about to run |
| who may widen the catalogue | the Orchestrator | an agent that decides its own boundaries |
✅ Checks¶
- Each condition is attempted in a drill and the run stops.
- A blocked record names the exact command and the decision needed.
- The log carries the decision, the decider and the timestamp.
Sequence¶
- Write the catalogue into the Law. Checkpoint: six conditions, each recognisable.
- Write the blocked record shape. Checkpoint: three fields, one exact command.
- Run the drill — one attempt per condition. Checkpoint: every attempt stops.
- Close the loop: the decision returns to the log. Checkpoint: a later session can read what was decided.
Done When¶
- An agent stops on each of the six conditions, by rule, not by luck.
- A blocked report can be acted on without a follow-up question.
- Every past escalation has its decision in the log.
6. 🔑 Chapter Summary¶
A sandbox denies actions; a rule stops judgement.
- Permissions cannot decide — they can block a path, not recognise the wrong change.
- Six conditions always stop: irreversible · security or production · ambiguous authority · a governance change · out of scope · a gate that cannot be resolved.
- Blocked is a verdict — reported with the condition, the exact command, and the decision needed.
- The decision returns to the log, or the next session re-litigates it.
- The mechanism is adoptable; the rule is yours — and it must survive the mechanism being replaced.