An AI agent unblock checklist template starts from a simple observation: a block is supposed to stop an agent, but it is not supposed to strand the team. Gartner projects that 40% of enterprise applications will incorporate task-specific AI agents by 2026, up from under 5% in 2025 — which means far more blocked actions, on far more teams, with nobody sure what reopens them.
When a governance control stops an agent and the only message is "blocked," the owner has to reverse-engineer the cause. Was it a missing identity? An expired grant? A ceiling? That guessing is its own risk: one developer documented a runaway agent loop burning over $700 in 72 hours with no budget controls at all. A system that can block but cannot explain itself invites the opposite failure — someone disables the control to get work moving again. The unblock checklist is what makes a block survivable: every stop arrives with the exact evidence that would reopen the action.
The principle: a block is a to-do list, not a dead end¶
The rule underneath is fail-closed. When required evidence is missing — identity, grant, approval, budget headroom, or a terms record — the action is blocked. It is never degraded to a warning. Every block persists an audit row with the actor, action, target, outcome=blocked, timestamp, and the exact reason. And every block tells the owner, in plain language, exactly which piece of evidence would unblock it.
That last sentence does the work. It turns "debugging an error" into "completing a checklist." Blocked actions are never retried automatically, either: a retry requires new evidence, not a timer. If nothing has changed, retrying just writes another blocked row and teaches the team to ignore them.
Start from the plan bound¶
An unblock checklist can only name evidence the system actually checks, so it is built from the plan bound — the bounded unit of work the Playbook requires before anything runs. A plan bound records 13 fields: plan_id, owner_identity, agent_identity, workload, data_class, resources, time_window, location, egress, storage, cost_ceiling, expiry, and grant_refs. Every block type below is one of those bounds failing, or one of the hard gates the plan cannot supply on its own. If a block cannot be traced to a bound or a gate, the checklist cannot name its unblock evidence — and that gap is a design bug to fix, not a mystery to live with.
The AI agent unblock checklist: block types and the evidence that reopens them¶
For each block type, write the unblock evidence in advance, in the checklist, before the block ever fires in production.
- No recorded identity. The acting agent has no stable, owner-scoped identity, or the identity is not in the identity registry. Unblock evidence: a recorded identity in the format
agent:[OWNER]/[NAME], with owner, date issued, and status in the registry. Anonymous, shared, or unregistered actors are rejected at the dispatch path — there is no warning version of this block. - Missing or expired grant. No grant covers the capability and scope, or the grant has passed its expiry. Unblock evidence: a grant record naming capability, scope, issuing owner, dates issued and expiring, and the identity it is issued to — issued by the grant authority, never auto-granted.
- Missing hard-gated approval. The action is one that always requires a recorded human approval: moving money or committing spend above the threshold, accepting contracts or terms, external outreach, accessing credentials or secrets, changing agent permissions or grants, or any action with legal or regulatory consequences. Unblock evidence: a recorded approval with approver identity, timestamp, action reference, and decision. The acting agent can never approve its own action.
- Plan ceiling reached. Spend counted against the plan in real time has hit its
cost_ceiling. Unblock evidence: new budget headroom — which means a hard-gated approval to raise the ceiling, with a recorded reason. Alerts at thresholds are information; the block at the ceiling is the control. - Plan or grant expired. The plan's
expiryortime_windowhas closed, or a referenced grant has lapsed. Unblock evidence: a renewed plan or grant with a future expiry. A changed bound means a new plan, not an edit to the expired one in place. - Missing terms record. The action accepts terms or carries legal consequences and no terms record exists. Unblock evidence: the signed terms document plus the approver identity, recorded outside the audit log itself — audit data never contains secrets or credential and terms material.
- Action outside plan scope. The action reaches for a higher
data_classthan the bound records, a domain outside theegressallowlist, a location outside the bound, or storage beyond its scope. Unblock evidence: a revised, newly approved plan that explicitly covers the wider scope. Widening scope is a permission change, and permission changes are hard-gated — it is never a quiet configuration tweak by the agent that got blocked.
What a good block message contains¶
The checklist only works if the block message carries it to the owner at block time. A good block message names six things: the actor (which agent identity attempted the action), the action, the target, the exact reason (which bound or gate failed), the named owner who can supply the evidence, and the exact evidence that would unblock it, in plain language. "Access denied" contains none of these and helps no one. A block message that ends with "provide X and this reopens" is governance as a to-do list instead of a maze.
Every one of those elements also lands in the audit row. Audit rows are hash-linked and append-only, and blocked or rejected outcomes require a reason — so the block, the evidence that reopened it, and the eventual outcome form one verifiable chain a reviewer can replay later.
Anti-patterns that quietly reopen everything¶
- Auto-retry on a timer. Nothing about waiting supplies missing evidence. Retries without new evidence are prohibited: the block persists until the evidence changes.
- Warning instead of block. Warning-only paths are prohibited for any action with external or financial side effects. A warning that lets the action proceed is the control opting out.
- The agent approves itself. An approver must be a human holding the approver role. Self-approval converts a hard gate into a formality.
- Casually widening a grant or ceiling to clear the block. Raising a ceiling and changing a grant are both hard-gated actions requiring their own recorded approval and reason. An unblock path that skips that gate has not unblocked the action — it has ungoverned it.
A copy-ready unblock checklist template¶
Attach one of these to every block type in your stack. Fill the brackets when the block fires; the evidence list itself is written in advance.
BLOCKED ACTION — UNBLOCK CHECKLIST
Plan: [PLAN_ID] · Agent: [AGENT_IDENTITY] · Owner: [OWNER_IDENTITY]
Action: [ACTION] · Target: [TARGET] · Time: [TIMESTAMP]
Audit outcome: blocked · Reason: [EXACT REASON FROM THE AUDIT ROW]
Evidence that reopens this action (supply all that apply):
[ ] Recorded identity for the acting agent, present in the identity registry
[ ] Grant record covering this capability and scope, unexpired
[ ] Recorded human approval (approver: [NAME/ROLE]) for this hard-gated action
[ ] Budget headroom under the plan ceiling, or an approved ceiling raise with reason
[ ] Renewed plan or grant with a future expiry
[ ] Terms record for the agreement this action accepts
Rule: no automatic retry. This action re-runs only when the checked
evidence above exists and is recorded.
Test the checklist with a real owner¶
Day 13 of the Playbook's 14-day rollout is devoted to exactly this: for every block type, write the exact evidence that would unblock it, surface the checklist to the owner at block time, and then test it — hand a real owner a blocked action and time the unblock, simplifying anything confusing. If the owner needs a developer beside them to interpret the block, the checklist has failed its test, however correct the underlying control is. A passing test looks boring: block fires, checklist arrives, owner supplies the named evidence, the action re-runs, and the audit chain shows blocked → evidence → outcome in order.
That boring pass is the point of the whole design. Blocks will happen more often as agents take on more work. Teams that treat each block as a named, evidence-shaped to-do list keep both the control and the velocity. Teams that do not will eventually route around their own governance — and find out, the expensive way, why it was there.