Weekly Video Notes — a short article distilling one talk from the weekly digest. Source video and key frames embedded throughout.

Memory was the theme running through the whole conference, and this 19-minute talk is the most empirically grounded take on it. Shlok Khemani, working independently, did something nobody else bothered to do: he sat down and reverse-engineered the memory systems of the major consumer AI products — ChatGPT, Claude, Gemini, Poke — by probing them, extracting raw profiles, and reading the tool calls. The result is a comparative anatomy of how four teams solved the same problem in four different ways, and what that convergence (and divergence) tells you if you’re building memory into your own product.

The headline finding is deflationary in the best way: none of these systems is a RAG pipeline. The industry’s default mental model — chunk the conversations, embed them, stuff them in a vector database, retrieve top-k — is not what any of the frontier consumer products actually shipped.

Talk agenda: a history of memory, then lessons

Part one: three years of memory, in three acts

ChatGPT memory v1 — the visible fact list

The first serious memory system in a consumer AI product was, by today’s standards, almost quaint. GPT-4 would extract what it thought was a salient fact from a conversation and write it into a list. As a user you could see every single memory, edit it, and delete it.

ChatGPT memory v1 — an explicit, user-visible list of extracted facts

Khemani’s read is that v1’s transparency was also its failure mode. Because every memory was an explicit atomic assertion, memory management fell entirely to the user — and facts don’t stay true. A preference you stated once gets added to your context window forever, long after it stopped describing you.

ChatGPT memory v2 — the running profile

V2 replaced the fact list with a running profile: a dense, continuously-rewritten document the model maintains about you. Khemani extracted his own and found it packed with keyword-dense clues rather than prose — the system tries to cram as much signal as it can into a fixed budget, trusting frontier models to resolve terse hints into relevant context.

The v2 running profile — dense, keyword-heavy, roughly 4,000 tokens

Two details matter for anyone copying this design. The profile runs to roughly 4,000 tokens and is only one of 16 different context blocks the system assembles. And critically, the raw profile is not visible to you — the burden of memory management moved from the user to the system, but so did the transparency. Khemani had to attempt extraction several times across different thinking modes to see his own.

The staleness problem didn’t disappear either. His profile confidently recorded a 2025 trip planning session involving Thailand and Turkey — but with dates and a resolution the model never updated after he actually made the trip.

Claude — the opposite bet

Claude started from the other end entirely. In v1 there was no user profile and no fact list at all. Instead the model got tools: search over past conversations, and a second tool to scope those searches by time period. Every conversation started genuinely fresh, with retrieval on demand.

Claude’s memory: tool-based search over past conversations rather than a maintained profile

Anthropic published a blog post at the time explicitly framing this as the opposite of ChatGPT’s architecture. Then Claude v2 added a running profile after all — but a deliberately different one: around 1,000 tokens rather than 4,000, written in prose rather than dense keywords, user-visible, and explicitly editable. You can request an edit, see previous edits, and delete things that no longer hold.

The convergence

Plot the four products over three years and the shape is unmistakable: everyone ended up with a maintained profile plus tools to search conversation history. ChatGPT added retrieval tools and a summarized profile view; Claude added a profile. They arrived from opposite directions.

Three years of independent evolution converging on profile + search

But — and this is Khemani’s actual point — they converged on the shape, not the implementation. Profile sizes differ 4x. Update cadences differ. Visibility policies differ. Gemini differs again, and coding agents like Claude Code, OpenClaw and Hermes differ more still. There is no one way to do memory.

The practical implication: memory is not a component you bolt on, it’s a system you build alongside your product and evolve with it. Every top consumer AI product today has a memory system that is idiosyncratic to what that product does.

Lesson two: memory is a function of compute

This is the framing most likely to change how you design. Khemani decomposes memory cost into two distinct budgets:

  • Update cost — how frequently you rewrite the profile, and how much context you feed the rewrite
  • Serving cost — the longer the profile, the more tokens every single conversation pays, forever

Memory as a compute trade-off: update cost versus serving cost

In an unconstrained world you’d update after every message and never cap profile length. In the real world these trade off directly against each other, and the design space is exactly the set of positions on that curve. You can buy a lower serving cost by accepting a higher update cost, or vice versa. Ask how much compute am I willing to spend per user per turn and most of the architecture falls out of the answer.

Lesson three: continual learning is already here

Khemani’s most interesting reframe: we talk about continual learning as a future research milestone, but consumer AI products are already doing it — outside the weights. Every conversation brings new information that changes what the system does in subsequent conversations. That’s continual learning; it just happens in context rather than in gradients, because updating weights is expensive and updating a text profile is not.

Continual learning is already shipping — it just happens outside the weights

The open question he poses back to the room: what data do we actually need to kick continual learning into its next gear?

The rant: fragmentation

The talk closes on a genuine frustration. Khemani’s decision to go to Thailand left traces in his ChatGPT conversations, his email, his messages, his calendar. But ChatGPT doesn’t read his email, so it never learned the outcome of a plan it helped make.

Memory is fragmented across products that don’t share context

Every product is building a memory silo over the same person, and none of them draw on the existing context sources that already describe your life. Memory today is capped not by model capability but by how much context any single product is allowed to gather. “None of this feels like 2026,” he says — while allowing the obvious defence: memory for AI is a three-year-old field.

Key takeaways

  1. No frontier consumer memory system is a RAG pipeline. The chunk-embed-retrieve default is not what ChatGPT, Claude, or Gemini shipped. Stop assuming it’s the answer.
  2. Two archetypes exist: the maintained running profile (ChatGPT) and tool-based search over history (Claude v1). Both work. They converged on doing both.
  3. Profile design is a real design space: 4,000 dense keyword tokens vs. 1,000 prose tokens; hidden vs. user-editable. These are product decisions, not technical ones.
  4. Visibility is a trade-off, not a virtue. v1’s fully-visible fact list pushed memory management onto users; hidden profiles remove that burden but also remove correction.
  5. Staleness is the unsolved problem. Every system Khemani probed had confidently wrong facts frozen from an earlier moment.
  6. Model memory as a compute budget split into update cost and serving cost — the architecture largely follows from where you sit on that curve.
  7. Continual learning is already shipping, outside the weights, in the form of profile rewrites between conversations.
  8. Fragmentation is the current ceiling. Memory quality is limited by context access, not model capability — and no product has access to the whole picture.

Source