Build memory into the way you work

Start with a clear project rule

Put the rule in AGENTS.md for Codex or CLAUDE.md for Claude Code. Add it to the instructions you already have; don’t replace the file. Give the agent a project scope and say what to do when the service is unavailable.

## Korium memory

Before planning or changing substantial work, search Korium for
relevant decisions, lessons, corrections and preferences. Use
focused queries and check the sources.

For code-location questions, use Korium code search, verify the
returned commit and read the relevant source locally.

Capture durable decisions, mistakes, corrections and handoffs.
Include the project scope, evidence, confidence and the agent
actually making the capture. Distinguish a person's decision
from your inference. Never store credentials.

If a connection fails, retry once, state what is unavailable
and continue from local evidence when safe. Do not invent a
memory or claim a failed capture succeeded. If nothing useful
was learned, save nothing.

Use hooks for specific moments

A hook is a command the assistant runs at a defined point, such as session start or task completion. A session-start hook can remind it to read memory. A task-end hook can update the code index.

Those do different things. A reminder is not proof that a search happened. Indexing code does not capture the decisions made while editing it.

• Codex hooksProject hook configuration and checks.
• Claude Code hooksSession and task-end examples.
• Git hooksKeep the code index current after a commit.

If you add a memory check, check the result

A stronger setup tracks whether a relevant search completed before the first edit, and whether a useful capture succeeded before the agent finishes. Use the current client’s tool events, not a guess based on how many times a name appears in a transcript.

Match the actual tool name or a verified suffix such as agent_search. Count a successful response, not merely an attempted call. A quota refusal or authentication error must not create a “saved” marker.

Keep any state separate for each session and project. An old marker from yesterday’s work does not prove today’s agent read anything. If the check judges relevance, say that it is a judgment rather than treating any search as sufficient.

Don’t hold the task hostage

For a reminder about missing memory, block once, explain the missing step and then allow the agent to proceed if the service is unavailable. Guard a Stop hook against repeated continuation. Otherwise a failed save can become an endless loop.

This advice applies to memory reminders, not security gates. Do not weaken a permission, secret-handling or destructive-action check to make a task finish.

The task-end code-index example deliberately reports a failure without blocking completion. The next task or commit can retry the index. The user still needs to know that code search may be stale.

Keep the handoff useful

Before finishing, record the outcome, the decisions that shaped it, the checks that ran and what is still open. Link to the actual files, issues or test evidence when you can. Don’t claim something was deployed if it was only changed locally.

If several agents worked on the task, each should record its own observations under its own name. The coordinating agent can summarize the result, while preserving whose evidence supports each claim.

Test the habit before relying on it

• Start a fresh session and check that the reminder appears.
• Ask for a real change and confirm a relevant memory search happens before the edit.
• Make a harmless test change and check the task-end index hook.
• Simulate a missing CLI with a test stub. Confirm the hook reports the failure and the task can finish.
• Simulate a refused capture. Confirm it is not counted as a successful save.
• Start a second session and check that it does not inherit the first session’s markers.

Keep the useful parts and remove checks that generate noise. The point is better work, not a large collection of hooks.