YC Root AccessThis Startup Is Trying To Solve The AI Memory Problem
CHAPTERS
- 0:05 – 0:48
Mem0’s core idea: a memory layer for stateless LLM agents
Nicolas introduces Mem0 and the founders frame the core problem: LLMs are stateless, so agents don’t naturally retain user context across sessions. Mem0 aims to provide a reusable memory layer so AI apps can “remember” like humans do.
- •Mem0 positions itself as a dedicated memory layer for AI agents
- •Problem: agents restart from scratch because LLMs don’t persist state
- •Goal: make memory a default building block for any AI app
- 0:48 – 1:17
Open-source traction and ecosystem distribution via agent frameworks
The founders share adoption metrics and explain how open source and framework integrations drive distribution. Mem0 is used directly by companies and indirectly through popular agentic frameworks.
- •14M+ Python package downloads and 41k GitHub stars
- •Used by thousands of companies
- •Integrated with major agent frameworks (e.g., AWS Agents SDK/Strands, CrewAI, Flowise)
- •Recently announced a $24M round
- 1:17 – 1:58
Why memory improves agents: personalization and “gets better over time” behavior
Mem0’s value is framed as sustained personalization: agents can retain preferences and context, improving with repeated use. The founders use a travel-planner preference example to show how memory changes outcomes.
- •Agents can store user preferences (e.g., hotel/location habits)
- •Better user experience through continuity across sessions
- •Memory enables agents to improve over time rather than act statelessly
- 1:58 – 2:27
Reducing cost and latency by avoiding naive “stuff it all in the prompt” context
They explain the cost/latency problem with sending entire histories into the context window. Mem0 instead retrieves only the most relevant information, reducing tokens and speeding responses.
- •Naive memory = dumping all history into the context window
- •More tokens increases both inference cost and latency
- •Mem0 selects the right information to include, optimizing prompts
- 2:27 – 5:02
Founder backgrounds and the YC pivot from EmbedChain to Mem0
The founders describe their long collaboration, prior experience, and how they entered YC with a different product framing. A viral side project exposed the “doesn’t remember me” pain, triggering the pivot and quick launch.
- •Founders met in undergrad; long history of building side projects
- •Deshraj led AI platform work at Tesla Autopilot
- •Applied to YC as EmbedChain, pivoted toward solving statelessness
- •Viral “Sadhguru AI” feedback highlighted the missing memory problem
- •Launched Mem0 rapidly after YC encouragement
- 5:02 – 6:04
Developer integration model: add memory + search memory primitives
Mem0’s product surface is described in terms of simple primitives and APIs. Developers send user-level signals; Mem0 extracts what matters, builds state, and returns the most important context when needed.
- •Two core primitives: write/add memory and read/search memory
- •Ingests developer-provided data (e.g., chat logs)
- •Extracts meaningful info and builds an evolving “state”
- •Returns high-value context for new conversations/tasks
- 6:04 – 6:59
Under the hood: hybrid memory store (key-value, semantic chunks, graph relations)
Deshraj outlines Mem0’s internal architecture for representing memory in multiple forms. Retrieval queries pull from all sources to balance accuracy and real-time performance.
- •Classifies unstructured inputs into multiple memory types
- •Key-value memory for structured facts/preferences
- •Semantic chunk storage for similarity-based retrieval
- •Graph memory for relationships between facts
- •Real-time retrieval designed for low latency and high accuracy
- 6:59 – 7:54
Customization as an “expectation problem”: rules, natural language controls, and onboarding
They emphasize that memory relevance varies by app and user expectations, so customization is essential. Mem0 supports developer-defined capture rules—often in plain language interpreted by an LLM—so teams can control what gets stored.
- •Memory differs by application and even by user for the same task
- •Onboarding aims to understand what the developer is building
- •Developers can specify what should/shouldn’t be remembered
- •Rules can be written in plain language and turned into pipeline logic
- 7:54 – 8:53
Use cases across industries—and a shift toward “agent memory,” not just user memory
They enumerate where memory is valuable: coding agents, companions, education, healthcare, finance, and more. A newer pattern is capturing state about the agent itself (tools used, decisions, prior plans) rather than only human preferences.
- •Context management for coding and workflow agents
- •Personal companions that track preferences and history
- •Education (learning trajectory), healthcare (patient history), finance (trade history)
- •Emerging demand: memory about agents, not only humans
- 8:53 – 9:52
Handling stale memories: hard, exponential, and domain-specific decay policies
Mem0 supports different forgetting/decay mechanisms depending on product needs. Some apps want strict expiration, others want recency bias, and some want permanent retention for specific categories (e.g., travel preferences).
- •Developers request different decay behaviors
- •Hard decay (e.g., delete after 6 months)
- •Exponential decay (recent memories weighted more)
- •Category/domain-based retention rules (keep some facts indefinitely)
- •Configuration via both plain-language intent and additional tuning knobs
- 9:52 – 11:48
Competing with model-native memory: neutrality across LLM providers and portability
They argue model providers adding memory validates the category but creates lock-in risk for developers. Mem0’s differentiation is being decoupled from any single model and usable across multiple LLMs/frameworks as a shared memory source.
- •Big labs shipping memory educates the market
- •Developers commonly use multiple models in one product
- •Memory shouldn’t be tied to a single model provider (avoid lock-in)
- •Memory must support both read and write across systems
- •Framework integrations help centralize memory across tools
- 11:48 – 15:38
Fundraising, team growth, and the roadmap: make it work, neutral, then portable
They discuss the $24M seed+Series A, why investors doubled down, and how they’ll deploy capital primarily into hiring and product execution. They close with a longer-term vision of portable memory across many apps as interfaces become agentic.
- •Round details: seed led by Kindred; Series A led by Basis Set; participation from Peak XV, YC, angels
- •Capital allocated to hiring and building the best memory product
- •Team size ~10 across India and SF; hiring across engineering roles
- •Engineering challenge: low-latency infra plus expectation-sensitive behavior
- •Vision: “make it work, make it neutral, make it portable” as agentic UX becomes mainstream
- 15:38 – 17:22
Founder lessons: focus (DFS vs BFS) and conviction over long timelines
In closing reflections, Deshraj emphasizes deep focus and customer conversation, while acknowledging their own ‘blessing in disguise’ detours. Taranjeet highlights perseverance and self-belief built from many years of attempts.
- •Advice: prioritize focus—go deep rather than chasing many ideas
- •Talk to customers while iterating quickly
- •Acknowledgement: their viral side project unexpectedly unlocked the real problem
- •Perseverance through multiple startup attempts
- •Belief and conviction as a practical founder advantage
