Pete Johnson — MongoDB’s field CTO of AI and a 30-year database veteran — makes the case across ~95 minutes on The Cognitive Revolution that the interesting frontier in AI has moved back into database territory. His thesis, stated once: agent performance, and especially cost-adjusted agent performance, depends on retrieval — what you choose to put in front of the model, in what order.

The thesis

  • Not the model, not the context window, not the prompt — retrieval is what decides whether an agent is good
  • Everything else in the conversation (database history, the Voyage acquisition, vector search) is downstream of that one claim

A history of constraints

  • 1970: SQL is born (E.F. Codd, IBM) — storage was the scarce resource, so normalization (store nothing twice) was the right design
  • 2007: MongoDB’s first commit, the year the iPhone ships — after 47 years of Moore’s Law, time became scarce, so denormalize: one JSON document, one disk read instead of three
  • “The problem has faded, but the solution persists” — Johnson agrees, and flags the education system’s “thou shalt always normalize” bias

MongoDB’s AI path — it started with keyword search

  • 2020: customers stood up their own Lucene servers for keyword search → MongoDB shipped Atlas Search (lexical, managed)
  • A vector is just an array of floats → to a document DB, that’s just another attribute, so vector search was cheap to add
  • Three levers: pre-filter (metadata) + lexical + vector = hybrid search in one query (rank fusion / score fusion, one API call)
  • 2025: the Voyage acquisition — and the conversation pivots from “database features” to “embeddings actually matter”

Embeddings are not commoditized

  • “Most people think embedding models are commoditized — that is not true”
  • Hugging Face’s Rtech benchmark: up to a 14% quality gap vs. the default picks
  • 14% is the difference between a hallucination and a correct answer
  • A reranker on top adds another 5–10% ($re-rank, one-call)
  • Anthropic — no embedding model of its own — recommends Voyage

Three Voyage features that remove plumbing

  • Contextualized chunking: send the chunk plus its surrounding context, get one vector back — better retrieval at smaller chunks, inverting the normal tradeoff
  • Matryoshka reasoning: dimensions nest like Russian dolls — embed at 1024, lop off the last 512 to test, no re-embedding your corpus
  • Shared embedding spaces: four sizes of one model share an embedding space; a free open-weight “nano” can run queries locally to kill token cost in dev

The memory problem, compressed

  • 2022: query → context window → answer. 2023: the knowledge cutoff + proprietary data → RAG. 2025: tools/MCP + looping → the memory problem
  • Early answer: short-term memory = cram the session; long-term = cram the last three days
  • Two failures: token maxing (Uber burned its entire 2026 budget in 13 weeks) and lost-in-the-middle (the first and last ~7K tokens are what matter; the middle muddies the answer)

The fix is selection, not stuffing

  • Stop asking “how do I cram a million tokens in” — ask “how do I choose the right 200K for this loop”
  • Taxonomic memory: a hundred company-specific terms exist, but only five are relevant to this loop — pick those five, re-pick next loop
  • Two responsibilities now: query with a token budget, and write the answer back so the system curates and stores it

Write, change, recall, forget

  • Memories have a half-life — recent matters more — and forgetting is the hardest part
  • Nathan’s own memory system (monthly logs → yearly summaries → entity wiki) hits both pain points: the DRY violation and the model keeping a dead project open for months
  • Guidance: a good embedder + reranker makes the forget step workable; graph structure for the top 2–6 levels, vector search in the leaf; don’t run multiple LLM passes to shrink the corpus — that’s just more tokens
  • Memory done well: ElevenLabs’ micro-agents, one per customer

Build vs. buy, three camps

  • Camp one: “I bought one tool, I’m done.” Camp two: POC purgatory — usually the wrong problem. Camp three: optimizing sophisticated memory
  • Problem selection: top 10–15 problems, which have good data, which already have metrics — else you can’t tell if AI helped
  • “Bad data quality and bad security posture don’t get solved by AI — they get amplified”
  • Lines of code is a terrible metric; idea-to-production is the one that matters

The world outside the US

  • Seven countries, ~100 customers this year — and the two most sophisticated were in Mexico City and São Paulo, both assuming US competitors were ahead
  • Nearly every country has a hyperscaler data center now — the geographic barriers that kept US companies ahead have eroded

“We’ve been building databases for 60 years. We’ve been building agents for about 18 months… there’s no LAMP stack for agents yet — no React and Angular, no established right answer an enterprise can confidently buy.”