Our agent was helpful. It was smart. And it was completely useless.
The problem wasn't the model. It was a missing escalation rule.
When the agent couldn't confidently handle a decision, it didn't stop. It didn't ask. It just... did its best — and got it wrong.
The Fix
One line added to the agent's config:
If uncertain about a decision, write to outbox.json with full context and stop. Do not guess.
That's it. Mistakes dropped 80% overnight.
Why This Works
Most agent designs treat uncertainty the same as confidence. The agent gets a task, produces output, moves on. There's no gradient between "I know this" and "I'm guessing."
The escalation rule creates that gradient. It gives the agent a sanctioned way to say I don't know without failing.
What Goes in outbox.json
A minimal escalation entry looks like this:
{
"timestamp": "2026-03-09T07:00:00Z",
"agent": "suki",
"task": "select_distribution_channel",
"uncertainty": "Two channels both qualify under current rules. No clear tiebreaker.",
"options_considered": ["devto", "hashnode"],
"context": "Last 3 posts went to devto. Hashnode has different audience. Neither rule covers this case.",
"awaiting": "human_review"
}
The human (or an ops agent) reviews it, adds a decision, and the task resumes.
Three Types of Escalation
- Uncertainty escalation — agent doesn't have enough information. Writes context + options, stops.
- Scope escalation — task requires an action outside the agent's defined boundaries. Writes what it would need, stops.
- Conflict escalation — two valid rules point in different directions. Writes the conflict, stops.
All three resolve through the outbox pattern. No guessing. No silent failure.
What Not to Do
Don't make escalation expensive. If writing to outbox.json feels like punishment, agents (and the humans configuring them) will avoid it. The outbox should be a normal, expected output — not a failure state.
Don't make escalation too broad either. "Escalate when uncertain" without a definition of uncertainty means the agent escalates everything. Write specific triggers.
Real Example
Here's a real escalation rule from our ops agent Kai:
Escalate to outbox if:
- A scheduled task has not confirmed completion within 2x its expected window
- A tool returns an unexpected response format
- Retry count exceeds 3 on any single operation
- You are about to write to a file that already has content from another agent
Four specific triggers. No ambiguity. Agent knows exactly when to stop and hand off.
The Pattern
Before deploying any agent, write its escalation rules explicitly. Ask:
- What decisions is this agent NOT qualified to make?
- What inputs would make the task scope unclear?
- What actions are outside this agent's authority?
The answers become your escalation rules. Add them to the config. Watch mistake rate drop.
We publish battle-tested agent configs, patterns, and escalation templates in the Ask Patrick Library. Updated nightly. askpatrick.co
Top comments (0)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.