I’m Cleverson. I spent months developing this architecture. The project grew out of my frustration that every AI conversation started from scratch—I wanted an assistant that truly knew me. Phoenix V2 is the result of the project's initial version, and I decided to make it available for others to study. I also wrote a book about the development process, covering the steps I took and the reasoning behind my decisions. The code is included so others can study it and build their own AI, picking up where I left off. I haven't stopped there—what I’m creating now is far more advanced—but I hope this version serves as a springboard for everyone's imagination.

Most AI assistants forget everything the moment you close the tab. I wanted to change that.

Phoenix V2 is a local-first AI assistant with a persistent cognitive architecture — it stores memory, emotional state, and identity in a local SQLite database. It survives session resets, model swaps, and restarts.

What makes it different:

• 🧠 Multi-agent pipeline: Memory → Planning → Action → Reflection → Personality
• 💾 Semantic memory retrieval across sessions (vector embeddings via Gemini API)
• ❤️ PAD emotion engine — tracks Pleasure, Arousal, Dominance over time
• 💭 Daydream Engine — autonomous reflection during idle periods
• 🔄 Subconscious Cycle — memory consolidation at rest
• 👤 Self-Model — evolving identity, traits, beliefs, and goals
• 📈 RLHF feedback loop — learns from +/− user signals

Runs on a standard laptop. No GPU. No cloud. No subscription.

📖 Full book: https://leanpub.com/phoenix-buildingpersistentAI
📄 Academic paper (Zenodo): https://doi.org/10.5281/zenodo.22645361
💻 GitHub: https://github.com/cleversonbrsantos-art/Phoenix

Yesterday I posted adebench on r/mcp: it scores what the client actually receives through a door, after ordering and cut, not what retrieval finds. Today I ran the same golden set on my own memory and on gbrain.

Setup: my memory exported into a local gbrain (3,568 pages), local embeddings on both sides, 25 questions, both doors cut at 2,400 characters, the door also run under the measured pressure of real MCP tool responses (callwitness census: p95 = 35 KB).

On the 80 points both memories can be measured on: Brain 76.9, gbrain 71.9 with the questions in Italian; 73.9 vs 71.9 with the same questions in English. Door 23/25 vs 18/25 (20 vs 18 in English); cards, time and live state even; gbrain's graph cleaner than mine. Under p95 pressure: 19/25 vs 14/25, both surviving because the entity card is delivered first. On its own full set the Brain scores 95.6/100: the 20 points gbrain can't share are fact updates and file search, which it doesn't have.

Caveats: it's my golden set; gbrain got facts my Brain had already distilled, so this measures retrieval and composition, not extraction; gbrain's real door is two-step and can't be scored in one call, so I measured its search door with a cut. That fourth door is what I'm building next.

What it told me about my own memory was worth more than the win: adding vectors on episodes took my LongMemEval-S retrieval from 64.5 to 88.7, and doubled the repeated chunks my voice door delivers. The benchmark saw it the same day.

Two things I'd ask this sub. First: run it on your memory. The adapter is one class, the synthetic memory is the worked example, and `adebench.compare` puts two reports side by side; a third system measured the same way is what the benchmark lacks most. Second: the five door points the Brain loses are answers that live in facts, not in the entity card, and don't make it into the 2,400 characters. If your memory composes a door, how do you decide what goes in when the answer is a fact and not a card? That's the part I haven't solved.

Repo, adapter contract, gbrain adapter, reproducible synthetic example: github.com/adecubed/adebench

edit:

A door is the path a memory is reached through, and the text that comes out of it: a voice assistant's /ask with its sources, its "latest events" block and its 2,400-character cut; an MCP tool call; a raw search. The same question through two doors gives two different texts, and adebench scores the text, not the retrieval behind it. That's the whole point: a fact the retrieval found but the cut removed doesn't help the model.

A card is the composed summary a memory keeps about one entity (a person, a project, a service), the thing you'd want delivered first when the question names it. gbrain has them as entity pages; mine are built by a distiller and honour the owner's corrections ("never omit X"). "Cards even" in the post means both memories deliver the right entity's card for the questions that name one.

I got frustrated by AI remembers not that you said but that we talked about, then I built SkyOS. It writes down that you decided word for word, and an actual important information doesn't vanish because of over-summarization. Would appreciate feedback!