Most developers using AI every day have run into the same strange problem.
The models are getting better, but the workflow still feels weirdly stateless.
You explain your project to ChatGPT. Then you explain it again to Claude. Then you explain it again to Cursor. Then you try a local model and start from zero. Then you open a new chat because the old one got messy, and you rebuild the same context again.
The problem is not that AI is useless.
The problem is that the useful context is trapped in the wrong places.
One tool knows how you like code reviewed. Another knows the architecture of your project. Another knows the product you are building. Another knows your writing style. Another knows nothing. Each assistant develops a partial picture of you, but none of that context moves cleanly between tools.
So the developer becomes the transport layer.
You copy old summaries. You paste project descriptions. You maintain prompt files. You explain the same constraints again. You keep telling the model what not to do. You build a small ritual around making your AI tools useful before you can actually use them.
That felt wrong to me.
If AI is becoming part of the development environment, then memory cannot stay trapped inside individual chat products. The memory layer should be independent from the model and the interface.
That is why I built Deja Vu.
Deja Vu is a local-first memory layer for AI tools. It stores useful context in a local SQLite database and exposes it through developer-friendly interfaces, including MCP, so different AI tools can access the same durable memory instead of each one starting from zero.
The idea is simple:
Your model can change.
Your assistant can change.
Your editor can change.
Your memory should persist.
*The Real Problem Is Context Fragmentation
*
A lot of people describe this as “AI forgets.”
That is not quite right.
AI tools do remember things. Some remember through chat history. Some have explicit memory features. Some infer preferences. Some store project context. Some rely on long context windows. Some let you upload docs. Some let you configure rules.
The issue is that every tool remembers separately.
That creates fragmentation.
For a developer, context is not one thing. It is a mix of durable facts, temporary task state, project conventions, personal preferences, architectural decisions, abandoned approaches, deployment details, naming patterns, API assumptions, team habits, and taste.
Some of that belongs in documentation.
Some belongs in code comments.
Some belongs in issue trackers.
Some belongs in commit history.
But a lot of it lives in the working relationship between you and the AI system.
For example:
You prefer direct code review instead of motivational feedback.
You want TypeScript examples unless stated otherwise.
Your app uses a specific auth provider.
Your backend has one ugly legacy service that should not be touched unless necessary.
Your frontend components follow a naming convention.
You already tried one architecture and rejected it.
You like short answers while debugging, but deeper explanations while learning.
These are not always worth putting in a README. They are also not random chat history. They are memory.
And right now, that memory is scattered.
Chat History Is Not Memory
One tempting answer is to keep longer chat history.
That helps, but it is not the same as memory.
A transcript is raw material. Memory is structured continuity.
If a system remembers everything, it has not solved memory. It has created a search problem, a privacy problem, and eventually a trust problem.
A useful memory layer needs to decide what is worth carrying forward.
There is a major difference between saving every sentence a user typed and remembering that:
The user is building a local-first AI memory tool.
The project uses SQLite as the default local store.
The user dislikes over-engineered abstractions.
The user prefers launch copy that sounds founder-written rather than corporate.
The user already rejected a certain positioning angle.
Those are durable pieces of context. They are likely to matter again.
The memory layer should extract that kind of information, deduplicate it, update it when it changes, and make it available when relevant.
It should not blindly hoard everything.
That distinction became central to Deja Vu.
The goal is not infinite recall.
The goal is useful continuity.
Why I Wanted Memory Outside the Chatbot
The more I used AI tools, the more obvious it became that the assistant should not own the memory.
The assistant is just one interface.
Today I might use ChatGPT for strategy, Claude for writing, Cursor for code, a local model for private work, and a specialized agent for some specific task. Tomorrow that stack might change. Better models will come out. Better editors will appear. New agents will become useful. Some products will disappear. Some will become too expensive. Some will change policies. Some will stop fitting the way I work.
The memory should not be trapped inside whichever interface I happened to use last month.
This is especially important for developers because we already understand the value of portable state.
We do not want our source code locked inside one IDE.
We do not want our environment variables trapped inside one hosting provider.
We do not want our database accessible only through one dashboard.
We do not want our credentials stored in a browser we cannot leave.
So why should our AI memory live inside one chatbot?
The more useful AI becomes, the more valuable memory becomes. If memory stays platform-owned, it becomes a very quiet form of lock-in.
Not lock-in through code.
Lock-in through context.
You stay because the tool knows you. You stay because rebuilding that context elsewhere is annoying. You stay because the assistant has become useful over time, even if a better model or interface exists somewhere else.
That is not the future I want.
I want the memory to belong to the user.
The Architecture Is Intentionally Boring
Deja Vu stores memory locally in SQLite.
That choice is not an accident.
SQLite is boring in the best possible way. It is reliable, portable, inspectable, and already everywhere. It does not require a cloud account. It does not require a new backend. It does not require you to trust that some platform will keep exposing your own context back to you.
A SQLite file can be copied.
It can be backed up.
It can be inspected.
It can be encrypted.
It can be moved between machines.
It can outlive the app that created it.
For AI memory, that matters.
The memory lives at:
~/.dejavu/memories.db
That one design decision changes the relationship between the user and the system.
Instead of memory being a hidden profile inside a product, it becomes a local artifact the user owns.
The file has a name.
The file has a location.
The file can be treated like infrastructure.
That is the point.
*What Deja Vu Actually Does
*
At a high level, Deja Vu is built around a simple loop:
- Observe useful context.
- Extract durable memory.
- Store it locally.
- Deduplicate and update it over time.
- Retrieve relevant memory when an AI tool needs context.
The purpose is not to store every message. The purpose is to preserve information that is likely to matter again.
That includes things like:
Project details
User preferences
Technical stack
Writing style
Recurring constraints
Important decisions
Rejected approaches
Useful facts
Ongoing work
The memory layer then makes those facts available through interfaces other tools can use.
Deja Vu includes a CLI, a local REST API, a Python SDK, and MCP support. The MCP piece matters because it lets AI tools connect to memory as an external context source rather than each tool needing its own isolated memory system.
The model should not need to own your memory to use your memory.
That is the basic architecture.
*Why MCP Matters
*
MCP is important because it points toward a more modular AI stack.
Instead of every AI product becoming a closed container with its own tools, memory, documents, and private state, MCP allows assistants to connect to external systems in a more standardized way.
For memory, this is exactly the right abstraction.
An AI tool should be able to ask:
What does this user usually prefer?
What project are they working on?
What context is relevant to this task?
What constraints should I know before answering?
But it should not need to store all of that itself.
The memory can live outside the assistant.
That separation matters.
Once memory is external, the assistant becomes replaceable. You can connect different models and tools to the same durable context layer. You can use hosted models and local models. You can use coding agents and writing assistants. You can experiment with new interfaces without losing continuity.
That is the future Deja Vu is designed for.
A model that can reason.
Tools that can act.
Memory that can persist.
Those should be separate layers.
*Local-First Does Not Mean Anti-Cloud
*
It is worth being precise here.
Local-first does not mean the cloud is bad.
It does not mean sync is bad.
It does not mean AI tools should never use remote inference.
It means the user’s copy is primary.
The user should have the memory in a form they can control directly. From there, they can decide how to sync it, back it up, encrypt it, share it, or connect it to other tools.
That default matters.
If the only copy of your AI memory lives inside a platform account, you are dependent on that platform for access, portability, pricing, export, policy, and continuity.
If the primary copy lives locally, you have leverage.
You can still use cloud models.
You can still use hosted AI tools.
You can still sync across devices.
But the memory itself is not born locked inside a vendor system.
For developers, this should feel familiar. It is the difference between using a cloud service and having your core project state trapped inside that cloud service.
Those are not the same thing.
*The Hard Part Is Not Storage
*
It would be easy to misunderstand Deja Vu as just “put memories in SQLite.”
That is part of it, but it is not the hard part.
The hard part is deciding what becomes memory.
Good memory has to be selective. It has to distinguish durable facts from temporary instructions. It has to avoid duplicating the same preference ten different ways. It has to update when something changes. It has to avoid preserving stale assumptions. It has to retrieve the right context at the right time without flooding the model.
Bad memory is worse than no memory.
If a system remembers too aggressively, it becomes creepy and noisy. If it remembers too little, it is useless. If it remembers stale information, it creates errors. If it hides what it remembers, it becomes hard to trust.
So the design has to be conservative.
Deja Vu is built around the idea that memory should be useful, inspectable, and controllable.
A good memory layer should help the user answer:
What was saved?
Why was it saved?
Where is it stored?
Can I edit it?
Can I delete it?
Can another tool access it?
Is it still true?
That is the difference between memory as infrastructure and memory as a black-box product feature.
*A Simple Example
*
Imagine you are working on a TypeScript project.
Over time, your AI tools learn a few things:
You prefer minimal dependencies.
You use PostgreSQL.
You use Prisma.
You want strict TypeScript.
You prefer functional utilities over class-heavy patterns.
You do not want generated code unless you ask for it.
Your auth flow has a legacy constraint that cannot be changed yet.
Your deployment target is Railway.
You already rejected a serverless architecture because cold starts were an issue.
This context matters constantly.
But it probably lives across chats, editor sessions, docs, and your own memory.
With a shared memory layer, the coding assistant does not need to rediscover all of this every time. It can retrieve the relevant facts before suggesting an implementation.
That does not make the model magically correct.
But it reduces the number of times you have to say:
“No, remember, we are not doing it that way.”
That is the practical value.
The philosophical value is larger:
The context belongs to you, not the assistant.
*Why This Matters More as Agents Improve
*
Memory becomes even more important when AI moves from answering to acting.
A chatbot without memory is annoying.
An agent without memory is risky.
If an agent is going to edit code, browse the web, file issues, prepare emails, update documents, run workflows, or operate across tools, then it needs more than the immediate task instruction. It needs durable context.
It needs to know what matters.
It needs to know what has already happened.
It needs to know what not to repeat.
It needs to know your preferences and constraints.
Otherwise, the agent is powerful but context-blind.
That is not a good combination.
As agents become more capable, the memory layer becomes more important. The user will need a way to carry context across agents, models, and surfaces without handing permanent ownership of that context to each product.
This is why I think AI memory should be treated as infrastructure now, not later.
The category is still early enough to choose better defaults.
*The Default Should Be User-Owned
*
The default path for software is usually platform-owned memory.
It is easier. It is good for retention. It makes the product feel more personalized. It gives the company a stronger relationship with the user. It reduces the incentive to make memory portable.
But personal AI memory is too important to leave entirely inside closed systems.
It is not just a convenience setting.
It is a growing representation of how someone works, thinks, writes, decides, and builds.
That should not be trapped by default.
The better default is:
The user owns the memory.
AI tools request access to it.
The user can inspect it.
The user can move it.
The user can delete it.
The user can use it with a different model tomorrow.
That is the design principle behind Deja Vu.
Not another chatbot.
Not another hosted profile.
Not another place where your context gets stuck.
A local-first memory layer for the AI tools you already use.
*Getting Started
*
Deja Vu is early, but the core idea is already usable.
Install it:
pip install dejavu-memory
Initialize it:
dejavu init
Start the local server:
dejavu serve
By default, the memory is stored locally in SQLite:
~/.dejavu/memories.db
The goal is to make that file the durable memory layer beneath your AI tools.
A file you can own.
A file you can move.
A file your tools can share.
The Future I Want
I do not think the future of AI is one assistant that owns everything.
I think the future is a stack.
Different models for different tasks.
Different tools for different workflows.
Different agents for different jobs.
Local models when privacy matters.
Hosted models when capability matters.
Specialized interfaces for coding, writing, research, operations, and automation.
In that world, memory cannot be trapped inside one product.
It has to move.
A user should be able to switch from ChatGPT to Claude to Cursor to a local model without becoming a stranger to their own tools. A developer should not have to rebuild the same context every time they change surfaces. A personal AI system should get more useful over time without forcing the user into one vendor account forever.
That is the future Deja Vu is trying to make normal.
The assistant should be replaceable.
The model should be replaceable.
The interface should be replaceable.
The memory should persist.
AI memory should be local-first.
AI memory should be portable.
AI memory should be inspectable.
AI memory should be a file you own.
Top comments (0)