The most underrated part of the recent Claude Code release is not Auto Mode or Outcomes. It is the hook system — eighteen named extension points where your code can intercept what the agent is doing — and the memory architecture that survives the agent's own context compaction. Together they are what makes Claude Code something a platform team can govern, instead of a clever assistant that lives only in individual developers' terminals.
Why hooks matter
A capable agent that you cannot inspect is a liability. A capable agent that fires events at every meaningful boundary — session start, before a tool call, after a tool call, before a commit, after compaction, on user prompt, on permission decision, and so on — is an infrastructure component. Your code can run on each of those events. You can block, redact, log, escalate, augment.
Eighteen hook types is enough surface to express almost any policy your security team will ask for. The ones that matter most in practice:
- Pre-session injection. Inject organisational context, policy reminders, or repository-specific instructions before the agent reads its first prompt.
- User-prompt-submit hooks. Inspect what the user is about to ask. Redact secrets that leaked in by accident, expand shorthand, attach the right house style guide.
- Pre-tool-use hooks. Veto or modify dangerous tool invocations. The agent never even sees the rejected call.
- Post-compaction hooks. Reinject the agent's identity, role, and policies after the model compresses its own context. Without this, long sessions silently lose grounding.
- Stop hooks. Run lints, security scans, or notifications when the agent ends a turn.
Each one is a clean integration point. You write a small program, register it, and the platform calls it at the right moment.
"Dreaming" — the memory architecture
Long agent sessions hit context limits. The model compresses old turns into summaries; the summary is lossy by definition. Without intervention, a multi-hour session quietly forgets the early discussion of constraints, the policy you set, the user's actual role.
The memory architecture in current Claude Code — sometimes referred to as Dreaming in Anthropic's own discussions — is a structured response to that problem. Specific pieces of information are written to durable memory that survives compaction; pre-session and post-compaction hooks read from that memory and re-inject the relevant pieces. The agent does not need to remember everything in its working context; it just needs to remember to consult the right notes.
For enterprise use, the consequence is meaningful. A coding session that lasts an entire afternoon does not drift. The agent that started under a "do not touch the auth module" instruction at 9am still knows that instruction at 4pm.
What this lets a platform team do
Concrete patterns that become realistic with hooks and memory:
- Repository-scoped policy injection. A pre-session hook reads the repository's
AGENTS.mdequivalent and adds it to the session context. Different repositories, different rules, no developer configuration. - Secret redaction at the boundary. A user-prompt-submit hook scans for token-shaped strings, replaces them with placeholders, logs the redaction. The agent never sees the secret.
- Tool allow-listing per directory. A pre-tool-use hook checks the working directory and denies network calls from anywhere in
/legacy/or denies file writes outside the developer's feature branch path. - Audit log shipping. A post-tool-use hook ships every tool invocation to your central observability stack with developer identity, repository, tool name, parameters, outcome.
- Compliance escalation. A stop hook posts to Slack whenever a long session has touched files in a sensitive path, so a senior reviewer can take a look before the developer opens a PR.
None of these are exotic. They are the same patterns enterprise security teams have built around every other developer tool for two decades. The difference is that the agent now has the events to integrate with.
A tool you cannot govern at the event level cannot enter regulated environments. Hooks are the line between "developer experiment" and "approved enterprise capability."
Practical starting kit
A useful first hook set for a typical enterprise team:
- One pre-session hook that injects your house rules (review expectations, secret handling, language style).
- One user-prompt-submit hook that redacts obvious secrets (regex on token prefixes, basic auth strings, AWS-style keys).
- One pre-tool-use hook that blocks tool invocations against paths or commands on your deny list.
- One post-tool-use hook that ships an audit event per tool invocation to your existing logging platform.
- One stop hook that notifies the developer of any flagged events from the session.
Five hooks. Most of them are tens of lines of code. Together they convert Claude Code from "tool an individual installs" to "capability a platform team owns."
What hooks do not solve
Two honest limits. First, hooks operate on what the agent does, not on what it thinks. A user prompt that includes social-engineering against the policy still reaches the agent unless your hook catches it. Investing in well-designed system prompts and memory entries matters as much as the hooks themselves.
Second, the hooks are local. They run on the developer's machine. For organisations that want a server-side enforcement layer, the hook system is necessary but not sufficient — you also need a central policy server that the local hooks consult. That pattern is straightforward; it just needs to be built deliberately.
The maturity signal
A tool that ships eighteen named extension points and a structured memory architecture is a tool taking itself seriously as infrastructure. That is the signal worth catching. For enterprise teams that have been waiting for agentic coding to feel governable, this is the moment to start designing the policy that will live in those hooks. Build the policy now. The next six months are when peers start asking how you did it.