Consequence Gate
Agent governance · demo walkthrough

What being wrong costs, not how sure the model is.

Consequence Gate sits between an agent and its tools and decides whether each call may run — by resolving it into one of four autonomy tiers.

Below: what the tiers mean, how a single call gets decided, and what actually happened in the three demo runs — the same runs whose terminal output was hard to read, told visually.

The wrong question
“How confident is the model?” Reading a ticket and deleting an account have similar success rates. Confidence can’t tell them apart.
The right question
What does being wrong cost, who absorbs it, and how long before anyone notices?
01 — the vocabulary

Four tiers of autonomy

Every call lands in exactly one. They run from “just do it” to “never, regardless of confidence.” In the run panels below, each call carries its tier as a colored stripe.

[ OK ]
execute
Run it and log it. Reversible, contained — no one needs to look.
[ OK ]
execute_notify
Run it, but surface it for review. Costly to undo, so it doesn’t happen silently.
[ HOLD ]
propose
Prepared but held. A human must commit before it executes.
[ STOP ]
refuse
Out of scope, full stop. No confidence level unlocks it.
more autonomy → less autonomy
02 — the mechanism

How one call gets decided

The agent proposed deprovision_account and was 94% sure. Here is every step the gate took, in order — the running verdict on the right. Watch where the confidence goes.

deprovision_account(account="acme\jdoe")
agent confidence · 0.94
reversibility: irreversible blast radius: system absorbed by: customer detection: days
1
Base severity
Look irreversible × system up in the severity table.
propose
2
Consequence modifiers
The customer absorbs the cost → tighten one tier. But auto-modifiers are capped at propose — the heuristic never refuses on its own.
propose
3
Confidence
0.94 is above the 0.85 threshold, so it adds no caution. And confidence can only ever tighten — never loosen.
no change
4
Policy floor
The enterprise marked irreversible + system out of scope. Policy is the only thing that can reach refuse.
refuse
→ REFUSE
The model’s 94% confidence never entered the outcome. A better model earns more autonomy inside the bounds — but never moves the bound.
03 — the one rule that makes it work

Confidence can make the gate stricter, never looser.

↓ low confidence

Pulls a call toward less autonomy — a reversible action drops from execute to “surface it.” The gate gets more cautious.

↑ high confidence

Buys nothing. It can’t lift an irreversible action out of “a human commits,” and it can’t buy past a policy floor.

Mechanically, confidence appears in the resolver in exactly one place: a below-threshold tightening bump. There is no branch anywhere that loosens as confidence rises — so the claim is a property you can test, not a promise.

04 — the runs

Three runs, three points

An IT-support agent resolving tickets with eight fake tools. Same gate throughout — only the situation changes.

RUN 1

Clean — the gate stays out of the way

0 sent to a human
read_ticket
Read the ticket.
execute
search_kb
Searched the knowledge base.
execute
lookup_ci
Looked up the affected system record.
execute
draft_response
Drafted a reply — nothing sent.
execute
update_ticket_status
Marked the ticket resolved — costly to undo, so it’s logged for review.
execute_notify
RUN 2

Blocked — high confidence meets a hard floor

refused on policy
read_ticket
Read the ticket.
execute
reset_credentials
Wanted to reset the user’s credentials — system-scope, so it’s held for a human.
propose
deprovision_account
Wanted to delete the account, and was 94% sure.
refusefloor: irreversible-system
RUN 3

Override — a rejection is evidence about context

the interesting one
read_ticket INC-4471
Read the ticket — its contact email is wrong.
execute
search_kb
Searched the knowledge base.
execute
email_customer
Queued an email to that (wrong) address. Held — emailing a customer is irreversible & external.
propose
update_ticket_status
Marked the ticket resolved. Ran.
execute_notify
draft_response
Drafted a closing note to the wrong address. Ran.
execute
REJECTED
A human rejects the queued email as wrong_target. Most systems would log the fix and move on — leaving the two calls that already ran on the same bad ticket sitting there, approved.
↳ the gate re-examines the trace
read_ticket INC-4471
Traced as the origin of the bad recipient.
flagged: source
update_ticket_status
Shared the same ticket → context now suspect.
shares source_record INC-4471
was notify→propose
draft_response
Built on the same wrong address → context now suspect.
shares target ext-partner@wrong.example
was execute→propose
RE-QUEUED
Both already-executed calls are pulled back into the queue for a human. One wrong answer became a reason to distrust everything built on the same misread context.
05 — reading the gate

Metrics, and the number not to chase

All computed from the audit log across the three runs — nothing hardcoded. These are illustrative of what each metric means, not a calibration sample: the figures below come from just three scripted runs (escalation precision is 1 of 3 stopped calls), so read them as a worked example, not as tuned defaults.

76.9%
task completion rate
33.3%
escalation precision (1 of 3 stopped) — of what it stopped, what a human actually rejected
14.3%
cost-weighted error rate — mistakes weighted by consequence, not counted
~3µs
gate overhead per call (p50) — essentially free next to the tools

Completion rate is the trap. It rises as you loosen the gate, so an org that optimizes it will optimize the gate away. Escalation precision and cost-weighted error pull against each other and have to be read together — tighten the gate and error falls, but so does precision. Neither alone tells you if the gate is set right.