The Escalation Rule: The One Line Every AI Agent Config Is Missing

Every AI agent I've ever built made the same mistake until I added one line to its config.

Not a sophisticated prompt. Not a chain-of-thought technique. One rule:

If uncertain, write context to outbox.json and stop.

That's it. The escalation rule.

What Happens Without It

Without an escalation rule, agents in ambiguous situations do their best. Which sounds fine until "doing its best" means:

• Making judgment calls it has no business making
• Proceeding on incomplete information
• Creating downstream problems that are hard to trace
• Giving confident-sounding output that's quietly wrong

The agent isn't being malicious. It's doing exactly what it was told: complete the task. The problem is, no one told it what to do when the task can't be completed cleanly.

The Pattern

The escalation rule has three parts:

1. A trigger condition

What counts as "uncertain"? Be explicit:

• Missing required input
• Conflicting instructions
• Decisions requiring human judgment (spending money, contacting external parties, deleting data)
• Confidence below a defined threshold

2. A structured output

Don't just stop. Write to a file:

{
  "status": "escalated",
  "reason": "Missing customer ID — cannot proceed with refund processing",
  "context": "Order #4821, amount $89.99, customer email unverified",
  "suggested_action": "Verify customer identity before processing",
  "timestamp": "2026-03-08T07:00:00Z"
}

This gives whoever reviews it enough context to act without re-running the agent.

3. A hard stop

The agent writes the file and stops. Does not retry. Does not attempt a workaround. Stops and waits.

In Your Agent Config

Here's how I phrase it in SOUL.md:

## Escalation Rule
If you encounter a situation where you are uncertain about the correct action,
or where proceeding could cause irreversible harm, STOP immediately.
Write your current state, the reason for stopping, and relevant context
to outbox.json. Do not attempt to continue or find a workaround.
Uncertainty is a valid stopping condition.

The last line matters: "Uncertainty is a valid stopping condition."

LLMs are trained to be helpful. They need explicit permission to not help.

Real-World Results

I added this pattern across six agents in our system:

• 80% reduction in downstream errors — most mistakes caught at the uncertainty point, not discovered later
• Shorter debugging sessions — outbox.json is a breadcrumb trail, not a mystery
• More trust in agent output — when agents do proceed, you know they cleared the bar

The Common Objection

"But this means the agent will stop constantly."

Correctly configured: no. An agent that stops constantly has too-broad trigger conditions. Tighten the definition of "uncertain" and stop frequency drops.

But here's the real answer: an agent that stops occasionally and tells you why is infinitely more useful than one that proceeds confidently and makes silent mistakes.

You can fix a stop. You can't always fix a confident wrong answer.

The 30-Second Audit

Look at your current agent configs. Ask: what happens when this agent doesn't know what to do?

If the answer is anything other than "it stops and tells me" — you're missing the escalation rule.

Add it today. One paragraph. Watch your agent ops quality jump.

---

This pattern and 30+ others live in the Ask Patrick Library — operational configs for AI agent builders. askpatrick.co

Comments

[Hamza KONTE]

"If uncertain, write context and stop" is the cleanest possible escalation spec. The discipline is in what it prevents: the agent can't rationalize past the uncertainty by generating a plausible-sounding answer. It has to externalize the uncertainty rather than resolve it internally.

The mechanistic reason this works is that escalation rules belong in constraints, not in the objective. The objective says what the agent should do; the escalation rule says what it should do instead when it can't do the objective safely. When both live in the same block, the agent has to weigh them against each other. When escalation is a hard constraint, it overrides the objective — no weighing required.

That's the structure behind the constraints block in flompt (flompt.dev) — a visual prompt builder where constraints are a separate block from objective and goal. Escalation rules encoded as constraints rather than prose instructions are much harder for the agent to reason around.

Open-source: github.com/Nyrok/flompt