Assistant Memory Explained: Why Claude Projects, ChatGPT Memory, and Gemini Still Forget What Matters
Claude Projects, ChatGPT memory, and Gemini context are per-user conveniences, not organizational memory. What they actually store, where they fail, and what solves it.
TL;DR
Every major AI assistant now has some version of memory. Claude has Projects. ChatGPT has its memory feature. Gemini has context you can pin to a workspace. They all promise the same thing: stop repeating yourself, let the assistant carry context forward. In practice, they solve a narrower problem than people think, and it's worth being precise about what that problem is. The short version: Claude Projects, ChatGPT memory, and Gemini's workspace context are per-user conveniences that store snippets and re-derive answers from scratch on every query. None of them reconcile conflicting information over time, which is the actual job of organizational memory, and the job Sentra was built for.
What Claude Projects Actually Does
Claude Projects lets you group files, instructions, and chat threads under one roof so a model has a fixed set of reference material for a task. It's genuinely useful for a contained piece of work: a codebase, a research brief, a client engagement. You upload the documents once, set the instructions, and every conversation inside that project starts from the same baseline.
But a Project is a container, not a brain. It holds what you put in it. It doesn't reconcile a decision made in week one with a contradicting decision made in week six. It doesn't know that the pricing model you discussed on Monday got overruled in a meeting on Thursday. It stores documents and threads. It does not resolve what those documents and threads actually mean when they conflict, which they always eventually do.
ChatGPT and Gemini Have the Same Ceiling
ChatGPT's memory quietly saves facts about you and your preferences across chats. Gemini's workspace context does something similar inside Google's ecosystem. Both are helpful for personalization: tone, recurring instructions, basic facts you don't want to retype.
None of them are built to hold the state of a company. They weren't designed to track who decided what, when a decision changed, or which version of a policy is the one currently in force. They store snippets. When you ask a question, the assistant goes and finds snippets that look relevant, then guesses how they fit together. That guessing step is where things go wrong, and it happens every single time you ask a question, because these systems don't resolve anything permanently. They re-derive an answer from scratch on every query.
The Real Problem: Re-Reading Instead of Knowing
This is the core issue with retrieval-augmented generation, the technique under most of these memory features. RAG grabs chunks of text at query time and asks the model to figure out, on the spot, what's true, what's current, and what's outdated. It's a search problem dressed up as a memory problem.
The cost of that approach shows up in two places. First, accuracy: the model is reasoning over raw fragments with no established relationships between them, so it can easily surface a stale answer as if it were current. Second, cost: every query burns tokens re-reading and re-guessing material that was already available five minutes ago. You pay that tax again and again, on every question, forever.
Why Sentra Works Differently
Sentra isn't a memory layer bolted onto a model, and it isn't a tool you call when an assistant gets stuck. It's context infrastructure, the company brain that sits underneath Claude, ChatGPT, Gemini, or whatever model you're running, so those assistants aren't left guessing at query time.
The distinction is where the work happens. Sentra resolves meaning once, at write time. When information enters the system, whether it's a decision, a document update, or a correction to something said earlier, Sentra places it into a bi-temporal context graph. That graph tracks two timelines at once: when something became true in the world, and when the system learned about it. So it knows that a policy was valid from March to September, that it was superseded in October, and that the correction itself was logged in November. Nothing has to be re-inferred later. The relationships, the supersessions, the current state of truth: all of it is already settled before anyone asks a question.
That's the opposite of RAG's approach. RAG defers the hard work to query time and repeats it endlessly. Sentra does the hard work once and reuses the result. The effect compounds. On Terminal-Bench 2.1, this approach showed roughly 70% lower model cost alongside higher accuracy compared to re-reading and re-guessing at query time. That gap exists because resolved context is cheap to serve and hard to get wrong, while raw retrieval is expensive to serve and easy to get wrong.
Where This Leaves Assistant Memory
Claude Projects, ChatGPT memory, and Gemini's context features are fine for what they are: lightweight, per-user conveniences. They are not equipped to be the source of truth for a business, because none of them were built to resolve conflicting information once and hold it that way over time.
That's the job Sentra does. Not a memory feature attached to one assistant, but the context infrastructure underneath all of them, the company brain that already knows what's true, so every model connected to it stops re-reading and starts actually knowing.