A Checkpoint: The Whole Path in One Event

Claude-mem’s value becomes easier to judge when one event is followed all the way through the pipeline. The connected ideas are now concrete: a host action is captured, admitted, queued, interpreted by an observer, stored in SQLite, optionally indexed in Chroma, and later returned through search or context injection. The practical judgment is not whether the event exists somewhere, but which of those transitions have actually happened and what each one guarantees.

One authentication investigation, seen as a chain

Imagine an agent investigating why an authentication test fails. The user’s prompt establishes the working conversation. The agent reads a configuration file, changes a setting, runs a test, and receives a successful result. The example is ordinary on purpose: claude-mem is designed to observe routine work, not only formal note-taking moments.

At the capture edge, the host supplies the event with its tool name, input, outcome, working directory, platform source, prompt number, and tool-use identity when available. Shared ingestion resolves the project and the local database session. It can reject the event if the project is excluded, the tool is configured to be skipped, the payload is an internal protocol message, or the related prompt was deliberately made private. If the event is admitted, its cleaned input and output can be written to the raw tool-use side index when a tool-use identifier is present, and the event is placed in the live per-session buffer.

At this point the work is captured and queued, but no generated observation necessarily exists. The primary agent can continue because the hook does not wait for the observer. The buffer is live process state, and its purpose is to feed a stateful reducer in order. It is not the same thing as the durable history of the primary session. If the worker disappears before processing the event, the current design relies on the host transcript and a later replay path rather than pretending that the in-memory fragment is independently recoverable.

The observer receives a synthetic prompt describing the authentication tool event. It does not open the repository or infer unseen output. It decides whether the event contains durable signal and, if so, returns a structured observation with a type, title, facts, narrative, concepts, and file lists. Several mechanical actions might become one observation: the setting was changed because an inherited environment value caused the failure, and the test then passed. The reduction is valuable precisely because it connects actions to a finding. It is also a model-produced interpretation, not a verbatim record.

The observer’s first response supplies its own SDK session identity. The local store registers that memorySessionId before inserting an observation or summary, because child rows use it as their foreign-key relationship. The host’s contentSessionId still identifies the user’s conversation. The two identities answer different questions: “Which primary session did this happen in?” and “Which observer-side parent owns this stored memory?” The distinction remains relevant even when the reader never sees either identifier in normal use.

If the response parses successfully and the memory identity is available, the worker commits the observation to SQLite. That transaction is the first strong local durability point for the generated memory. The stored row contains the fields needed for later display and search, including the narrative and facts that explain the authentication finding. The insert also computes a content hash scoped to the observer memory session. If an identical generated observation is presented again under the same identity, the unique constraint can return the existing row instead of creating another copy.