Lifeline

A conversation can contain information that matters much later. Keeping the transcript is straightforward. Deciding which part should enter a new prompt is harder: a recent remark may be irrelevant, a durable preference may be old, and a similar sentence may concern the wrong situation. Lifeline makes that selection an explicit part of an ordinary chat request.

I built the assistant around stored memories rather than expecting the model to carry context between requests. The implementation separates extracting a candidate memory, storing it with its source, retrieving candidates for a new message, and formatting the selected context. That separation makes the mechanism inspectable. It does not establish that the model extracted the right facts or that using them improves an answer.

The React interface sends a message to Django. Before an ordinary model call, the view retrieves memories for the requesting user, combines them with memories associated with the current conversation, and builds an enhanced prompt. Recent messages provide immediate conversational context alongside that stored memory. The ordinary text path sends this assembled prompt to the model.

After a response has been saved, the view starts a background thread to extract memory from the user message and assistant response together. The extractor asks an LLM whether the pair contains something worth retaining. If it returns a memory, the backend embeds its content and creates a Memory record linked to the user, source conversation, and source message. This is a later write, not something the current response waits on.

The timing matters. An answer can already exist while extraction is unfinished or fails. The thread is not a durable job queue, and the extraction function logs an exception and returns no memory. To inspect that separation, I exercised the original Django handler against a fresh SQLite database and held its scheduled callback until after the API response was rendered. Releasing the callback then saved a memory that a new conversation retrieved. The ordering is controlled by the probe, not measured production timing.

Memory is a Django model with content, a type, tags, an importance score, an embedding, timestamps, and links back to the conversation. Types include preferences, goals, and facts. The conversation-pair extractor also records which messages it examined and whether its output describes an actionable item or deadline. These fields make the stored interpretation easier to inspect than an unexplained vector alone.

There is an important distinction between a remembered statement and a verified fact. The extractor reads the assistant response as well as the user message. An assistant suggestion can therefore contribute to the material being summarized. The extraction prompt and returned confidence are not an independent check that the resulting memory is accurate or appropriate to retain.

Embeddings are stored with each memory in a JSON field. Retrieval embeds the new query and compares it with those stored vectors in Python. There is no vector database in this path. The implementation gives the project a small, inspectable retrieval mechanism, while leaving embedding quality and the correctness of the stored content as separate questions.

The chat caller requests at most five relevant memories with a minimum cosine similarity of 0.3. The database query first restricts candidates to the requesting user and memories with embeddings. The function then scans those candidates, drops similarities below the threshold, and scores the survivors. A high importance value cannot rescue a memory that fails this similarity filter.

The score gives similarity a weight of 0.6, importance 0.3, and recency 0.1. Recency decreases with whole days since the memory was updated and reaches zero after 30 days. The age comes from updated_at, not the last time retrieval accessed the memory. Reading a memory increments separate access fields, so that accounting should not be described as making its content newly current.

The fictional example below shows why this is different from selecting the nearest vector. A moderately similar, important, recent memory can outrank the closest but older, less important candidate. Those weights encode a retrieval preference. They are implementation choices, not coefficients shown here to improve relevance on a judged dataset.

The view also requests up to three memories from the current conversation, ordered by importance and creation time. That branch does not use the semantic similarity threshold. The two lists are combined and deduplicated by memory ID, so a memory rejected by the similarity branch could still enter through conversation membership. Describing every included memory as a similarity match would misstate the implementation.

The formatter then sorts the combined selection again, by importance and creation time, and includes up to eight entries. It shortens each entry to at most 100 characters. Retrieval score determines one branch's selection, but it is not carried into the formatter as the final ordering rule. Truncation is another transformation: the text the model receives may be shorter than the stored memory that was selected.

Recent message history is also shortened by the prompt builder. Although the caller supplies a history-token parameter, this builder uses a recent-message and character-based policy instead. I would not describe it as enforcing the caller's token budget. To understand an answer, the useful object to inspect is the assembled prompt after these transformations, not just the original retrieval list.

The retrieval scan grows with the number of stored memories for a user. It computes a cosine comparison for each candidate with an embedding, sorts the accepted results, and updates access metadata for selected memories. Limiting the returned list does not remove the scan. At a small scale this keeps the algorithm easy to follow, but the source alone provides no latency or capacity result.

The chat view creates a debug record containing the assembled prompt, selected-context information, model identity, and response metadata. That is a useful inspection surface because it can connect a request with what the ordinary model call actually received. It is not a quality metric. Counts of selected memories do not tell us whether they were relevant, whether an important detail was truncated, or whether the answer used them correctly.

Retrieval logs broad failures and returns an empty list. Continuing without memory may keep a request moving, but an empty result can then mean either that nothing matched or that retrieval failed. Without inspecting that distinction, a plausible answer can hide a broken memory path.

Lifeline also implements Gmail tool calling through a LangGraph agent. That is a separate request branch. In the inspected chat view, the agent receives the current question and conversation history, without the enhanced memory prompt built for ordinary chat. Memory-related metadata can still be attached to the response, so its presence does not prove that the agent consumed the selected memories.

Ordinary chat and tool execution therefore need separate evaluation. A debug record can describe context assembled earlier in a request without establishing that a later branch received it. The consumer's actual input is the boundary that matters: in this implementation, the enhanced memory prompt reaches the ordinary text model, while the tool agent starts from the question and recent conversation.

The seven-memory example checks the scoring arithmetic using invented descriptions and stipulated similarities. The separate four-memory trace goes further: it executes the original request, retrieval, deduplication and formatting code against in-memory records, then captures the argument at the model-call boundary. The source hashes, fictional inputs and exact prompt are retained. Neither example calls an embedding model, runs Django or opens a database.

The backend lifecycle probe adds real Django models, SQLite writes, request handling and JSON serialization. Original extraction and retrieval code connects the stored message pair to a memory and a later prompt. Fixed model replies and embeddings make this a wiring check. Injected extraction and memory-embedding failures leave the chat response and its messages intact without adding a memory. Another fictional user's query omits the saved preference, but the original foreign-conversation request returns a server error.

Following that defect exposed a missing ownership check on notes. A separate local repair scopes both message and note access to the conversation owner and validates content before processing. A 62-case Django/SQLite regression check, including 42 invalid-body cases, passes and was independently repeated. The same checks produce 51 failed assertions on the original API. The repair is committed on an isolated branch; it has not been merged into the original checkout or deployed as a backend service.

The historical EC2 deployment does not establish current hosted availability. This probe also leaves login, migration history, production thread scheduling and durable background work untested. The inspected source has local changes, so file hashes identify the exercised bytes separately from the base commit. The follow-up below adds a small judged retrieval comparison with local surrogate embeddings. Actual-provider retrieval, generated answers and current hosted behavior remain unverified. The useful boundary is still both ends of the path: whether extraction saved context, and which version reached the later consumer.