Mem0

Mem0 AI

Mem0 AI

Mem0 AI

Mem0 AI

Mem0 AI

Mem0 AI

Mem0 AI

Mem0 AI

Mem0 AI

Mem0 AI

Continual learning in mid-2026. A map of everyone trying to crack it: memory layers, "dreaming" agents, and the Post-Transformer models that learn inside the network

Llion Jones said “2026 is the continual learning year” in the recent Post-Transformer debate. Sutton/Silver call the next phase the "era of experience”. What’s continual learning? Simply put, it’s a model’s ability to continuously improve as it gains experience – without exhibiting catastrophic forgetting. Essentially the stability-plasticity tradeoff for a reasoning model. Essentially it comes down to: where does the memory live? Outside the model. Memory files, vector dbs, graphs. Text is retrieved and pasted back into context. The model stays frozen. In the model's running state. Hidden states or fast weights that change while the model processes input. In the model's weights. What it actually knows. Encoded within the model weights to improve decision making patterns without forgetting. Dev docs today hint at #1 - memory outside the model. But the “2026 is continual learning year” notion does not come from it. Why? Part 1: The Memento stack (today’s stack) There are engineering fixes for the LLM’s memory problem. Julian Togelius & a16z compared it to Memento. In the movie, Leonard functions with his Polaroid and notes. But everyday he is the same man as day 0. Progress around these include: Anthropic's Dreaming: an async job to manage “memories”, explicitly modeled on sleep consolidation. Long context as memory: Visibly good, but with 3 problems. a) Position bias and "lost in the middle" challenge. b) Longer LLM windows come with bigger costs and we’re already discussing “token economics”. c). KV cache bottleneck, and everything evaporates when the request ends. Mem0, Letta, Zep: the popular memory-layer products from startups. AGENTS.md and git-style memory files: But, in this ETH Zurich paper (arXiv 2602.11988) it showed that LLM-generated context files actually reduce task success by about 3% while raising cost over 20%. And human-written ones barely helped too. Part 2: Continual learning, memory within the model (the big bet) Weight updates in large networks trigger catastrophic forgetting. A January 2026 paper tried continual fine-tuning on LRMs (arXiv 2601.18699) but catastrophic forgetting didn’t fade but rather increased. Promising directions that could solve this: TTT layers (arXiv 2407.04620, ICML 2025): the hidden state of the sequence layer is a small model, updated by gradient descent on tokens as they stream in. Matches or beats Transformer / Mamba baselines upto 1.3B params. Titans & Atlas: Titans add a neural long-term memory that decides what to store using a surprise signal. Atlas upgrades the memory's learning rule. Nested Learning + HOPE: Architecture updates different blocks at different frequencies. RNNs are also coming closer to Transformers via viral Memory Caching papers. Dragon Hatchling (BDH): From AI lab Pathway (arXiv 2509.26507). Working memory lives in Hebbian synapses rather than in a KV cache, allowing for an "infinite context window" without quadratic cost. AMI Labs, LFMs, etc. also mention continual learning but I didn’t find much specific info on them in this front. Current State and Future Outlook Where is continual learning in mid-2026? Solved with public access: nothing. Shipping in production: only the dossier stack, all frozen models. Demonstrated at research scale (< 2B params): TTT, Titans, Memory Caching, HOPE, and BDH. What would move the needle imo: Ship memory within the model with forgetting measurably controlled. Two questions though: What OpenAI is brewing in all of this? What’s the blocker to adoption for continual learning models: the missing breakthrough itself, or evals, serving economics, etc? submitted by /u/Ok_Can_1968 [link] [comments]

I built notmemory — auditable, reversible memory for AI agents. v0.1.0 on PyPI. Looking for contributors.

After too many debugging sessions where I had no idea what my agent remembered or why it made a decision — I got frustrated and built something. notmemory is an open-source Python SDK that gives AI agents auditable, reversible memory. Not magic. Just a tamper-proof record of what your agent knew, when it knew it, and the ability to undo the moment it got something wrong. The problem I kept hitting My agent would do something wrong. I'd dig into it. I could see what was currently in memory — but not what it believed at step 47 when it made the bad decision three days ago. Every debugging session felt like archaeology. I got tired of it. What notmemory does Cryptographic audit trail Every write is SHA-256 hash-chained. Like Git commits, but for memory. You always know what changed, when, and in what order. Git-like rollback await memory.rollback(transaction_id) One line. Bad write gone. Hash chain stays valid. GDPR tombstoning await memory.forget(bank_id) Proven deletion with a forensic trail. Not just "deleted from index." Conflict detection Catches duplicate or contradicting beliefs before they cause problems. Health score 0–100. Confidence decay c(t) = c₀ · 2^(−t/30) — stale memories lose weight automatically. No more old beliefs quietly poisoning recall. LangGraph drop-in from notmemory.adapters.langchain import NotMemoryCheckpointer checkpointer = NotMemoryCheckpointer() graph = builder.compile(checkpointer=checkpointer) # that's it — every checkpoint is now auditable MCP server Works with Claude Desktop, Cursor, Windsurf out of the box. Mem0 + SuperMemory sidecars SQLite is the source of truth. Semantic search layers on top. If the sidecar goes down, your data is fine. Multi-agent sync READ / WRITE / ADMIN permissions per memory bank per agent. Install pip install notmemory # with LangChain / LangGraph pip install "notmemory[langchain]" # with MCP pip install "notmemory[mcp]" Quick example import asyncio from notmemory import AgentMemory async def main(): async with AgentMemory() as memory: # store something entry = await memory.retain( bank_id="facts", content={"fact": "Paris is the capital of France"}, source="user", ) # search it result = await memory.recall(bank_id="facts", query="Paris") # undo it await memory.rollback(entry.transaction_id) # delete it with proof await memory.forget("facts") asyncio.run(main()) Where it is today (v0.1.0) 113 tests passing across Python 3.11, 3.12, 3.13 SQLite + FTS5 full-text search LangChain, LangGraph, Mem0, SuperMemory, MCP adapters Confidence decay, Git backup, multi-agent sync MIT license, CI/CD, full README What's coming in v0.2.0 Feature What it does memory.state_at(timestamp) Read memory as it was at any point in time Crypto-shredding Encrypt-on-write + key destruction for real GDPR compliance memory.export_state() Clean JSON snapshot of any memory bank memory.diff(from_ts, to_ts) Human-readable before/after between two timestamps Belief lineage Which downstream writes were caused by a bad early assumption Honest take This is v0.1.0. The core is solid but it's early. SQLite only for now — Postgres is planned. The adapters are sync-layer wrappers, not full replacements for Mem0 or SuperMemory. If you're running a hobby project with one agent — you probably don't need this yet. If you're running multiple long-lived agents, working in a regulated industry, or have already had a production incident you couldn't properly debug — this is for you. Looking for contributors The codebase is around 2000 lines. Every adapter follows the same BaseAdapter pattern so it's easy to get oriented. Good first issues are tagged on GitHub. Things I'd love help with: Postgres backend Crypto-shredding implementation memory.state_at(timestamp) Dashboard UI (FastAPI + SSE already in optional deps) Docs and examples Feedback Would love to hear from: Anyone running agents in healthcare / finance / legal Fleet operators with 5+ concurrent agents Anyone who's already built their own memory audit system and had to solve things I haven't thought of yet Brutal feedback welcome. That's the only way this gets better. GitHub: https://github.com/notmemory/notmemory PyPI: https://pypi.org/project/notmemory/ submitted by /u/imsuryya [link] [comments]

Claude's memory problem isn't a model problem

Every morning for about 4 months, the first thing I did in Claude Code was paste the same paragraph letting him know what my structure was and to read the "rules.md" file Then I'd ask my actual question. I assumed this was just how it had to work. Longer context windows would fix it eventually (1M context is not enough now). I waited for that. Then I noticed something. Even WITH long context, Claude in a fresh session still asked things like "what's your testing framework?" which I'd told it 47 times across previous sessions. The problem wasn't context length. Each session is amnesiac by design. What I tried, in order: CLAUDE.md in the repo root. Free. Works. Biggest single improvement of anything I tried. Claude reads it on every new session. Mine has the stack, the prompt-style I want, the do-not-touch files. Took 30 minutes to write. Should have done it month 1. Inline /memory commands. Mid. Works for the current session, gone next morning. Useful when learning a one-off fact you want Claude to keep until conversation end. Not a real memory layer. A custom MCP server that injects a "memory" tool. Better. Claude could query "what do I know about Sarah's database schema?" mid-session. But I had to remember to teach it new facts manually. That defeated the point. Mem0 + Qdrant under an orchestrator. It watches the conversation, auto-extracts facts every 6 turns, surfaces them into the next session as "previously, you established X about this codebase." This is what actually killed the re-explaining problem for me. The framework I should have started with: Claude's memory isn't a model problem. It's a workflow problem. Fix the workflow first. The free version (CLAUDE.md) gets you 60% of the way. For a single-developer codebase you probably don't need anything fancier than that. I open-sourced the rest of my setup as OpenYabby - Claude Code orchestrator with the Mem0 auto-extraction baked in (MIT, macOS, github.com/OpenYabby/OpenYabby). But honestly: write a CLAUDE.md first. See if you even need anything more. Most people don't. submitted by /u/Interesting-Sock3940 [link] [comments]

I built a system that makes Claude actually remember me across sessions — here's how it works

Every time I opened a new Claude chat I had to explain myself from scratch. Who I am, what I'm working on, who the people in my life are, how I write. It got old. So I built a folder of plain text files. One about me, one for each person I deal with regularly, one per project, and a running log of decisions I've made and why. At the top there's a single file that tells Claude what to read before it does anything else. That's the entire system. No app, no database, no plugin. Now I open a chat and it already knows me. I can say "draft a follow-up to Barry" and it pulls who Barry is, the last few things we talked about, and the way I actually write, without me feeding it anything. I know the obvious reaction is "this is just ChatGPT memory" or "mem0" or "a vector DB with extra steps." It genuinely isn't, and the differences are the whole point: Nothing gets auto-captured. ChatGPT's memory decides for you what's worth keeping, and you end up with a black box you can't inspect. Mine is the reverse. I decide what goes in, so there's no junk, and I can open any file and see exactly what the model knows about me. It's text in git. I can read it, edit it, or delete a wrong fact in about two seconds. It reads, it doesn't retrieve. No embeddings, no similarity search trying to guess which chunk is relevant. The rulebook defines a fixed read order and the model loads the actual files at session start. For one person's worth of context this beat RAG every time I tried it, because RAG kept surfacing the wrong note or missing the obvious one. It outlives the tool. Plain text works with whatever model I switch to next year. No lock-in. On evidence, since fair question: I've run it as my daily driver for a few months. The concrete win is that it drafts emails in my voice that I send with little or no editing, because it has my past messages and my style notes already loaded. The video has three demos of things a cold session flat-out can't do, so you can judge for yourself rather than take my word. Limitations, because they're real: It doesn't scale to a huge corpus. Loading files into context has a ceiling, so this is built for "everything important about one person's working life," not a 10,000-note archive. If your goal is a giant searchable knowledge base, you want retrieval, not this. There's no automatic capture. If I don't write a fact down, it doesn't exist. That's the price of having no noise. Bad taxonomy degrades it quietly. What's stable versus what changes weekly, what lives in the always-read file versus what only gets opened when relevant. Get that split wrong and recall gets worse without you noticing. The code was an afternoon. Figuring out the taxonomy took weeks of actually using it. Short walkthrough with the three demos (recalling a past decision, pulling a person's full context cold, and stitching facts together from separate files): https://youtu.be/tZKAY5mqa_c That's enough to build your own. I also wrote the method up as a guide for anyone who'd rather skip the trial and error, but you don't need it to do this. Happy to get into the folder structure if you're setting one up. That's where the gotchas live. submitted by /u/Michaelcbaldwin [link] [comments]

After 6 months of running AI agents in production I think the framework you pick barely matters. The thing that kills them is something else.

Going to get downvoted for this but here we go. I've been running about 30 agents in production for paying customers for the last 6 months and I'm convinced the framework debate is mostly a distraction. LangChain, CrewAI, AutoGen, OpenAI Agents SDK. Pick whichever one your team already knows. It doesn't matter as much as you think. What actually decides whether your agent works in production is something almost nobody talks about on this sub, and it isn't in the framework. Here's what I've seen kill more agents than every framework bug combined. The agent gets stuck in a loop. It calls the same tool 200 times in 4 minutes because something downstream returned ambiguous data and the LLM decided to retry forever. Your OpenAI bill goes from $3 a day to $400 in one afternoon. By the time you notice you've burned a grand. You can't even tell which agent did it because there's no audit trail. Your VPS reboots overnight for kernel patches. Every agent that was mid-task loses everything. Tomorrow morning the support agent has no memory of yesterday's tickets, the research crew has forgotten what they were investigating, the pipeline agent restarts from scratch. None of these are framework problems. They're memory and state problems. A customer complains the agent gave them wrong info three days ago. You go to debug. There's no record of what the agent saw, what it decided, or which tool calls it made. The framework didn't log that because frameworks aren't observability tools. You shrug and refund. You scaled to 15 agents working together. Two of them have conflicting beliefs about the same customer because their memory isn't shared. The customer gets two different answers in the same conversation depending on which agent replies first. You've been around enough times to realize the part you actually need isn't in the framework at all. What I think the real stack is. The framework just orchestrates LLM calls. Use whatever your team likes. It's the cheap layer. A persistent memory layer that survives crashes, restarts, and redeploys, so the agent has actual continuity. This is the layer that decides whether your agent is a toy or a product. Loop detection at the runtime layer, not bolted on as a wrapper around the framework. Something that catches your agent making the same call too many times in a row and stops it before the bill explodes. An audit trail of every decision the agent made, with a hash chain so you can prove later what happened when the customer pushes back. Screenshots and logs aren't enough when ten thousand dollars is on the line. Shared memory between agents in the same team so they're not having different conversations about the same customer. Cost tracking per agent so you actually know which one ran away with your budget. When I look at what makes the agents that survive production look different from the ones that died, it's never that they picked the right framework. It's that they had this layer underneath, either built carefully in-house or borrowed from somewhere. Full disclosure I'm building one of these tools. There are others. Mem0 and Zep and Letta in the memory space. Helicone and LangSmith in the observability space. Mix and match. Use one or build your own. Just please stop arguing about whether LangChain or CrewAI is better when the thing eating your production agents has nothing to do with either of them. What's been your worst production agent failure? Curious what other people have actually hit. I built a free tool that aims to solve most of this issue, what do you think? submitted by /u/DetectiveMindless652 [link] [comments]

Am I stupid for pivoting to Transparency with Agents over Memory after 6 months?

built an open source memory layer for ai agents. thought the obvious feature people would care about was persistent memory across restarts and shared memory between agents. that was the whole pitch. few months of actual user data in. most of the api calls aren't about memory at all. they're hitting the audit trail (what did the agent do and when), the loop detector (catching when an agent is stuck doing the same thing 20 times in a row), and the per-agent performance dashboard (which agent is wasting tokens, which one keeps crashing, who's drifting off goal). basically people don't really care that their agent remembers stuff across restarts. they care that they can see what it did and pull the plug when it goes off the rails. so i'm wondering if i should just flip the pitch. lead with "observability and accountability for ai agents" instead of "memory for ai agents". memory is table stakes at this point and mem0/zep already dominate that framing. loop detection + audit trail + performance scoring per agent feels like open territory. am i stupid? or is this the obvious move i somehow missed for 3 months submitted by /u/DetectiveMindless652 [link] [comments]

Memory drift? Context bloat? A Claude Code skill I wrote to manage long-running memory libraries

I've been running Claude Code's auto-memory on the same project for about three months. Roughly a month in, the library started getting hard to use: the same lesson recorded under three different filenames, frontmatter missing on half the files, searching for "that bug we fixed last month" returned nothing useful. Every new session, Claude loaded more and more memory files, and the context window kept getting crowded with irrelevant entries. I wrote a skill that enforces a naming schema and a bash audit script that flags drift. Sharing in case it's useful. What the skill does Claude Code's auto-memory (v2.1.59+) writes plain markdown to ~/.claude/projects/ /memory/. The files are yours to read, edit, and version. What it doesn't enforce is structure — naming, required fields, or a Why section on each lesson. Schema on top of auto-memory. _ .md naming, required frontmatter (name / description / type), Why section on feedback entries. Auto-memory still writes; the skill makes Claude write to a spec. Phrase-triggered review. "Audit memory" runs the script. "Review session" walks the recent session and surfaces what's worth keeping. Soft warning, no hooks. Audit reports drift; nothing blocks a write. Plain markdown on disk. Edit, grep, git-commit. The skill doesn't add a database or daemon. Effect One topic per file means Claude lands on the right entry on the first lookup, not after several near-misses. A deduplicated library loads fewer files per session, freeing context for the work itself. Sample audit output: Memory audit · 2026-05-15 · 132 files Hard checks (must be zero): missing frontmatter 0 frontmatter fields 0 feedback missing Why 1 naming violations 0 broken MEMORY.md links 0 Soft signals: oversized files 78 groups over 15 entries 3 untouched 30+ days 31 not in MEMORY.md 0 Hard-rule compliance: 99.2% (1 violation / 132 files) Install Paste this into any Claude Code session: Install the claude-memory-manager skill from https://github.com/jau123/claude-memory-manager Claude handles the rest. To verify, say "audit memory" in a new session. First use The skill activates from natural language. No slash command. You: "Record today's wildcard bug fix" → Claude writes one feedback_*.md entry: filename, frontmatter, Why section, How-to-apply. You: "Review the session" → Claude walks recent session, surfaces 3–5 candidates, asks which to keep. You: "Audit memory" → Runs scripts/audit-memory.sh, reports compliance, lists files that need splitting. vs the built-in auto-memory Schema Audit Long-term result Auto-memory alone None (Claude decides) None with this skill 3-type schema + required fields + Why on feedback One-command script For semantic retrieval over chunked storage, look at vector-backed tools like Mem0, Letta, or Zep. Limits Single-project scope. One memory directory per skill instance. No semantic ranking. The audit is pattern matching; it won't catch two files describing the same concept in different words. Bash; Windows / git-bash untested. Overkill for small libraries. Below ~10 entries or a month of project age, the built-in auto-memory is sufficient. GitHub: https://github.com/jau123/claude-memory-manager Curious whether others have hit this drift problem on long-running Claude Code projects, and how you handled it — especially anyone who tried hook-based enforcement and gave up. Schema feedback (3 types of feedback / reference / project) also welcome. submitted by /u/Deep-Huckleberry-752 [link] [comments]

How are you handling context loss between Claude Code / Cursor sessions?

I've been building with Claude Code and Cursor for the last few months and keep running into the same wall: every new session, the agent forgets what it did last time. My TaskList wipes, the file changes context vanishes, and I end up reading my own commit messages to remind the agent what we were working on. Right now I'm doing this: - Writing a CLAUDE.md or AGENTS.md by hand after every major change - Keeping a separate "what I tried and why it failed" doc - Sometimes literally pasting yesterday's chat back in I've seen Mem0, Letta, MemoryPlugin pop up but none of them seem to travel between tools — they're locked to one model or one IDE. Two honest questions: 1. How are you handling this right now? Markdown files like me, or something smarter? 2. If a tool sat between your IDE and the model — recording what the agent did, why, and let you "rewind" to a previous state — would that be worth paying for, or is this just a "nice to have"? Not selling anything yet, trying to figure out if I'm alone in this or if there's a real gap. Will share what I find in the comments. submitted by /u/kafadankirik [link] [comments]

On "harness engineering": Are people actually building things or just giving impressive labels to "tweaking?"

I see a lot of posts and videos talking about harness engineering, or it could be context engineering, RAG, etc. The thing is, most of them talk about the concepts. And then I hear about all these people actually doing it. And my question is about this disconnect: what does it look like in practice? The way I understand it tools like Claude Code or OpenAI Codex are agents, and the logic that controls what gets fed to the model is the harness. So when people talk about "engineering the context," are they: writing actual programs CLI tools, pipelines, custom API wrappers that manage what gets sent to the model? or mostly just structuring their prompts well and calling it engineering? Same question for RAG--or any other oft-discussed topics: are people actually building retrieval pipelines from scratch, or are they standing up LlamaIndex / Mem0 and saying they're "using RAG" to infomaxx their AI agents? Not trying to be dismissive. I'm genuinely curious about what people are actually doing when they say they have applied these concepts to their agentic workflows. submitted by /u/josh_apptility [link] [comments]

CFS - Conditional Field Subtraction

CFS selects relevant candidates by penalizing regions already covered by previous picks. Results on retrieval ranking: baseline cosine top-K: NDCG@10 0.5123, Recall@10 0.6924 mem0 additive fusion: NDCG@10 0.4903, Recall@10 0.6625 rrf(cosine, BM25): NDCG@10 0.5196, Recall@10 0.6989 rrf(cosine, cos2, BM25): NDCG@10 0.5278, Recall@10 0.7060 rrf(cosine, BM25, CFS): NDCG@10 0.5311, Recall@10 0.7168 Against mem0’s additive fusion, rrf(cosine, BM25, CFS) improves retrieval ranking by +4.08 pp NDCG@10 and +5.43 pp Recall@10. Against rrf(cosine, BM25), adding CFS contributes +1.15 pp NDCG@10 and +1.79 pp Recall@10. https://gist.github.com/M-Garcia22/ff4ec80f5a08ca2fd9234bcc35804d1c submitted by /u/mauro8342 [link] [comments]

Built a Chrome extension for the long-session degradation problem — want this sub's read on whether it's actually useful

Long-time Claude user, finally built something for the long-session problem and want this sub's read on whether it's actually useful or solving something I made up. The pattern that pushed me to build: 60+ messages into a Claude session, the model starts losing the thread. A constraint I set 40 messages back stops being respected. Re-state it, works for two replies, then forgets again. Eventually you hit compaction, panic, summarize, paste into a new chat, and lose half your context anyway. It's not a window-size problem either. Even at 200K (or 1M on the API), usable performance drops well before the limit. The model technically remembers everything, it just stops weighting it properly. What's already out there, since this sub will rightly ask: - Cross-session memory tools (Mem0, MemoryPlugin) — they remember who you are across chats. Different problem. They don't help when this specific conversation is degrading in front of you. - Context indicators (Context Compass, TokenFlow) — they show how full the window is. Useful, but stop at the warning. You still manually summarize and paste. - Claude's own auto-summary — server-side and opaque. You can't see what got kept or trigger it on your terms. The gap I'm trying to close is the workflow between "I see I'm running out of context" and "I'm continuing in a fresh chat without losing the thread." Built it as a Chrome extension called Curlo: - Ring on the chat bar shows window fill, so compaction doesn't ambush you - One-tap checkpoint fires a structured prompt and saves Claude's reply locally — decisions, progress, open questions, next steps. Paste into a fresh chat to keep going - Each checkpoint is a delta against the last, so they stay tight - Fully client-side, no backend, no accounts, free Next up: optional Notion sync (your workspace, your pages, not locked in my tool) and a Prompt Studio that uses on-device AI to assemble prompts from your saved library. https://curlo-pavilion.lovable.app What I actually want from this post: For Pro and Max users — does Projects' shared context meaningfully delay degradation, or do you still hit the wall mid-conversation? Trying to figure out where my tool helps vs where Anthropic already has you covered. What's your trigger for "time to start fresh"? I default around 70% but it feels arbitrary. Anyone using a system prompt phrasing that genuinely delays drift? Would rather steal a workflow than build around the problem. Roast it. submitted by /u/theRedHood_07 [link] [comments]

Project Shadows: Turns out "just add memory" doesn't fix your agent

Been building a multi-agent system called Shadows for a few months. Nine agents collaborating on strategy work with a shared memory layer. I spent most of my time on retrieval because that's what every benchmark measures. Mem0, MemPalace, Graphiti, all of them. On LongMemEval, recall_all@5 hit 97%. Overall accuracy was 73%. So the right memories are there. The agent still picks the wrong answer. It can't aggregate across sessions, doesn't know when to abstain, and guesses which aspect of a preference the user meant. That lined up with something I've been stuck on. Most LLMs jump straight to execution when you give them a task. People don't. We filter first, check if we're even the right person, then start. Next direction: Agents that can be moved with their identity and memory! submitted by /u/MegaWa7edBas [link] [comments]

I spent 2 months and $600 building a cognitive system on top of Claude because the product I actually need doesn't exist. Here's what I learned.

DISCLAIMER: AI wrote this article. I gave it all of my ideas, thoughts, point-form notes, and context, but I'm not articulate enough to write clearly and comprehensively for 4000+ words. I did write this disclaimer myself. Every major AI lab is competing on the same axis — capability. Bigger models, longer context, better benchmarks. And yet every serious user hits the same wall. Not a capability wall. A structural one. The AI forgets everything between sessions. It tells you what you want to hear instead of what's accurate. It follows your instructions for about three exchanges before drifting back to default behaviour. It can't hold the full architecture of your professional life and reason across it. I have ADHD. I've spent 22 years building compensatory systems for the cognitive dimensions my neurology constrains. When I started using AI seriously — building a company from incorporation to pre-launch in two months while working full-time and managing a newborn — I realized AI is the most powerful compensatory substrate I've ever found. But only if you fight it. So I built a system: a persistent context document I maintain across sessions (currently at version 7), three governance protocols that constrain the AI's behaviour, a 40-rule analysis protocol, a correction log, and systematic quality enforcement. It costs me ~$50/day in AI usage and hours of maintenance overhead. It works better than anything any AI company ships out of the box. In building it, I accidentally specified a product category that nobody sells. I'm calling it Omniscient Partner Intelligence (OPI) — a persistent, full-context cognitive partner calibrated to one person. Not an assistant. Not a chatbot. A second mind. The full article below covers what I built, why every existing product category falls short, who needs this, what it would take to build, and the strongest arguments against the whole idea. OMNISCIENT PARTNER INTELLIGENCE The AI Product Category That Doesn’t Exist Yet I’ve spent the last two months building a workaround for a product nobody sells. This is what I learned, what I built, and what should exist. I. The Wall I pay for the most expensive AI subscription Anthropic offers. I use Claude for everything: writing whitepapers, analysing legal documents, building financial models, producing formatted deliverables, conducting competitive research, and pressure-testing my own strategic thinking. In the last two months I’ve used it to build a company from incorporation to pre-launch while working a full-time job and managing a newborn. The AI throughput is real. I am not dismissing what these systems can do. But every serious user hits the same wall. Not a capability wall. A structural one. The AI forgets everything between sessions. I re-explain my business, my strategic context, and my open threads every time I start a new conversation. It follows my instructions loosely—I set explicit constraints in the first message and watch them dissolve within three exchanges as the model drifts back to its default behaviour. It softens its feedback to avoid upsetting me, which means I have to actively fight to extract honest assessments. I once asked it to analyse a years-long conversation history with someone important in my life. The first analysis was about 60% grounded and 40% cushioning. I had to ask specifically, “how much of this is objective and how much is you trying to be supportive of me?” before I got the real version. A peer-reviewed study published in Science in March 2026 confirmed what I’d already learned from experience: all four major AI systems—ChatGPT, Claude, Gemini, and Llama—systematically tell users what they want to hear. Worse, users rated sycophantic responses as more trustworthy, even when those responses led to worse decisions. The sycophancy is not a bug. It is a structural outcome of training on human approval ratings, where agreeable outputs score higher than honest ones. This creates a specific failure mode for people like me: founders, solo operators, and independent professionals making high-stakes decisions without a team to push back. I have no manager catching flawed strategy. No board member challenging assumptions. What I have is an AI system available around the clock that always seems to understand what I’m trying to do. It does not understand me. It mirrors me. So I built a workaround. And in building it, I accidentally specified a product that nobody sells. II. What I Built Over roughly forty sessions and two months, I constructed a system on top of Claude that compensates for every structural gap I just described. It is held together with duct tape—persistent context documents, governance protocols, correction logs, and manual quality enforcement. It is cognitively expensive to maintain. And it works better than anything any AI company has shipped. The Brain Document I maintain a persistent context file—currently at version 7—that contains the complete architectur

Spent 3 months building an MCP memory server for Claude. No idea if anyone else will want this.

Been using Claude Code heavily for the last year, both at my day job and on side projects. The thing that kept killing me was starting a new session and having to re-explain everything. What I'm working on, what I decided last week, why I chose Postgres over Mongo, the architectural tradeoffs I'd already reasoned through. Every single time. I tried the obvious stuff first. CLAUDE.md files hit a ceiling pretty fast. Obsidian is great for notes but can't answer "why did I decide this?" Mem0 was closer but just didn't retrieve well enough for the questions I actually cared about. So I started building my own on nights and weekends. Called it Genesys. It's an MCP server. You point Claude at it and it stores memories as a causal graph instead of flat vectors. When you ask "why did I choose X?" it traces the chain and shows you. Memories also decay over time based on how often they're accessed and how connected they are to other memories, so stale stuff doesn't pollute retrieval forever. If you want to try it One-line install: bash pip install genesys-memory Or paste this to Claude and let it set everything up for you: Install genesys-memory, create a .env with my OpenAI key, start the server on port 8000 with the in-memory backend, and connect it as an MCP server. Works with Claude Code: bash claude mcp add --transport http genesys http://localhost:8000/mcp Or Claude Desktop by adding it to claude_desktop_config.json. If you want to keep everything local (no OpenAI, no cloud): bash pip install 'genesys-memory[obsidian,local]' Set GENESYS_BACKEND=obsidian, GENESYS_EMBEDDER=local, and point OBSIDIAN_VAULT_PATH at your vault. It uses sentence-transformers for embeddings (downloads a ~80MB model on first run), your markdown files become memory nodes, your wikilinks become causal edges, and a SQLite sidecar in .genesys/ handles indexing without touching your files. No API keys required, nothing leaves your machine. Four storage backends total (in-memory, Postgres + pgvector, Obsidian, FalkorDB). Apache 2.0. GitHub: https://github.com/rishimeka/genesys The benchmark, since people are going to ask I ran it on the full LOCOMO benchmark out of curiosity. 1,540 questions across 10 multi-session conversations, gpt-4o-mini as both the answering and judging model (same setup Mem0's paper used, apples-to-apples). Single-hop: 94.3% Open-domain: 91.7% Temporal: 87.5% Multi-hop: 69.8% Overall: 89.9% For context: Mem0 scored 67.1% on the same benchmark, Zep scored 75.1% (their corrected number), and just dumping the entire conversation into the context window scores ~73%. All three scripts (ingest, eval, judge) and the full 1,540 judged results are in the repo. You can reproduce it on your machine. Two honest notes. First, MemMachine scored 91.7% using gpt-4.1-mini (a stronger answering model than mine), so I'm not claiming top of the leaderboard. Second, an independent audit of LOCOMO found ~99 ambiguous ground truth answers in the dataset itself, so the real ceiling is more like 93-94%, not 100%. Anyone claiming 100% is either overfitting or using a generous judge. What I still go back and forth on The thing I genuinely don't know is whether the causal graph approach is worth the complexity. Multi-hop queries at 69.8% are where it falls apart, and I can tell you why: the retrieval finds the right context, the answering model just doesn't always make the inferential leap. That's a real flaw, not a polished one. Benchmarks and real-world usage are also different animals. It's been working well for me personally. That's n=1. Which is why I'm here. What I'm actually looking for feedback on For those of you using memory with Claude Code or Desktop, what's your current setup? What works, what doesn't? Is the "why did I decide this?" query something other people actually want, or is it just my brain that works this way? If you clone the repo and try it, what's the first thing that breaks or annoys you? Genuinely want to know. I'll be here for the next few hours replying to everything. Roast it, ask questions, tell me I'm overengineering it. submitted by /u/StudentSweet3601 [link] [comments]

I built a local-first memory system for Claude Code — 98%+ on 4 benchmarks, 100% LME with optional reranking

I've been working on context-mem — a persistent memory layer for AI coding assistants. The problem: every new Claude Code session starts from scratch. Architecture decisions, bug fixes, preferences — all gone. My approach: capture everything automatically via hooks, compress it (99% savings with 14 summarizers), and retrieve the right context in future sessions. Benchmarked on 4 academic datasets (3,200+ questions total): Pure local (free, no API): LongMemEval: 97.8% (vs MemPalace 96.6%, vs Mem0 ~85%) LoCoMo: 98.1% (vs MemPalace 60.3%) MemBench: 98.0% ConvoMem: 97.7% With optional Haiku reranker (~$1 per 500 queries): LongMemEval: 100% (500/500) The LoCoMo result was the most interesting — 98% vs 60% on multi-hop reasoning. Simple retrieval is easy. Cross-conversation questions are where it actually matters. One command to try it: npm i context-mem && npx context-mem init Works with Claude Code, Cursor, Windsurf, VS Code, Cline, Roo Code. 44 MCP tools. MIT licensed. 1143 tests. GitHub: https://github.com/JubaKitiashvili/context-mem Would love feedback — especially on whether the retrieval approach makes sense for your workflow. submitted by /u/SubjectGrapefruit281 [link] [comments]