The hook is the guarantee mechanism, not the prompt

Your agent has hands now. It runs commands, edits files, calls APIs, sends the email, moves the money. So ask the question that should make you slightly nervous: what is stopping it from using those hands wrong? For most teams the answer is the model's good judgment — a probabilistic system that, depending on how you happened to word the prompt, might decide today is the day it runs the cleanup command on the wrong folder. Professor Glitch's July 2026 guide to Claude Code hooks on askglitch.com names the fix: a hook is deterministic code that fires at a fixed point in the agent loop, and the model cannot talk its way past it. The property you care about is guaranteed by the mechanism, not by asking the model to be careful.

A hook is Theorem 3 in code

A hook is deterministic code that runs automatically at a fixed point in the agent loop — before a tool executes, after it completes, when the agent declares done, when the session ends. It is not part of the model's reasoning. It sits outside the brain, and it just runs. Professor Glitch's July 2026 hooks guide on askglitch.com puts the distinction plainly: the model is probabilistic, every instruction is a suggestion it will probably follow; a hook is code that runs every single time, at the same point, with the same rules, and the model cannot forget it, skip it, or talk its way past it.

[ORIGINAL DATA] This is Theorem 3 from the 21 papers: a property is guaranteed exactly when its mechanism is implemented and measuring. The hook is that mechanism. "The tests pass before the agent declares done" is a property. A Stop hook that runs the suite and exits 2 on failure is the implemented, measuring mechanism. Remove the hook and you have a wish. Keep the hook and you have a guarantee — not because the model got smarter, but because the failure path is now physically impossible.

The prompt says "always run the tests before finishing." That is a suggestion the model will probably honor. The hook refuses the stop until the suite is green. That is a rule. The difference between a suggestion and a rule is the difference between hoping and knowing, and that difference is the entire discipline. Picture the model as the crowd and the hook as the bouncer at the door, Professor Glitch writes: the crowd can be charming all it wants, the bouncer checks everyone, every time, no exceptions.

The model is probabilistic; the boundary is deterministic

Mechanically, per the official hooks documentation, a Claude Code hook is a shell command you register in a settings file. When the event fires, Claude Code runs your command, pipes a JSON payload describing the event into stdin — the tool name, the tool's exact input, the session id, the working directory — and reads your verdict from the exit code and stdout. Exit 0 means proceed. Exit 2 means block, and whatever you printed to stderr gets fed back to the model as the reason. You write them in whatever you want: Bash, Python, a compiled binary. If it reads stdin and returns an exit code, it is a hook.

[UNIQUE INSIGHT] This is "the space is the router" at the agent boundary. In Everythink, the network→community→room topology routes a request before anything responds — the space decides who is addressed, not the responder. A PreToolUse hook is the same pattern one layer down: the hook routes the tool call before the tool executes. The agent does not choose whether its read of .env proceeds; the boundary decides. Routing precedes retrieval, and at the tool boundary the hook precedes execution.

The gotcha that bites almost everyone, straight from the docs: only exit code 2 blocks. Exit code 1 — the conventional Unix failure code — is treated as a non-blocking error and the action proceeds anyway. If your guard script crashes with exit 1, the bouncer just waved the whole crowd through. Write your hooks so the failure path is explicit, and prefer the JSON output form (permissionDecision: "deny" on stdout with exit 0) when you want the decision to be unambiguous. A guardrail that silently fails open is worse than no guardrail, because it sells the feeling of safety without the mechanism. Theorem 3 is unforgiving here: a mechanism that is implemented but not measuring does not guarantee the property. A hook that crashes open is not measuring.

Job one: make certain failures impossible

Professor Glitch lists three guardrails he actually runs, in ascending order of how much they have saved him. The pattern across all three is the same: you are not making the model smarter or more careful. You are making certain failures impossible. Those are different engineering problems, and the second one is a lot easier to solve.

Block reads of the secrets file

A PreToolUse hook sees every tool call before it executes, with the full input. If the agent is about to read .env or anything under secrets/, the hook exits 2 and the read never happens. Cold. It does not matter how reasonable the agent's justification was, or whether a prompt injection buried in some webpage asked it nicely. The bouncer does not debate.

Block destructive commands

The same event, matched to the Bash tool. The hook inspects the command string in tool_input.command before it runs — rm -rf pointed anywhere sensitive, a force push, a DROP TABLE, whatever your personal list of scar tissue looks like. Deny it in code and it is simply not possible, no matter what the model reasons its way into.

Reject "done" until the tests pass

This is the one that matters most, and it uses a different event. Claude Code fires a Stop event when the agent finishes responding. Your hook runs at that moment. If it exits 2, the agent is prevented from stopping; your stderr message goes back to the model, and it goes back to work. The agent says "all set, I shipped the feature." The Stop hook quietly runs the test suite. Three failures. The hook exits 2 with the failure output. The agent does not get to be done. It gets shoved back into the loop with the bug in hand.

The refused stop is the guarantee that matters

Everyone gets that hooks can block a bad action. The underrated move is that a hook can block a bad stop. This is where the source's argument and Theorem 3 meet most cleanly.

"Always run the tests before finishing" in your prompt is a suggestion. A Stop hook that refuses the stop is a rule. The agent literally cannot declare victory while the suite is red. Two practical notes from the guide: keep the check fast and deterministic, because it runs on every stop; and make sure a real failure produces a fixable message, because that stderr text is the only guidance the agent gets. "Tests failed" sends it wandering. The actual failure output sends it straight to the bug.

[PERSONAL EXPERIENCE] The HAI Engine has run in production since 2016, and the lesson of those years is the same: the properties we guarantee — probabilities normalized in exactly one place, scenarios sorted descending, entropy in nats — live in the Oracle's ensemble code, not in a prompt asking the Sisters to be careful. The Sisters imagine; the Oracle merges. The normalization is the hook. It runs every time, at the same point, with the same rules, and no Sister can talk it into shipping a cone whose probabilities sum to 1.05. That is Theorem 3: the property holds because the mechanism is implemented and measuring.

The same pattern works one level down: SubagentStop fires when a subagent finishes, so delegated work can be held to the same standard as the main loop. In Everythink's terms, this is why the space is the router — a room routes to the right subagent, and the subagent's stop is gated by the same boundary that gates the parent. The guarantee composes across the topology. A network routes to a community, a community routes to a room, a room routes to a subagent, and at every boundary the same discipline applies: the mechanism guarantees the property, not the responder's judgment.

Job two: the end-of-shift journal

Guardrails are what everyone uses hooks for. There is a second job almost nobody talks about: hooks are how an agent's memory gets written.

Your agent already reads memory; retrieval pulls the relevant facts into the window when a task starts. But something has to file the new facts — the preference you stated, the approach that worked, the mistake worth not repeating. That something is a hook. Claude Code fires SessionEnd when a session terminates. It cannot block anything; its output is ignored; it exists purely for side effects. Which is exactly what a memory write is: take the transcript path off stdin, distill the conversation, append the durable stuff to your store.

It is the end-of-shift journal, except the journal writes itself, every single shift, because it is a rule and not a mood. Next session, the agent walks in already knowing what this one taught it.

Two rules keep this from becoming a toy. Gate the write: most messages are "thanks" and "got it," so write at session end and let the prompt end with "if nothing is durable, write nothing." Storing everything is not memory, it is clutter. And use the cheap model: distilling a transcript into a paragraph is not hard reasoning. The senior model thinks during the session; the intern writes up the minutes after.

This maps to a discipline we keep in the 21 papers: a measurement that is not gated is noise. The Oracle does not log every Sister draft — it logs the normalized ensemble, the entropy, the calibration trace. The SessionEnd hook is the same gate at the memory boundary: write the durable fact, drop the chatter. A memory system that stores everything remembers nothing.

The event map

Claude Code exposes around thirty events. The ones you reach for first, per the docs:

• PreToolUse — before any tool call executes; can block; secrets guard, destructive-command filter.
• PostToolUse — after a tool call completes; feedback only; auto-format after edits, log every command.
• UserPromptSubmit — when you submit a prompt; can reject the prompt; inject context, filter prompts.
• Stop — when the agent finishes responding; can refuse the stop; run tests before accepting done.
• SubagentStop — when a subagent finishes; can block; hold delegated work to the same bar.
• SessionStart — when a session begins; cannot block, adds context; load today's state into the window.
• PreCompact — before context compaction; can block; save state before the window gets squeezed.
• SessionEnd — when a session terminates; side effects only; the memory write.

Notice the symmetry: SessionStart injects context in, SessionEnd writes learning out. That pair alone is a working memory system — and it is a memory system made of rules, not of moods. The PreCompact event is the boundary that prevents the window from silently discarding state: save the working set before the squeeze, and the agent resumes from fact, not from summary.

What Everythink guarantees this way

The HAI Engine ✅ is the production system this discipline produces. The Sisters ✅ are the imaginers; the Oracle ✅ is the merger; the ensemble normalization is the hook that guarantees probabilities sum to one. World Monitor ✅ routes live geo-signals through a gateway that bounds upstream call volume by our schedule, not by client count — a rate-limit hook at the architecture level. Social ✅, Campaigns ✅, and Whitelabel Network ✅ are the modules where a network's routing rules are enforced in code, not in a brand guideline.

The Partial ⚠️ modules — Matchmaking, Marketplace, Calendar — are measured but not yet fully hardened; we say so. The Roadmap 🔵 modules — Wallet & Token, Super App, Community Credit — are pre-revenue and subject to Howey review; we do not promise outcomes for them, and no hook we ship can change that honesty. A hook can guarantee a property; it cannot guarantee a market.

Customer sovereignty is the deepest version of this pattern. Your network, your brand, your data — the routing rules are yours because they live in code you control, not in a vendor's prompt. The ethics of scope — civil and defensive use only — is itself a hook: a written policy at the boundary, not a hope that the model declines the wrong job. Inclusion by design — multilingual, multimodal, low-connectivity — is a SessionStart injection: the locale and the bandwidth shape the first context the agent sees, before it responds.

Key takeaways

• A hook is deterministic code at a fixed point in the agent loop; the model is probabilistic and cannot talk past it. The property is guaranteed by the mechanism, not by the prompt.
• The refused stop is Theorem 3 in code: "tests pass before done" is a property; the Stop hook that exits 2 on failure is the implemented, measuring mechanism.
• Exit 2 blocks; exit 1 fails open. A guardrail that crashes open is worse than none — it sells the feeling of safety without the mechanism.
• SessionEnd writes memory so SessionStart can read it. The pair is a memory system made of rules, not moods; gate the write or store clutter.
• The hook is "the space is the router" at the tool boundary: routing precedes execution, and the boundary decides, not the responder.

Frequently asked questions

What is a Claude Code hook, exactly? A shell command you register in a settings file. When a fixed event in the agent loop fires — before a tool runs, when the agent declares done, when a session ends — Claude Code pipes a JSON payload into your script and reads the verdict from the exit code. Exit 0 proceeds, exit 2 blocks.

Why is a hook safer than a prompt instruction? A prompt instruction is a suggestion a probabilistic model will probably follow. A hook is code that runs every time, at the same point, with the same rules. The model cannot forget it, skip it, or argue it down. "Hoping it behaves" becomes "knowing it will."

What does "refuse the stop" mean? The Stop event fires when the agent finishes responding. A hook on that event can exit 2 to prevent the agent from stopping, sending the stderr message back to the model. Run the test suite there, and the agent literally cannot declare victory while the suite is red.

How does this connect to Theorem 3? Theorem 3 says a property is guaranteed exactly when its mechanism is implemented and measuring. The hook is that mechanism: implemented as code, measuring as an exit code. Remove it and you have a wish; keep it and you have a guarantee.

Does Everythink use hooks? The same discipline runs the HAI Engine ✅: the Oracle's ensemble normalization is the hook that guarantees probabilities sum to one, in code, every run. No Sister can talk it into shipping an unnormalized cone.

Sources

Professor Glitch, "Claude Code Hooks: The Guardrails Your Agent Can't Talk Past," askglitch.com, July 7, 2026 — https://www.askglitch.com/blog/claude-code-hooks

Claude Code hooks reference, code.claude.com — https://code.claude.com/docs/en/hooks

Create your network.