- In short
- A hook pipeline is a set of hooks composed across the tool lifecycle so that pre-execution enforcement runs before post-execution normalisation. Ordering matters: gating an action before it runs, then cleaning its result, keeps invalid operations from ever being processed.
Why a hook pipeline is an ordering problem
Once you can write individual hooks, the next architectural skill is combining them, and the moment you have more than one hook acting on a tool, their order becomes the design. A hook pipeline arranges several hooks across the tool lifecycle so that each stage does its narrow job at the right moment. The defining property of a well-built pipeline is sequence: enforcement happens at the pre-execution stage, the tool runs only if it passed, and normalisation happens at the post-execution stage on a result that is now known to be legitimate.
That sequence is not a stylistic preference; it follows directly from when each event fires. A PreToolUse gate can stop an action, and a PostToolUse normaliser can only reshape one that already happened. Compose them in that natural order and the pipeline blocks first and cleans second, which is exactly what you want. The architecture, in other words, is mostly the discipline of putting the right hook at the right lifecycle point.
- Hook pipeline
- A composition of multiple hooks across the tool lifecycle, ordered so pre-execution enforcement precedes post-execution normalisation. Each stage is a focused, independently testable control, and together they form a layered, deterministic guard around a tool call.
The cost of getting the order wrong
The central exam trap for this knowledge point is putting normalisation hooks before enforcement hooks and thereby processing invalid operations. Conceptually, this is what happens when a designer thinks of normalisation as a first step that tidies inputs before anything else. In a tool pipeline that instinct is backwards. If you clean and act on data before you have checked whether the action was allowed, you have already done work on an operation that should never have proceeded, and in the worst case you have let the action itself run.
Ordering enforcement first has a name worth remembering: fail fast. The cheapest, safest pipeline rejects a disallowed operation at the earliest possible moment, before any side effect, before any expensive transform. A pipeline that normalises first does the opposite, spending effort and risking side effects on operations it is about to discover were invalid. Recognising that enforcement is a precondition for everything downstream, not a parallel concern, is the heart of designing the pipeline correctly.
Layering several controls
Real pipelines often stack more than two hooks. A single tool call might pass through a compliance gate that checks a regulated precondition, then a threshold gate that checks a numeric limit, before the tool runs, and finally a normaliser that standardises the output. Each is a small, single-purpose control, and the layering gives you defence in depth: an action has to clear every gate to execute, and only a legitimate result reaches the model. This is the layered-enforcement idea the key concepts call combining multiple hooks in a pipeline.
Layering this way keeps each control simple, which is what keeps the system maintainable. Rather than one sprawling hook that tries to check compliance, enforce thresholds, and reshape output all at once, you have a sequence of focused stages you can reason about, change, and test one at a time. It mirrors the staged thinking behind a multi-pass review architecture, where separating concerns into ordered passes makes the whole more reliable than any single monolithic step.
How Claude Code combines hooks on the same event
It is worth being precise about what "first" means, because hooks attached to the same event do not run in a strict line. The official hooks guide explains that when an event fires, every matching hook runs in parallel, and identical hook commands are deduplicated so the same command is not executed twice. Claude Code then waits for all of them to finish and merges their results. So when two PreToolUse gates guard one tool, they are evaluated together rather than one feeding the next, and a deny from one does not stop a sibling hook from also running.
What makes the pipeline behave like an ordered set of gates is how those parallel results are combined. For a PreToolUse permission decision, Claude Code resolves the merged outcome by the most restrictive answer: a deny from any single hook wins over an ask, which wins over an allow. The practical effect is exactly the every-gate-must-clear property this page relies on, because one gate's denial is enough to block the call no matter what the others returned. The strict ordering that genuinely holds is across events, not within them: every PreToolUse hook finishes before the tool runs, and every PostToolUse hook runs only after it. Keeping that distinction clear, parallel within an event and ordered across events, is what lets you reason correctly about a pipeline that stacks several gates on one tool.
Observability across the pipeline
A pipeline that silently does its job is good; a pipeline you can see working is better, especially when several stages share responsibility for a single tool call. Each stage is a natural place to emit a small record of what it saw and what it decided, so that a denied transfer can be traced to the exact gate that stopped it and the reason it gave. Without that visibility, a multi-hook pipeline becomes hard to debug: when an action is blocked you want to know which gate fired, and when one slips through you want to know which gate should have.
Observability also keeps the layers honest as the system grows. With per-stage records you can confirm that the compliance gate is actually being exercised in production, not just present in the configuration, and you can spot a gate that never fires and may be mis-scoped. Treating each hook as an instrumented checkpoint rather than an invisible filter turns the pipeline into something you can monitor and reason about over time, which is exactly what a layered safety system needs to remain trustworthy.
Testing the pipeline independently of the model
A defining strength of a hook pipeline is that it can be tested without the model in the loop. Because every stage is a command that reads JSON input and returns a decision, you can feed it crafted inputs and assert the outcome directly: give the compliance gate a missing screening result and assert a deny, give the normaliser a Unix timestamp and assert an ISO 8601 output. This is the key concept that a hook pipeline must be testable independently of the model, and it is what lets you trust the pipeline the way you trust any well-covered piece of code.
That testability is also why a pipeline of hooks beats an equivalent set of prompt instructions for anything that matters. You cannot unit-test a paragraph of guidance into a guarantee, but you can unit-test a hook. Verifying each stage in isolation, then confirming the order, gives you a deterministic safety net that behaves identically in development and in production. When an exam question asks how you would gain confidence in an enforcement design, independent per-stage testing is the answer that separates an architecture from a hope.
Worked example
A payments agent needs two guarantees and one cleanup on its transfer tool: block sanctioned counterparties, cap autonomous transfers at a limit, and present amounts to the model in a single currency format.
A designer's first sketch puts a normaliser at the front, reasoning that it is good hygiene to standardise the transfer amount into one currency before doing anything else. Then a threshold gate checks the limit, and a compliance gate checks sanctions. Tracing an invalid transfer through this order exposes the flaw: the pipeline reshapes and reasons about a transfer to a sanctioned party before the compliance gate ever runs, and any side effect attached to that early processing has already occurred. Normalisation before enforcement processed an operation that should have been stopped on sight.
The corrected pipeline reorders the stages to match the lifecycle. At the PreToolUse stage, the compliance gate runs first and denies any sanctioned counterparty, failing fast before anything else happens. If it passes, the threshold gate checks the amount and denies an over-limit transfer. Only a transfer that clears both gates reaches execution. After the tool runs, a PostToolUse normaliser standardises the confirmation into the single currency format the model expects. Invalid transfers are now rejected at the earliest point, and only legitimate results are ever cleaned.
The two sketches use the same three hooks; only the order differs, and the order is the entire difference between a safe pipeline and a leaky one. Because each stage is independently testable, the team can prove the compliance gate denies sanctioned parties and the normaliser formats correctly without ever invoking the model, then assert the sequence in an integration test. That is what makes the pipeline an architecture you can certify rather than a configuration you hope works.
Trace one concrete transfer to feel the difference. A payment to a sanctioned counterparty for an amount within the limit enters the corrected pipeline, hits the compliance gate first, and is denied immediately, before the threshold gate or the normaliser ever run and before any money moves. In the flawed pipeline the same payment would first have its amount tidied into the canonical currency and then be reasoned about, all while the sanctions check still sat downstream waiting its turn. Same hooks, same transfer, opposite outcome: the ordering is not a detail of the architecture, it is the architecture.
Evolving a pipeline safely
Pipelines are not static; rules change, new gates are added, and a normaliser learns about a new tool. Because the stages are independent and individually tested, this evolution stays manageable. Adding a fourth gate means writing and testing one new stage and slotting it into the correct lifecycle position, not rewriting a monolith. The single-responsibility structure that made the pipeline clear to build is the same structure that makes it safe to change, since a modification to one stage cannot quietly break the logic of another.
The one invariant you must preserve through every change is the ordering principle: enforcement before execution, normalisation after. A new gate joins the pre-execution group; a new reshaper joins the post-execution group; nothing moves a blocking control behind the action it is meant to block. Holding that invariant constant while everything else evolves is what keeps a long-lived pipeline correct, and it is why the ordering rule is worth internalising as a property of the architecture rather than a one-off setup decision.
Common misreadings to avoid
Misconception
Normalisation is basic data hygiene, so it makes sense to run normalisation hooks before the enforcement hooks.
What's actually true
Misconception
A multi-hook pipeline can only be validated by running the whole agent and watching its behaviour end to end.
What's actually true
How it shows up on the exam
This is the capstone knowledge point of Task Statement 1.5, so its questions ask you to assemble or critique a multi-hook design rather than reason about a single hook. A common form presents a pipeline with the stages in the wrong order and asks what is wrong; the answer identifies that enforcement must precede normalisation and that the current order processes invalid operations. Another form asks how to gain confidence in the design, where the credited answer is independent per-stage testing.
The reliable mental model is the lifecycle itself: pre-execution gates that can block, then execution, then post-execution reshaping that cannot. Lay any proposed pipeline against that timeline and ordering errors become obvious. Combined with the earlier knowledge points in this task statement, you can now not only choose the right hook but sequence several of them into a layered, testable architecture, which is exactly the applied competence Domain 1 expects.
A team's transfer pipeline has three hooks: a PostToolUse normaliser that standardises currency, a PreToolUse threshold gate, and a PreToolUse sanctions-compliance gate. They report that occasionally work is done on transfers to sanctioned parties before anything stops them. What is the correct fix?
People also ask
What order should hooks run in?
Should enforcement or normalisation hooks run first?
How do you test a hook pipeline?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
Implementing a hook
Why watch: Ordering and combining hooks into a working setup foreshadows the multi-hook pipeline architecture.
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.