- In short
- Prerequisite gate design is the practice of putting a deterministic check in front of a downstream tool so the tool cannot run until a required prerequisite is satisfied. A canonical gate denies the refund tool until account ownership has been verified, and it is implemented in code such as a PreToolUse hook, never as a prompt instruction.
What prerequisite gate design is
Once the high stakes enforcement decision rule tells you a step must be deterministic, you need a concrete mechanism to make it so. Prerequisite gate design is that mechanism. A gate is a check positioned directly in front of a downstream tool that allows the tool to run only when a named prerequisite has been satisfied, and blocks it otherwise. The textbook example is a refund that may not be issued until account ownership has been verified: the gate sits in front of the refund tool and denies every call while the ownership check is still outstanding.
The key word is prerequisite. The gate does not evaluate whether a refund is wise or whether the amount is right; it evaluates one binary precondition, has ownership been verified, and uses that to permit or deny. By reducing enforcement to a single deterministic condition checked in code, the gate converts a fuzzy instruction ("be sure to verify first") into an unbreakable ordering constraint.
- Prerequisite gate
- A deterministic guard placed in front of a downstream tool. It checks whether a required prerequisite (such as verified account ownership) is satisfied and blocks the tool call until it is. Gates are built in code, for example a PreToolUse hook returning a deny decision, rather than expressed as prompt text.
One way to keep the design honest is to picture the gate as a bouncer rather than a sign. A sign on the door asking guests to show ID is a prompt: most people comply, some do not, and the sign cannot stop anyone. A bouncer who physically checks every ID before letting anyone through is a gate: the policy is enforced at the threshold, on every entry, regardless of how persuasive the guest is. The bouncer does not need to understand the whole party or judge intentions; it checks one precise precondition and admits or refuses on that basis alone. That narrowness is a feature, because a gate that tries to reason about too much becomes as unpredictable as the model it was meant to constrain.
How a gate is built with a PreToolUse hook
In the Claude ecosystem the cleanest way to build a gate is a PreToolUse hook. The hook fires before any tool call executes and receives the tool name and its inputs. For a refund gate, the hook matches on the refund tool, inspects shared session state for a verified-ownership flag, and returns one of two decisions. If the flag is set, it allows the call. If it is not, it returns a deny decision with a reason, and the refund tool simply never runs.
What makes this robust is that the decision is plain code reading a flag, so it behaves the same on every request. The model can propose the refund in any phrasing, at any point in the conversation, under any amount of user pressure, and the gate's answer never changes while the prerequisite is unmet. The hook can also explain itself: the deny reason is fed back so the agent understands it must verify ownership before trying again, which nudges it toward the right sequence without ever relying on that nudge for safety.
Order independence is the property you are buying
The subtle benefit of a gate is that it makes the rule independent of conversation order. A prompt that says "verify the customer before refunding" assumes the model will execute the steps in the intended sequence. But conversations are messy: the customer might open by demanding a refund, the verification might get interrupted, the model might revisit the refund three turns later having lost track of whether verification finished. In any of those orderings a prompt can slip.
A gate does not care about order. It evaluates the prerequisite at the exact moment the refund is attempted, so no matter how the conversation wandered, the refund is impossible until the flag is set. This is why a gate is the correct answer when a scenario mentions failures that appear only occasionally or only under unusual flows, because those are precisely the cases where order-dependent prompt logic breaks down.
Worked example: closing the wrong-account refund hole
A concrete failure makes the design choice vivid.
Worked example
A support agent issues refunds. With only a prompt telling it to verify ownership first, a small fraction of refunds land on the wrong account. Design a gate that closes the hole.
The starting state is a prompt-only agent: the system prompt instructs it to confirm the customer owns the account before any refund. In the great majority of conversations it does. But across thousands of real sessions a stubborn slice, say several in every hundred, slip through: the verification was skipped because the customer was insistent, or it was performed against the wrong account because the conversation had drifted. The result is refunds posted to accounts that do not belong to the requester. No amount of rewording removes that residual rate, because the model is still the thing deciding.
Now design the gate. First, define the prerequisite precisely: a boolean ownership_verified on the session, set true only by the verification tool after it confirms the caller controls the specific account being refunded. Second, write a PreToolUse hook matched to the refund tool that reads ownership_verified for the targeted account and returns deny when it is false. Third, make sure the flag is account-specific, so verifying account A cannot unlock a refund on account B. With the gate in place, every refund attempt is intercepted and checked at the instant it is made. The insistent customer, the drifted conversation, the unusual ordering, none of them matter: the refund tool is inert until the right account has been verified. The occasional wrong-account refund does not become rarer; it becomes impossible.
Misconceptions about gates
Misconception
A strongly worded prompt plus a few examples of verifying first will reduce the wrong-account refunds enough to be safe.
What's actually true
Misconception
A prerequisite gate is just a check the model performs as the first step of its reasoning.
What's actually true
Scoping the prerequisite precisely
A gate is only as sound as the prerequisite it checks, and the most common design bug is a prerequisite that is too loosely scoped. A naive refund gate reads a single ownership_verified boolean on the session and unlocks every refund once it is true. But a session can verify ownership of account A and then attempt a refund on account B; with a session-wide flag, the gate happily allows it. The fix is to scope the prerequisite to the exact resource being acted on, so the flag answers "is this caller verified for this account" rather than the vaguer "has any verification happened."
Scope has a time dimension too. Verification that was valid an hour ago may not be valid now, so a careful gate treats the prerequisite as something that can expire and re-checks freshness rather than trusting a stale flag. The general principle is that the gate's condition should mirror the real-world precondition as tightly as possible: the right account, the right action, and a verification recent enough to still mean something. Loosely scoped gates create exactly the wrong-account failures they were built to prevent.
Pre versus Post: timing decides whether you can block
Designers sometimes reach for the wrong hook because they conflate observing an action with preventing it. The two relevant events sit on opposite sides of execution. A PreToolUse hook runs before the tool executes and can return a deny decision, so it is the only event that can actually block a call. A PostToolUse hook runs after the tool has executed; it can inspect the result, normalise data, or raise an alert, but it cannot un-ring the bell. For a prerequisite gate, only the pre-execution event will do.
This timing distinction is the heart of many exam distractors. An option that proposes a PostToolUse hook to "check that ownership was verified" sounds responsible, but by the time it runs, the refund has already posted. Post-execution logic belongs to auditing and to data normalisation, which is the proper job of PostToolUse hooks, not to enforcement. If your goal is to make a bad action impossible rather than merely visible after the fact, the check must run before the tool, every time.
Composing several gates
Real workflows rarely have a single prerequisite. A high-value refund might require that ownership is verified, that the amount is within the agent's authority, and that no fraud hold is active on the account. Rather than cram these into one tangled condition, sound design composes several focused gates, each checking one clear prerequisite, that all must pass for the action to proceed. Layered this way, each gate stays simple, testable, and easy to reason about, and the overall policy is the conjunction of them.
A composed gate system should also fail closed. If the data a gate needs is unavailable, an unreachable verification service, a missing flag, the safe default is to deny rather than allow, because an open default would quietly turn a high stakes action loose exactly when the system is least healthy. Failing closed keeps the guarantee intact under partial failure, which is the entire reason you chose a deterministic gate over a prompt in the first place.
How this knowledge point is tested
At difficulty four and the apply Bloom level, this is one of the more demanding knowledge points in task statement 1.4. Questions go beyond classifying stakes and ask you to choose or critique an actual design. A common stem describes a high stakes step that fails intermittently and asks which fix makes it reliable, or it presents a proposed gate and asks what is wrong with it, for example that the verification flag is not scoped to the specific account.
The winning instinct is to look for the deterministic interception point. A correct gate (a) lives in code rather than the prompt, (b) blocks the specific downstream tool, and (c) checks a precise, correctly scoped prerequisite at call time. Any option that keeps the decision inside the model, or that checks the wrong condition, is a distractor. Carry that checklist into the open-ended workflow enforcement scenario analysis, where you weigh gates against lighter mechanisms across varied scenarios.
An agent posts refunds and, despite a detailed system prompt, a few percent of refunds reach accounts the caller does not own. The team wants the wrong-account rate to be exactly zero. Which design achieves that?
People also ask
What is a prerequisite gate in an agent workflow?
How is a prerequisite gate implemented in Claude Code?
Why is a prompt not enough to enforce a prerequisite?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
14-Block Tool Commands with PreToolUse Hooks | Claude Code Guide
Why watch: Directly demonstrates using a PreToolUse hook to physically block a tool call before execution, the exact mechanism behind a programmatic prerequisite gate.
More videos for this concept
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.