Persistent Local Memory for AI Assistants: A User-Driven Architecture Proposal

When AI Assistants Develop "Amnesia"

Bert Singels, a 54-year-old autistic man from the Netherlands, has proposed a technical concept called "Persistent Local Memory Layer" (PLML) based on his frustrating experiences with AI assistants. He is not a developer, nor a tech industry professional, but his observations hit on a pain point the industry has overlooked: AI assistants cannot reliably remember important information users have already told them.

Even when the conversation history is still sitting right there in the app, the AI may be unable to access the relevant content when needed. Users are forced to repeatedly explain system configurations, restate decisions already made, and re-rule out approaches that have already failed. Singels's proposal is simple at its core: rather than relying entirely on the AI provider to remember everything, let users save the complete conversation history themselves and retrieve the right information through a local system when needed.

The Real Problem: Retrieval, Not Storage

AI assistants are increasingly used for long-running work across sessions—software development, system operations, technical troubleshooting, research and writing. These scenarios all depend on accumulated context. When an assistant cannot retrieve prior decision records, five types of cascading problems arise: duplicated effort, broken continuity, repeated mistakes, diminished trust, and vendor lock-in.

The proposal highlights a key distinction that is easily confused: the problem is not whether conversation data is stored, but whether the right information can be retrieved and supplied to the model at the right moment. This distinction determines the direction of the solution—there is no need to infinitely expand the model's context window; instead, build an independent retrieval layer.

According to Singels's analysis in the proposal, even when existing AI services retain complete history, they lack a reliable mechanism to re-inject relevant fragments into the conversation when needed. This causes users to repeatedly "rebuild" work already completed in long-cycle projects.

Context window refers to the upper limit of tokens a language model can directly "see" during a single inference, including the system prompt, conversation history, and current input. Once a conversation exceeds this window, earlier content is truncated or forcibly summarized, and the model can no longer access it directly. Window sizes vary widely across models, from a few thousand to over a million tokens. PLML's insight is that even when the window is large enough, cramming all history into it is both expensive and inefficient, and the model's attention to the middle portion of long contexts decays. So rather than infinitely expanding the window, it is better to build an independent retrieval layer that precisely injects relevant fragments with each request.

Architecture Breakdown: Five Components, One Principle

The core principle of PLML can be summarized in one sentence: store locally, retrieve locally, share only what is necessary. It decouples three functions that are originally bundled together: long-term storage, context retrieval, and language model inference.

Local Conversation Archive

Messages and their metadata are stored using SQLite or a similar local database—provider and conversation identifiers, timestamps, speakers, message content, project associations, attachment links, and references to decisions, corrections, and unfinished tasks. Full-text indexes and optional vector indexes support different retrieval methods. The archive resides on the user's own device.

SQLite is an embedded relational database in which the entire database is stored as a single file on the local disk, requiring no separate server process. It supports transactions, indexes, and a full-text search extension (FTS5), and is widely used in browsers, mobile apps, and desktop software. For PLML, SQLite's appeal lies in zero operations, cross-platform support, single-file ease of backup and migration, and FTS5's efficient handling of full-text retrieval for exact terms and commands. Vector indexes can be implemented through extensions or standalone components, working alongside relational metadata to form a hybrid retrieval foundation.

Conversation Capture

New messages are captured through browser extensions or supported application integrations. Integration methods include official export/import, provider APIs, browser extensions interacting with the rendered interface, and supported local application interfaces. For browser capture, the system needs to detect messages, preserve order, avoid duplication, and identify incomplete responses and edited content.

Local Retrieval Engine

When a new request arrives, the retrieval engine searches the archive for relevant material. A robust implementation combines multiple methods: full-text search for exact terms, commands, model numbers, and technical identifiers; semantic search for related concepts expressed in different wording; metadata filtering by project, provider, and date; recency and relevance ranking; and source message retrieval—pulling original messages rather than relying solely on summaries.

The proposal gives a concrete example: a user asks to continue a Windows backup project without mentioning the specific drive, imaging software, or previous troubleshooting steps. The retrieval engine can locate earlier relevant decisions and supply them to the assistant.

Full-text search and semantic search are two complementary retrieval paradigms. Full-text search is based on exact keyword matching and is suited to identifiers such as commands, model numbers, and error codes; semantic search maps text into embedding vectors (high-dimensional numerical representations) and measures semantic similarity through vector distance, capable of recalling passages that are conceptually related but worded differently. Vector indexes (such as approximate nearest neighbor structures) make large-scale semantic retrieval feasible. PLML combines both and narrows results with metadata filtering and recency ranking to avoid the blind spots of any single method—full-text search misses synonymous expressions, while semantic search may overlook exact technical identifiers.

Local Memory Agent

A lightweight local agent coordinates retrieval and browser interaction. It is responsible for identifying relevant conversations, selecting source passages, retrieving more context when passages are ambiguous, preparing compact context packages, interacting with the browser interface, verifying that context has been submitted and a response received, and honestly reporting retrieval failures rather than silently fabricating missing context.

One detail worth noting (an engineering judgment from the proposal): the local agent does not need to replicate the capabilities of large cloud models. Most operations can be handled by conventional code, with a small local language model providing assistance only for tasks such as natural language classification or semantic interpretation.

Provider Interface: Two Integration Modes

Mode A: Browser integration—a browser extension interacts with the existing chat interface, preparing context messages, entering the conversation, and submitting. This approach can avoid API costs and does not require providers to implement a dedicated memory API, but it depends on the browser interface, applicable terms of service, and appropriate automation safeguards.

Mode B: Supported API or application integration—where APIs are available and appropriate, the local service can send context directly to the provider. Control is more predictable, but it may introduce usage costs, credential management, and provider-specific integration requirements.

The architecture is designed to support both modes simultaneously without binding the archive to either one.

Context Management: What You Send Matters More Than What You Store

Retrieving relevant history is only the first step. The proposal emphasizes that the system must distinguish seven categories of information: current project state, important user requirements, past decisions and their rationale, approaches that have already failed, explicit corrections to assistant behavior, unresolved issues and next steps, and the original messages used to verify the above.

In scenarios where accuracy is critical, the context manager should prioritize original source material. Summaries can accelerate retrieval but should not become the sole record of important technical details.

Context Budget

The amount of context sent to the model should be governed by its actual limits. If the retrieved history is too large, the system should prioritize the most important material, split work into coherent segments, or request further retrieval in subsequent interactions. The proposal specifically warns: simply sending multiple large messages is not equivalent to preserving context—earlier messages may still fall outside the model's effective context window. The system must track what has actually been supplied, avoiding the assumption that all historical details remain available.

The effective context window is not equal to the model's nominal maximum token count. The actual available space must deduct the system prompt, tool definitions, and reserved output tokens; more importantly, the model's utilization of information in the middle of the window is often lower than at the beginning and end, a phenomenon known as "lost in the middle." Therefore, even if earlier messages are still within the window, they may not be effectively utilized by the model. PLML requires the system to track what has actually been supplied and prioritize injecting highly relevant fragments, rather than assuming that "history is in the window means the model remembers."

Verification Mechanisms

Before using retrieved information, the system should be able to identify its source, distinguishing verified historical facts from inferred summaries. If sufficiently relevant material cannot be found, this limitation should be honestly stated rather than fabricating continuity.

Storage Scale: Text Conversations Are Actually Light

The proposal provides an illustrative estimate: assuming a user exchanges about 24,000 words per day, at 6 bytes per word (including spaces and punctuation), raw text amounts to roughly 52 MB per year. Planning for 200 MB per user per year (leaving a larger margin for metadata and storage overhead), 1,000 users would require 200 GB, 1 million users 200 TB, and 900 million users 180 PB. These are estimates, not measured averages.

The core architectural advantage is that each user's archive can stay on their own device. If providers offer local memory functionality, they need not centrally host each user's complete conversation history in order to make it searchable. Local storage also avoids the need to load the entire archive into the active model context—search and retrieval select only the information needed for a specific request.

Privacy and Security: Local-First Is Not Zero-Risk

Local-first storage can reduce the amount of personal conversation data held by providers, but it does not eliminate security requirements. The proposal lists necessary safeguards: local access control and optional disk encryption, clear permission boundaries for browser access, prevention of unauthorized access by other local applications, secure handling of credentials and provider sessions, explicit control over which retrieved fragments may be transmitted, visible indicators of shared content, data export/deletion/retention controls, and protection against malicious instructions embedded in archived messages or retrieved documents.

A key design stance is: archived messages should be treated as historical information, not as automatically trusted instructions. The local agent must not allow retrieved content to override current user intent or security controls. The default policy should be data minimization—the complete archive stays local, and only passages necessary for the current task are transmitted.

User Experience and Provider Independence

The typical interaction flow is designed to minimize user intervention: the user opens the AI assistant, asks to continue a project, the local memory service searches the archive, retrieves relevant decisions and source messages, supplies context to the assistant, the assistant continues working based on this information, and new messages are archived for future retrieval. Users should also be able to inspect what was retrieved, correct inaccurate project summaries, exclude specific conversations, and disable automation at any time.

The proposal advocates open, documented data formats for the local archive. Users should be able to switch between AI providers without having to rebuild their personal history or rely on proprietary memory formats. Provider-specific adapters handle differences in browser interfaces, message submission, and context limits, while the underlying archive and retrieval system remain independent. This creates room for open-source implementations—a local memory layer that can work with multiple AI services.

Phased Roadmap and Quantifiable Evaluation

The proposal divides development into six incremental phases: local archive (import/export, SQLite storage, full-text search) → automatic capture (browser extension, deduplication, reliability checks) → context retrieval (semantic search, source message retrieval, ranking, context package generation) → browser automation (input detection, context insertion, submission verification) → multi-provider support (adapters, universal formats, context budget management) → reliability and security (long-cycle project testing, retrieval accuracy measurement, recovery testing, privacy control evaluation).

The evaluation criteria are not "does it have a memory feature" but quantifiable outcomes: the percentage of relevant past decisions successfully retrieved, the rate of missed or incorrect retrievals, the frequency with which users must re-supply information, the probability that assistant recommendations contradict recorded decisions, source attribution accuracy, the time required to resume a long-cycle project, the number of interactions requiring manual recovery, the amount of personal data transmitted to providers, and compatibility across providers and application updates.

The technical appendix provides initial engineering targets: at least 90% retrieval recall on a curated test set of relevant historical passages. The proposal explicitly states that this is a proposed engineering target, not an established performance result.

Technology Choices and Proof of Concept

The technology combinations suggested in the technical appendix are quite restrained: JavaScript and Chrome Extensions Manifest V3 for the browser extension, Python or Node.js for the local service, SQLite for the conversation database, SQLite FTS5 for full-text search, local embedding models and vector indexes for semantic retrieval (optional at the MVP stage), Python or TypeScript for the context manager, optional small local language models for request classification, and provider adapters for interface detection and submission verification.

The design rule is emphasized in bold: keep the database, retrieval engine, and provider adapters separate. Changes to one AI provider should not require rebuilding the conversation archive.

The proof of concept is divided into four phases, each with clear acceptance criteria. For example, Phase 1's acceptance criteria are: imported messages are searchable, duplicates are detected, and original text can be retrieved without alteration. Phase 4's acceptance criteria are: the assistant receives the expected context, the extension detects failures, and users can inspect the supplied content. The proposal recommends running at least 30 representative test questions before drawing conclusions.

The initial prototype scope is limited to one provider and plain-text conversations. Images, audio, video attachments, complex multi-agent workflows, and fully autonomous recovery can be added later. The prototype does not require running large language models locally—conventional search and database software is sufficient to support the initial version. If the chosen browser interface can be reliably integrated, no API is needed either.

What Makes This Proposal Truly Worth Noticing

At the outset, Singels explicitly states that he does not claim ownership of this idea. "Anyone is welcome to use this idea, develop it, adapt it, build software based on it, or take it in a completely different direction. You don't need my permission." What he is really worried about is something else: the idea being copied by a large company, buried in an internal backlog, and shelved indefinitely—while the underlying problem remains unsolved.

Most of the proposal's technical content is the integration of mature components rather than breakthrough innovation. Its value lies in proposing a clear problem framework—separating personal history from model inference—and providing an actionable, verifiable, privacy-conscious starting point. For a user without a technical background, this way of thinking—starting from real pain points, rejecting vendor lock-in, and emphasizing quantifiable evaluation—is itself worthy of serious attention from AI product architects.

The proposal's concluding sentence encapsulates the entire approach: a user's conversation history should function as a persistent personal resource, not information that must be repeatedly rebuilt every time the assistant loses the thread.

One-line Summary

A Dutch autistic man proposes the PLML concept: store conversations locally, retrieve context on demand, and solve the AI assistant amnesia problem.

Paragraph Summary

The article introduces "Persistent Local Memory Layer" (PLML), a technical proposal by Dutch autistic man Bert Singels based on his own frustrating experiences. The proposal identifies that the core pain point of AI assistants is not insufficient storage but retrieval failure—even when conversation history still exists, the model cannot retrieve relevant fragments when needed. PLML decouples long-term storage, context retrieval, and language model inference: users save complete conversation archives locally (SQLite + hybrid full-text/semantic indexing), and a lightweight local agent retrieves relevant decisions and source messages with each request, transmitting only the context necessary for the current task to the model. The architecture includes five components and a dual-mode provider interface, emphasizing data minimization, open formats, and quantifiable evaluation (with an initial target of 90% retrieval recall).