The control gate is correct. It is not the whole story.
Every enterprise architect working with agentic systems learns hooks early. The proposition is straightforward: hooks intercept the tool call before it executes. The governance plane evaluates the action. It approves, denies, modifies, or defers. The agent proceeds accordingly.
Anthropic’s hooks specification is precise on this. PreToolUse fires after the model creates tool parameters and before the tool call is processed. It can allow, deny, modify the tool input, and inject additional context. PostToolUse fires after the tool returns. The event types are well-defined. The decision options are clearly enumerated. The architecture is exactly what it says it is.
The gap is not in the documentation. It is in what the control-gate framing leaves unnamed.
Hooks are one of the few reliable instrumentation surfaces in the agentic loop where execution-plane memory state can be surfaced to, and attested by, the governance plane. That is a different claim than “hooks intercept tool calls.” Both are true. Only one of them completes the architectural argument.
What the governance plane cannot see
In a two-plane architecture, the governance plane makes authorization decisions above the execution layer. The execution plane carries out tool calls, accumulates context, and manages the agent’s working memory across turns. That separation is the point — it is what makes governance possible without embedding policy logic inside the agent itself.
But the governance plane makes its decisions against a context it largely cannot see. The agent’s memory — what it retrieved, what it inferred, what it acted on in prior turns — lives in the execution plane. It accumulates there. It gets compressed there. When the context window compacts, behavioral state shifts in ways that are invisible to callers outside the execution loop.
A governance plane operating against invisible memory state is not governing behavior. It is governing declared intent at the moment of a single tool call. Those are different things.
Recent SDK discussion has surfaced this gap directly: compaction boundaries are invisible to callers outside the execution loop. Output behavior can shift after compaction even when no explicit policy was lost. Vocabulary use, topic focus, and response style can change silently. A governance plane that cannot observe compaction events is authorizing a session that may have silently changed its behavioral baseline.
Two problems, one surface
This series argues that hooks are the architectural response to both dimensions of the governance plane’s blindness. The two dimensions are distinct, and they require different thinking.
The first is the consistency problem. The governance plane needs to see memory state. PreToolUse and PostToolUse are the instrumentation points where execution-plane state can be surfaced upward at each tool call. But visibility into individual tool calls is not enough if compaction events and session boundaries remain invisible. The PreCompact hook — which fires before context is irreversibly summarized — and the SessionStart and SessionEnd hooks are the instrumentation points for those boundaries. Without all of them, governance decisions are made against a context the governance plane did not fully witness. The mechanism that closes this gap is what Post 1 will call the memory witness feed.
The second is the sovereignty problem. Seeing memory state is not enough if that state can be overwritten, pruned, or adversarially shaped before the governance plane observes it. An agent with a corrupted or adversarially-shaped memory context will produce decisions that look authorized but are behaviorally compromised. The governance plane that can only observe cannot govern integrity. Post 2 will argue that hooks at compaction boundaries and session lifecycle events are the attestation layer — the architectural mechanism for memory sovereignty, not just memory visibility.
Together, these two dimensions define what this series calls the Memory Governance Surface: the architectural plane across which memory must become governable, not just retrievable.
Consistency says the governance plane needs to see memory. Sovereignty says the governance plane needs to own memory. A mature architecture requires both. They are different design commitments with different infrastructure requirements.
Where this fits in the larger argument
The Memory Governance Surface is not an isolated concept. It is one instance of a structural pattern that the Luminity corpus has been mapping across multiple series.
The Regulatory Surface names where externally-mandated policy requirements make contact with agentic systems. The Alignment Gate names where behavioral constraints must persist across session boundaries and delegation chains. The Provenance Gap names where the audit and trace record is structurally absent.
Each of these names a surface where agentic systems require governance instrumentation that does not emerge automatically from model capability or operational tooling. Together they constitute what Luminity is developing as the Governance Surfaces framework: the set of architectural planes where deliberate governance instrumentation is structurally required, not optional, not compensable by controls that operate at a different layer.
The Memory Governance Surface adds a fourth surface to that framework. It is not the last. But it is the one where hooks — already in the practitioner’s toolkit, already understood as a control gate — reveal a deeper architectural proposition than most deployments have yet explored.
