Agent Memory Hooks: Load Context and Save Progress

A lifecycle hook is a function that runs at a defined point in an agent's execution: before the first action, after each action, or when the agent finishes. Memory hooks use those points to load context the agent needs and to save progress before the session ends.

The value of hooks over in-session memory is control. You decide what gets loaded, when, and from which source. You decide what gets saved, and you can validate it before it is written. Tools like fenbs work well as a handoff destination for hooks because the saved context is reviewable, attributable, and available to any tool that connects to the same project.

What memory hooks do

A pre-run hook fires before the agent acts. It loads context into the agent's input: the current task state, the active rules, where the last session stopped. The agent starts with accurate information rather than guessing or asking.

A post-run hook fires when the agent finishes or pauses. It saves progress: what changed, what was checked, what the next step is. If this write happens in the hook rather than by asking the agent to summarize itself, the saved content is more predictable.

Some frameworks also support per-turn hooks that run after each individual action, not just at the session boundaries. These are useful for validation: checking that the agent's last action produced an acceptable result before the next one begins.

Loading context correctly

A hook that loads context from the right source is more reliable than an agent that retrieves its own context. The agent may call a retrieval tool, get a stale or semantically similar but incorrect result, and proceed on a wrong assumption. A hook that loads a specific, human-reviewed record eliminates that path.

Load the minimum context needed. A large context load fills the agent's context window (the maximum text it can process at once) with information that is not relevant to the current task. Prioritize the active rules and the current task state. Link to larger reference material rather than including it inline.

Keep pre-run hook failures loud. If the context load fails, the agent should not run with an empty context and produce work based on nothing. A failed hook should stop the run and report the failure rather than allowing a silent degradation.

Saving progress without trusting auto-summaries

Asking an agent to summarize its own work at the end of a session produces a summary that reflects what the agent believes it accomplished. That belief may be wrong. An incorrect action the agent did not notice still appears as correct in a self-generated summary.

A better approach is to save structured progress from the hook using verifiable facts: the files changed, the test results, the commit hash if one was made, and the specific next step. These facts come from the run environment, not from the agent's interpretation of the run.

Where subjective progress must be recorded, keep it separate from verified facts and mark it as unreviewed until a person confirms it. For the architectural tradeoffs in memory design, see how to build agent memory.

Per-turn validation hooks

Some frameworks support per-turn hooks that fire after each individual action rather than only at session boundaries. These are useful for lightweight validation: confirming that the file the agent just edited still compiles, that a required field was not deleted, or that the change falls within the expected scope. A per-turn hook that catches an error stops the agent before the problem propagates to the next action.

Keep per-turn hooks fast. A slow validation check delays every action in the session. Reserve detailed validation for session-boundary hooks, and use per-turn checks only for the quick signals that meaningfully change what the agent should do next.

Avoiding the over-trusting pattern

A common mistake is using a hook to save an agent's self-reported progress and then using that output as the input for the next session's hook. After several sessions, the context window contains a chain of summaries, each one potentially amplifying errors from the previous.

Break this chain by having a person review progress at meaningful intervals. The reviewed state becomes the authoritative starting point. Summaries that have not been reviewed should be marked as such and weighted accordingly by the next session.

How to do this with fenbs

1. Create a free account and add a project and tasks for the work your agent runs.
2. In your pre-run hook, read the active tasks and Decisions from fenbs using the MCP connection at Integrations. Load only what the current task needs.
3. In your post-run hook, write the task outcome to fenbs: what changed, what tests passed, what the next step is. Use verifiable facts where possible.
4. Review the saved progress before the next hook run reads it. Mark reviewed states as the confirmed starting point.
5. Record any rules that emerged from the run as Decisions in fenbs so future hooks load them from the start.

For context on how hooks work specifically in Codex CLI, see Codex CLI hooks. For MCP as a connection mechanism between agents and memory stores, see agent memory MCP.