Persistent Memory Vision
Vision
Uvilo’s AI coaches need to remember what matters about each user across sessions — goals, constraints, preferences, history, and patterns — so that coaching feels like an ongoing relationship rather than a series of disconnected chats. Without persistent memory, every conversation starts from scratch, recommendations are generic, and follow-ups lack continuity.
The Persistent Memory project defines how Uvilo captures, stores, and retrieves durable user information — facts, preferences, and context — that persists beyond a single conversation. It encompasses the extraction of user facts from conversations and quizzes, the storage and semantic retrieval of those facts, the generation of conversation summaries for session continuity, and the tools the coach uses to recall context on demand. The result is a memory system that makes the coach feel more human — remembering the right thing at the right time — without pretending to be perfect.
Background
The Uvilo Method (Section 7) defines Persistent Memory as the user-context layer that sits between what users say (conversations, quizzes, metrics), what Uvilo can do (habits, tasks, programs, recommendations), and how the coach responds (tone, prioritization, follow-through). An extraction prompt (Prompts/Extract_Persistent_Memory_Prompt.md) already exists, defining how factoids and user profile fields are extracted from conversations. This project formalizes the full scope of the persistent memory system as a product specification.
Research Instructions
Research should investigate existing approaches to long-term memory in AI assistant and coaching platforms, vector database implementations for semantic recall, and privacy patterns for storing personal user context. Particular attention should be paid to how memory systems handle staleness, correction, and the tension between comprehensive recall and prompt efficiency.
Requirements
R1: Factoid extraction
The system must extract durable, useful facts about the user from conversations (interviews, quizzes, journal entries) so that coaching context accumulates over time. Extraction must distinguish between genuine user context (goals, preferences, relationships, patterns) and ephemeral application state (onboarding steps, quiz status, habit objects), storing only the former. Each factoid must be atomic (one fact per entry), self-contained (understandable out of context), and labeled with a category and life domain for structured retrieval.
R2: User profile field management
The system must maintain structured user profile fields (e.g., name, date of birth, gender, location, coach preference, verbosity) as the canonical source of truth for standardized user attributes. Profile fields must be updated from conversation extraction when values change, and must be kept distinct from unstructured factoids — the profile is the “form,” factoids are the “notes.”
R3: Factoid storage and semantic retrieval
Extracted factoids must be stored in a way that supports both chronological browsing (list with category and domain filters) and semantic recall (vector similarity search based on meaning, not just keywords). The coach must be able to retrieve relevant context even when the user phrases something differently from how it was originally stored. More recent memories should be considered more truthful than older ones.
R4: Conversation summaries
The system must generate concise, structured summaries of coaching sessions when conversations close. Summaries must capture what was covered, decisions and commitments, open questions, risks, follow-ups, and next steps — without inventing details or including unnecessary PII. Summaries serve short-term continuity (what happened and what’s next), complementing factoids which serve longer-term context (who the user is). Recent summaries must be includable in the context of subsequent conversations.
R5: User context tools
The coach must have on-demand tools to recall user context during conversations — including reading the user profile, listing and semantically searching factoids, listing life domain quiz results, and reading specific habits and tasks. Context must be retrieved selectively (not dumped wholesale into the prompt) to keep conversations lightweight, accurate, and cost-effective. The coach must treat recalled memory as fallible and confirm sensitive context with the user when it matters.
R6: Privacy and data governance
User memory must be handled with appropriate privacy controls. The system must avoid storing unnecessary PII in factoids, allow users to correct or update stored information over time, and ensure that memory is used to improve coaching outcomes — not for surveillance or unrelated purposes. Factoid extraction must explicitly exclude ephemeral application state to prevent noise and protect user trust.
R7: Memory quality and lifecycle
The system must maintain memory quality over time. Factoids must be evaluated for usefulness before storage (would a coach benefit from knowing this in 6 months?), and the system must support correction, staleness handling, and eventual retirement of outdated information. Memory should degrade gracefully — incomplete or stale context is preferable to fabricated context.
Success Criteria
| # | Criterion | Measured by |
|---|---|---|
| V1 | Factoids extracted from conversations are durable, atomic, and exclude ephemeral app state | Review of extracted factoids against the extraction prompt’s quality rules; no app-state factoids in storage |
| V2 | User profile fields are updated from conversations when values change and remain distinct from factoids | Profile fields reflect latest known values; no duplication between profile and factoids |
| V3 | Factoids support both chronological listing (with category/domain filters) and semantic vector search | listFactoids and vectorSearchFactoids tools return relevant results; semantic search finds context even with different phrasing |
| V4 | Conversation summaries are generated on close, are concise and structured, and avoid fabricated details or unnecessary PII | Summary review against accuracy rules; summaries include decisions, next steps, and open questions |
| V5 | Coach has on-demand context tools that retrieve selectively and treat recall as fallible | Tool inventory includes profile, factoid, quiz, habit, and task retrieval; prompt instructions guide selective use |
| V6 | User memory excludes unnecessary PII and supports correction over time | Factoid extraction rules enforce minimal PII; mechanism exists to update or correct stored facts |
| V7 | Memory quality is maintained — factoids are useful, correctable, and degrade gracefully | Factoid value test applied at extraction; correction mechanism available; stale facts handled without fabrication |
Out Of Scope
- Implementation of the database schema, vector index, or API endpoints (technical implementation is defined during Spec and Plan phases)
- The coaching logic that consumes memory (the coach’s system prompt and behavior are separate concerns)
- The journaling feature itself (journaling is a separate feature; this project only covers how journal entries are mined for memory)
- The quiz and domain evaluation system (quizzes are a separate feature; this project only covers how quiz answers are mined for memory)
- The notifications and reminders system
- User-facing UI for browsing or managing memories (may be a separate project)
- Cross-user memory or collective intelligence (this project is scoped to per-user memory only)
Charter Considerations
- Privacy — This project directly handles user data, personal information, and sensitive life context. Privacy is a first-class requirement (R6). Factoid extraction rules explicitly minimize PII, and users must be able to correct stored information.
- Security — Persistent memory contains sensitive personal context (worries, relationships, health patterns). Access must be scoped to the user’s own data and the coaching system. This is addressed through the data governance requirement.
- Performance tracking — Factoid extraction and embedding generation involve LLM and embedding API calls with associated token costs. The system should track these costs as part of normal convo telemetry, but cost optimization is not a primary requirement of this vision.