I Updated My AI Model and Lost Everything We Built Together. So I Fixed It.
There is a moment that anyone who works seriously with AI will recognize.
You have been using the same assistant for weeks. It knows your style. It understands the context of your project without you needing to re-explain it every time. There is something that feels like a working relationship — a rhythm that took time to develop.
Then a new model comes out. Better on every benchmark. Faster. Cheaper. You update.
And everything is gone.
Not backed up somewhere. Not archived. Gone — because it was never truly stored anywhere. It lived inside a context window that closed the moment the session ended, and the new model has no idea you ever existed.
That moment happened to me. I live in Sinop, Mato Grosso, Brazil. I work as a commercial manager at a wholesale building materials company. I have no formal programming background, no team, no research lab, no GPU cluster. What I had was a 2008 Acer notebook — an Intel T9300, 6 GB of RAM — and a question I could not stop thinking about.
Why does AI have to reset every time?
The Problem Is Architectural, Not Incidental
Large Language Models are stateless by design. Each conversation begins from zero. This is not a bug that will be patched in the next version — it follows directly from how transformers work. An LLM is a function that maps tokens to probabilities. It has no memory. It cannot update itself from individual interactions. The model that responds to you today has no access to what you discussed last week.
The industry's response has been to make context windows larger. GPT-3 started at 2,048 tokens. Today some models handle a million. But this does not solve the problem — it postpones it. A million tokens is roughly 750,000 words, which sounds enormous until you realize that a serious working relationship generates more than that in a few months. And even if windows keep growing, you pay for every token on every call. The cost is not a one-time investment; it compounds indefinitely.
The deeper issue is that memory is not what LLMs do. Asking them to remember is like asking a calculator to hold a conversation. The architecture simply is not built for it.
So I built the architecture that is.
Phoenix V2: The LLM as Consultant, Not Substrate
The core insight of Phoenix V2 is a reframing: the LLM should be treated as an external reasoning consultant, not as the cognitive center of the system.
All persistent state — every memory, every emotional context, the system's model of who you are — lives outside the LLM, in a local SQLite database on your machine. The LLM is called when needed, given the relevant context, and asked to reason. It stores nothing. When you switch to a newer, better, or cheaper model, your relationship continues from where it left off.
The architecture has five subsystems working together:
The Memory Agent retrieves the most relevant memories for each interaction, scored by a combination of semantic similarity, recency, and importance. High-priority facts survive indefinitely; low-priority ones decay. This is the same three-factor model introduced in the Generative Agents research from Stanford (Park et al., 2023) — the closest academic precedent to Phoenix V2.
The Planning Agent builds a structured prompt from everything on the Blackboard — your current message, the retrieved memories, the system's emotional state, its self-model — and sends it to the LLM. This is the only unconditional API call in the pipeline.
The Reflection Agent checks the draft response with a local heuristic before it reaches you. Only flagged responses go back to the LLM for revision. Most pass through without an extra API call.
The Personality Agent modulates tone and style according to the current affective state. Phoenix has a bad day when interactions go badly, and recovers. This is not a gimmick — it is what makes the behavior consistent and readable over time.
The SubconsciousEngine runs in the background on a timer, independent of your conversations. It consolidates memories, generates reflective insights, and updates the system's beliefs about you and itself. It only runs when the system is not under interactive load, and only on users who have been active in the last six hours. Think of it as the system processing its day while it waits for you.
All of this coordinates through a Blackboard — a shared working memory that the agents read from and write to within each processing cycle, without knowledge of each other. The pattern comes from a 1980 speech-understanding system called HEARSAY-II. It turns out that a good idea from 1980 is still a good idea in 2026.
What "Local-First" Actually Means
Every memory, every emotional state, every insight the system generates about you — it all lives in a single SQLite file on your machine. You own it completely. You can back it up, move it to another computer, or delete it to start over.
What leaves your machine: the text of your messages (sent to the LLM), and the text of memories being stored or retrieved (sent to the embedding API to generate search vectors). That is it. No vendor holds your data. No subscription can delete your history.
This is what Kleppmann et al. called "local-first software" in 2019: the authoritative copy is yours, and the cloud is optional infrastructure, not the owner.
Built on a 2008 Notebook, On Purpose
Phoenix V2 runs on an Acer 7720 from 2008. Not as a proof of concept — as the actual development machine. The T9300 processor, the 6 GB of DDR2 RAM, no GPU.
This was a deliberate design constraint. If persistent, emotionally-aware AI requires a data center, it belongs to whoever owns the data center. If it can run on hardware from 2008, it belongs to anyone with a computer.
The entire pipeline requires no GPU. Embedding generation uses a remote API call. LLM calls go to whichever provider you configure — the client is a single file, and swapping providers is a one-line change.
The Paper and the Book
I have just published a companion preprint describing the architecture formally: "Phoenix V2: A Cognitive Architecture for Persistent, Emotionally-Aware AI Assistants on Consumer Hardware."
It covers the formal characterization of the amnesia problem, the full architecture with equations and a system diagram, each subsystem in detail, the comparison with Mem0, MemGPT/Letta, Zep, and Generative Agents, and an honest account of what Phoenix V2 does not yet do — there are no quantitative benchmarks, and the local embedding path is future work.
The companion book, "Building Persistent AI: Designing an Assistant That Remembers, Learns and Belongs to You", is a complete implementation guide written for developers without prior AI research experience. Twenty-five chapters, seven appendices, and the full source code distributed under the MIT License. The book explains not just how Phoenix is built, but why every decision was made — because the goal is not for you to run Phoenix, but for you to understand it well enough to build something better.
The Point
I am not a researcher. I do not have a PhD. I have a commercial management job in a mid-sized Brazilian city and a very old laptop.
What I have is a question that would not leave me alone, eighteen months of work, and a clear answer to that question.
The properties we most want from an AI partner — memory, personality, growth — are exactly the properties that LLM architecture cannot provide internally. Separating them from the model has a practical consequence: your relationship with your assistant does not need to reset when a provider updates, reprices, or retires a model. The relationship lives in a file you own.
The code is open. The book explains everything. If you are a developer who has ever lost work to a context window, or a builder who wants to understand how persistent AI actually functions rather than just use it — this is for you.
📄 Paper (Zenodo): https://doi.org/10.5281/zenodo.22645361
💻 Source code (GitHub, MIT): https://github.com/cleversonbrsantos-art/Phoenix
📖 Book: https://leanpub.com/phoenix-buildingpersistentAI
I am happy to discuss the architecture, the design decisions, or the strange experience of building something like this on a 15-year-old laptop. Leave a comment or send a message.
Top comments (1)
"Happy to answer questions about the architecture, the design decisions, or the hardware constraint. What aspect of Phoenix V2 are you most curious about?"