Proposal Persistent Local Memory for AI Assistants

A Personal Introduction

My name is Bert Singels. I'm a 54-year-old man from the Netherlands, and I have autism. I'm an ordinary AI user, not a software developer or someone working in the technology industry. I came up with this proposal through my own experiences using AI assistants and repeatedly running into the same problem: important information, decisions, and corrections can get lost or become inaccessible, even when they are still present somewhere in the conversation history.

Over time, I started thinking about whether there might be a more fundamental solution. Rather than relying entirely on individual AI providers to remember everything, why not let users keep their own complete conversation history and use a local system to retrieve the right information whenever it is needed?

That idea became this proposal.

I'm sharing it because I believe reliable, persistent memory could make AI assistants significantly more useful, and because I don't think solving this problem should depend on one company alone.

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 do not need my permission to explore the concept or turn it into something useful. I am not publishing this to keep the idea to myself or to claim exclusive ownership over its implementation.

What I do hope is that the idea will be given a genuine opportunity to become reality. I would hate to see it copied by a large company, buried in an internal backlog, and left there indefinitely while the underlying problem remains unsolved.

I would much rather see independent developers, researchers, open-source communities, and AI providers work on it, experiment with different approaches, and make meaningful progress. If someone can build a better solution than the one described here, that would be a good outcome.

I don't have all the technical answers, and I don't pretend that every detail of this proposal is already solved. My contribution is the idea, the reasoning behind it, and a practical starting point for exploring how it could work.

The goal is not to own this idea. The goal is to make sure it has a chance to become something real that people can actually use.

Proposal: Persistent Local Memory for AI Assistants

A User-Controlled, Provider-Independent Architecture for Long-Term AI Continuity

Document type: Technical and product proposal

Status: Proposed design

Intended audience: AI providers, product architects, software engineers, privacy engineers and open-source developers

---

1. Executive Summary

Current AI assistants can produce sophisticated answers, help solve complex problems and support users across long-running projects. However, continuity between conversations and across extended work sessions remains a significant usability challenge.

Users may have extensive conversation histories containing decisions, technical details, previous attempts, corrections and unresolved tasks. Even when that history remains available in the application, the AI may not have reliable access to the relevant information when it is needed.

This proposal introduces a Persistent Local Memory Layer (PLML): a user-controlled software component that stores conversation history locally, retrieves relevant context and supplies that context to the AI assistant currently in use.

The proposed system combines:

• Local conversation storage.
• Full-text and semantic search.
• Context retrieval from original messages.
• A lightweight local AI agent for browser interaction and context management.
• Automatic context injection through the existing user interface, where technically and contractually permitted.
• Optional integrations with officially supported APIs and connectors.
• A provider-independent data format.

The complete conversation archive does not need to be hosted by the AI provider. Only the context required for a particular interaction needs to be transmitted.

The objective is straightforward: the user should not have to repeatedly reconstruct information that already exists in their own conversation history.

2. The Problem

AI assistants are increasingly used for work that extends beyond a single question or conversation. Examples include software development, system administration, technical troubleshooting, research, writing and long-term planning.

These activities depend on accumulated context.

A user may have already explained their system configuration, tested several solutions, rejected certain approaches and documented the reasons for those decisions. If the assistant cannot retrieve that information later, the user must repeat work that has already been completed.

This creates several problems:

1. Repeated effort: Users must re-enter information and explain previous work.
2. Lost continuity: Earlier decisions, constraints and failed approaches may be overlooked.
3. Repeated mistakes: The assistant may suggest an approach that was already tested or rejected.
4. Reduced trust: Users cannot reliably predict whether previous work will remain available to the assistant.
5. Provider dependence: Personal knowledge accumulated in one service may be difficult to reuse with another.

The underlying issue is not simply whether conversation data is stored. It is whether the right information can be retrieved and supplied to the AI at the right time.

3. Proposed Solution

Introduce a local memory service that operates independently of the AI provider.

The service maintains a searchable archive of conversations and associated project information. When a user submits a new request, the service identifies relevant historical context and makes it available to the assistant.

The central AI remains responsible for reasoning and generating the answer. The local component provides continuity and context retrieval.

Core principle

Store the history locally. Search locally. Share only what is needed.

This separates three functions that do not need to be implemented in the same system:

• Long-term storage.
• Context retrieval.
• Language-model inference.

A local memory service does not need the full reasoning capabilities of a large language model. Most of its work can be handled by conventional software, a search index and, where useful, a relatively small local model.

4. System Architecture

The proposed architecture contains five principal components.

4.1 Local conversation archive

A local database stores conversation messages and their associated metadata.

Potential fields include:

• Provider and conversation identifier.
• Message identifier and chronological position.
• Timestamp and speaker.
• Message content.
• Project or topic associations.
• Links to attachments and locally available files.
• References to decisions, corrections and unresolved tasks.

SQLite or a comparable local database would be sufficient for an initial implementation. Full-text indexing and an optional vector index would support different retrieval methods.

The archive would be stored on the user's own device, under the user's control.

4.2 Conversation capture

A browser extension or supported application integration captures new messages and adds them to the archive.

Possible integration methods include:

• Official export and import facilities.
• Provider-supported APIs or connectors.
• Browser extensions that interact with the rendered conversation interface.
• Supported local application interfaces.

For browser-based capture, the implementation should detect messages, preserve their order and avoid storing duplicates. It should also identify incomplete responses, edited messages and deleted content where the interface makes that information available.

Browser-interface integration is a practical implementation option, although it may require adaptation when the underlying website changes.

4.3 Local retrieval engine

When a new request arrives, the retrieval engine searches the archive for relevant material.

A robust implementation can combine:

• Full-text search for exact terms, commands, model numbers and technical identifiers.
• Semantic search for related concepts expressed using different wording.
• Metadata filtering by project, provider, date or conversation.
• Recency and relevance ranking to prioritize useful context.
• Source retrieval to retrieve original messages rather than relying exclusively on summaries.

For example, a user might ask to continue a Windows backup project without mentioning the particular drive, imaging software or previous troubleshooting steps. The retrieval engine could locate the relevant earlier decisions and supply them to the assistant.

4.4 Local memory agent

A lightweight local agent coordinates retrieval and browser interaction.

Its responsibilities include:

• Identifying which previous conversations are relevant.
• Selecting the appropriate source passages.
• Retrieving additional context when a passage is ambiguous.
• Preparing a compact context package.
• Interacting with the browser interface.
• Verifying that context was submitted and that a response was received.
• Reporting retrieval failures instead of silently inventing missing context.

The local agent does not need to reproduce the capabilities of a large cloud model. Most operations can be performed by conventional code. A small local language model can assist with tasks that benefit from natural-language classification or semantic interpretation.

4.5 AI provider interface

The context package is supplied to the AI assistant currently being used.

There are two principal integration modes.

Mode A: Browser-based integration

A browser extension interacts with the existing chat interface. It can prepare a context message, enter it into the conversation and submit it using the interface's available controls.

This approach can avoid API charges and does not require the provider to implement a dedicated memory API. It does, however, depend on the browser interface, applicable service rules and appropriate automation safeguards.

Mode B: Supported API or application integration

Where an API is available and appropriate, the local service can send context directly to the provider.

This may offer more predictable control over message submission and response handling, but can introduce usage costs, credentials management and provider-specific integration requirements.

The local memory architecture should support both modes without tying the archive to either one.

5. Context Management

Retrieving relevant history is only useful if the selected information is supplied in a form the model can process.

The system should distinguish between:

• Current project state.
• Important user requirements.
• Previous decisions and their rationale.
• Approaches that have already failed.
• Explicit corrections to previous assistant behavior.
• Outstanding questions and next steps.
• Original messages needed to verify any of the above.

The context manager should prioritize original source material when accuracy matters. 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 controlled by its actual limits.

If the retrieved history is too large, the system should prioritize the most relevant material, split work into coherent sections where appropriate, or request further retrieval in a subsequent interaction.

Simply sending multiple large messages is not always equivalent to preserving context: earlier messages may still fall outside the model's effective context window. The system must therefore track what has actually been supplied and avoid assuming that every historical detail remains available.

Verification

Before using retrieved information, the system should be able to identify its source and distinguish verified historical facts from inferred summaries.

If no sufficiently relevant material can be found, it should state that limitation rather than manufacture continuity.

6. Local Storage and Scalability

Text conversations require relatively little storage compared with photographs, audio and video.

As an illustrative estimate, consider a user who exchanges approximately 24,000 words per day over a year. At an average of six bytes per word, including spaces and punctuation, the raw text would occupy approximately 52 MB annually.

Allowing 200 MB per user per year provides a larger planning allowance for metadata and storage overhead, although actual usage will vary.

At that illustrative rate:

Population	Annual storage
1 user	200 MB
1,000 users	200 GB
1 million users	200 TB
900 million users	180 PB

These figures are estimates, not measured averages for any particular AI provider.

The central architectural advantage is that each user's archive can remain on their own device. A provider offering local memory functionality would not need to centrally host every user's complete conversation history merely to make that history searchable.

Local storage also avoids requiring the entire archive to be loaded into active model context. Search and retrieval select only the information needed for a particular request.

7. Privacy and Security

Local-first storage can reduce the amount of personal conversation data held by a provider, but it does not eliminate security requirements.

The system should include:

• Local access controls and optional disk encryption.
• Clear permission boundaries for browser access.
• Protection against unauthorized access by other local applications.
• Secure handling of credentials and provider sessions.
• Explicit control over which retrieved passages may be transmitted.
• A visible indication of what context is being shared.
• Data export, deletion and retention controls.
• Protection against malicious instructions embedded in archived messages or retrieved documents.

Archived messages should be treated as historical information, not 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: keep the complete archive locally and transmit only the passages necessary for the current task.

8. User Experience

The feature should work with minimal user intervention.

A typical interaction would be:

1. The user opens their preferred AI assistant.
2. The user asks to continue an existing project.
3. The local memory service searches the conversation archive.
4. The service retrieves relevant decisions, constraints and source messages.
5. The service supplies the context to the assistant.
6. The assistant continues the work using that information.
7. 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 whenever they choose.

The system should not require users to manually maintain elaborate memory notes simply to compensate for missing conversational continuity.

9. Provider Independence and Interoperability

The local archive should use an open, documented data format.

A user should be able to switch between AI providers without having to rebuild their personal history or depend on a proprietary memory format.

Provider-specific adapters can handle differences in browser interfaces, message submission and context limits. The underlying archive and retrieval system should remain independent.

A common schema would make it easier for independent developers to create compatible extensions, desktop applications and local memory agents.

This also creates an opportunity for an open-source implementation that can be used with multiple AI services.

10. Implementation Roadmap

A practical development process can be divided into incremental stages.

Phase 1: Local archive

• Import conversation exports.
• Store messages in a local database.
• Preserve chronological order, identifiers and metadata.
• Implement full-text search.
• Provide a simple interface for browsing and exporting history.

Phase 2: Automatic capture

• Implement a browser extension for a selected provider.
• Capture new messages where technically and contractually permitted.
• Detect duplicates and incomplete captures.
• Add reliability checks and recovery mechanisms.

Phase 3: Context retrieval

• Add semantic search and project-level indexing.
• Retrieve original source messages.
• Rank results according to relevance and recency.
• Generate compact, source-linked context packages.

Phase 4: Browser automation

• Identify the active conversation and input interface.
• Insert the prepared context.
• Verify submission and response completion.
• Handle errors and interface changes through DOM inspection and accessibility information where available.

Phase 5: Multi-provider support

• Add adapters for additional AI services.
• Maintain a common archive format.
• Allow users to choose the provider for each task.
• Implement context-budget management for different models.

Phase 6: Reliability and security

• Test long-running projects.
• Measure retrieval accuracy and missed-context rates.
• Test recovery after browser and application updates.
• Evaluate privacy controls, malicious archived content and unauthorized access scenarios.

This staged approach allows a useful prototype to exist before every integration is complete.

11. Evaluation Criteria

The project should be evaluated against measurable outcomes rather than the mere existence of a memory feature.

Recommended metrics include:

• Percentage of relevant historical decisions successfully retrieved.
• Rate of missed or incorrectly retrieved context.
• Frequency with which users must repeat previously supplied information.
• Rate of repeated recommendations that contradict documented prior decisions.
• Accuracy of source attribution.
• Time required to resume a long-running project.
• Number of interactions requiring manual recovery.
• Amount of personal data transmitted to the provider.
• Compatibility across providers and application updates.

A successful implementation should improve continuity without introducing excessive latency, unreliable automation or unnecessary disclosure of personal information.

12. Benefits for AI Providers

A local memory layer could provide benefits beyond user convenience.

Improved user experience: Assistants can continue long-running work with less repeated explanation.

Reduced friction: Users spend less time reconstructing context and more time accomplishing their goals.

Provider flexibility: Users can choose a model for its capabilities rather than remaining tied to a single proprietary history system.

Privacy differentiation: Providers can offer an architecture in which complete personal archives remain under user control.

A broader developer ecosystem: An open local-memory interface could support independent tools, extensions and integrations.

Better continuity without requiring unlimited model context: Retrieval supplies selected historical information rather than requiring the model to process every previous message.

The feature would not eliminate model errors or guarantee correct reasoning. It would address a specific, measurable source of failure: the inability to reliably reuse information that already exists in the user's history.

13. Recommendation

AI providers should treat persistent, user-controlled conversational memory as a core capability for long-term assistance rather than an optional convenience.

The recommended direction is a local-first architecture with:

1. A durable, searchable conversation archive.
2. A retrieval system that can locate original messages.
3. A lightweight local agent for context preparation.
4. Provider-independent data storage.
5. Browser-based and officially supported integration options.
6. Explicit privacy controls and transparent context sharing.
7. Measurable reliability standards.

The first implementation does not require a new large language model or a provider-wide infrastructure redesign. It can begin as an independent local application and browser extension, then evolve through testing and wider compatibility.

Conclusion

The central challenge is not storing more text in the AI model itself. It is ensuring that useful historical information remains accessible when the user needs it.

A local memory layer offers a practical way to separate personal history from model inference, reduce dependence on a single provider and support continuity across long-running projects.

The user's conversation history should function as a persistent personal resource, not as information that must repeatedly be reconstructed whenever the assistant loses the thread.

The technology needed to build this system is largely composed of established software components. The opportunity lies in integrating them into a dependable, privacy-conscious and provider-independent experience.

Technical Appendix: Persistent Local Memory for AI Assistants

Document: Technical architecture and proof-of-concept plan

Version: 1.0

Objective: Demonstrate reliable, provider-independent conversational continuity using locally stored history.

A. Architecture diagram

flowchart TD

U\[User\] \--\> B\[AI provider in browser\]

B \--\> E\[Browser extension\]

E \--\>|Archive messages| DB\[(Local conversation database)\]

E \--\>|New question| R\[Local retrieval engine\]

DB \--\> R

R \--\> S\[Context selection and verification\]

S \--\>|Relevant source passages| E

E \--\>|Context \+ current question| B

B \--\>|AI response| E

E \--\> DB

R \<--\> L\[Optional local language model\]

The browser extension connects the existing AI interface to the local memory service. The database remains on the user's computer. Only selected context is inserted into the provider conversation.

B. Principal components

Component	Suggested technology	Responsibility
Browser extension	JavaScript, Chrome Extensions Manifest V3	Capture messages and interact with the chat interface
Local service	Python or Node.js	Coordinate storage, retrieval and automation
Conversation database	SQLite	Store messages, timestamps and conversation identifiers
Full-text search	SQLite FTS5	Find exact words, commands and technical identifiers
Semantic retrieval	Local embedding model and vector index, optional for MVP	Find conceptually related passages
Context manager	Python or TypeScript	Rank results, select source passages and respect context limits
Optional local model	A locally hosted small language model	Help classify requests and identify relevant projects
Provider adapter	Browser-specific extension module	Handle interface detection, submission and response verification

Design rule: Keep the database, retrieval engine and provider adapter separate. A change to one AI provider should not require rebuilding the conversation archive.

C. Proof of concept

Phase 1 — Local archive

Goal: Prove that conversation history can be stored and searched reliably.

1. Import an existing conversation export.
2. Preserve message order, role, timestamp and conversation identifier where available.
3. Store messages in SQLite.
4. Implement full-text search.
5. Display search results with links or references to their source conversations.

Acceptance criteria: Imported messages are searchable, duplicates are detected and the original text can be retrieved without alteration.

Phase 2 — Automatic browser capture

Goal: Keep the archive up to date without manual exports.

1. Create a Chrome extension for one selected AI provider.
2. Detect completed user and assistant messages in the rendered interface.
3. Send captured messages to the local service.
4. Record message identifiers or content hashes to prevent duplication.
5. Detect incomplete captures and provide an error indicator.

Acceptance criteria: New messages are archived automatically, in the correct order, without duplicating previously captured messages.

Phase 3 — Context retrieval

Goal: Recover useful information from previous conversations.

1. Enter a new question into the local memory interface.
2. Search the archive using full-text retrieval.
3. Optionally add semantic retrieval.
4. Rank matching passages by relevance and project association.
5. Retrieve original messages around each match.
6. Build a concise context package containing decisions, constraints, failed approaches and open tasks.

Acceptance criteria: A test set of questions about previously discussed projects retrieves the correct historical information and includes traceable source passages.

Phase 4 — Browser integration

Goal: Supply recovered context to the AI automatically.

1. Detect the active conversation and input field.
2. Insert a clearly delimited context message.
3. Submit it through the browser interface.
4. Verify that the submission succeeded.
5. Submit the user's actual question, or combine it with the context where appropriate.
6. Confirm that the resulting answer arrives and archive it.

Acceptance criteria: The assistant receives the intended context, the extension detects failures and the user can inspect what was supplied.

Browser interaction should use the supported interface and comply with applicable service rules. If the interface changes, the extension should detect the failure rather than silently continuing with incorrect assumptions.

D. Initial test scenario

Use an existing technical project with several previous conversations.

1. In an earlier conversation, record a system configuration, a decision and a rejected solution.
2. Start a fresh conversation with the same provider.
3. Ask a question that depends on those earlier details without repeating them.
4. Let the local retrieval engine locate the relevant messages.
5. Inject the context automatically.
6. Check whether the answer respects the earlier decision and avoids the rejected solution.
7. Inspect the retrieved sources and verify that no critical detail was omitted.

Run at least 30 representative test questions before drawing conclusions about reliability.

E. Success metrics

• Retrieval accuracy: Were the relevant earlier messages found?
• Source fidelity: Does the supplied context match the original messages?
• Continuity: Does the assistant respect previously recorded decisions?
• Automation reliability: Were capture and submission completed successfully?
• Privacy: Was only the intended context transmitted?
• Recovery: Does the system detect missing context or interface failures?

For an initial target, aim for at least 90% retrieval recall on a curated test set of relevant historical passages. This is a proposed engineering target, not an established performance result.

F. Scope and exclusions

The first prototype should support one provider and text-only conversations. Image, audio and video attachments, complex multi-agent workflows and fully autonomous recovery can be added later.

The prototype does not require a locally running large language model. Conventional search and database software are sufficient for the initial version.

It also does not require an API if the selected browser interface can be integrated reliably. An API adapter can be added later as an alternative transport mechanism.

G. Deliverables

The proof of concept should produce:

1. A working browser extension.
2. A local database and searchable archive.
3. A context retrieval and assembly service.
4. Automatic context insertion into one AI provider's interface.
5. A test suite and retrieval evaluation report.
6. Installation instructions, configuration documentation and privacy controls.

Definition of done: A user can resume a previous project in a new conversation, without manually copying the earlier history, and the assistant receives relevant, source-verifiable context from the local archive.

Final technical recommendation

Build the first version around SQLite, full-text search, a small local service and a browser extension. Introduce semantic search only after the basic capture-and-retrieval workflow is proven.

This minimizes dependencies, keeps the data under the user's control and establishes a measurable foundation for a provider-independent personal memory system.