Background, Factual, Event, Dialogue, Reflection, Skill: A Deep Dive

1. Why Six Types?

In our earlier article on AI memory types, we introduced the concept that not all memories are created equal — that a user's career background, their dietary preferences, last Tuesday's conversation, and their preferred coding style represent fundamentally different kinds of information that deserve fundamentally different treatment. That article outlined the "what." This article provides the "how" and the "why" in exhaustive detail.

The six-type memory architecture is not arbitrary. It is grounded in decades of cognitive science research on human memory systems, adapted for the specific requirements of AI agent memory. The human brain does not store all information in a single undifferentiated mass — it maintains distinct memory systems (episodic, semantic, procedural, working, etc.) that interact but serve different functions and have different characteristics. Our AI memory architecture follows the same principle.

Why does this matter in practice? Consider two systems: System A stores all user information as flat key-value pairs in a vector database. System B maintains six distinct memory stores, each optimized for its specific type of information. When a user asks "What approach did we take on the Jenkins migration last month?", System A performs a vector similarity search across all memories and hopes the relevant ones float to the top. System B routes this query to the event memory store, applies a temporal filter for "last month," and retrieves the specific event with its full context — including who was involved, what decisions were made, and what the outcomes were.

The performance difference is not subtle. On the LoCoMo benchmark's temporal reasoning tests, systems with type-specific memory routing score 25-30 percentage points higher than those with flat memory stores. On multi-hop questions that require connecting facts from different memory types (e.g., "Given my role at the company, what should I prioritize in our next 1-on-1?"), the gap is even larger. The architectural decision to maintain distinct memory types is the single biggest contributor to MemoryLake's 94.03% accuracy on LoCoMo.

In this deep dive, we examine each of the six memory types in detail. For each type, we explain what it stores, provide a real-world analogy, describe the technical implementation, discuss the retrieval characteristics, and identify the use cases where it provides the most value. By the end of this article, you will understand not just what each memory type does, but why it exists and how to leverage it in your own AI applications.

2. Background Memory

Background memory stores the contextual information that provides a persistent backdrop for all interactions with a user. This includes information about the user's role, organization, industry, work environment, team structure, and other relatively stable contextual factors. Background memory answers the question: "Who is this person, and what is the world they operate in?"

Think of background memory as the character sheet in a role-playing game. It describes the fundamental attributes and context that inform every action and decision, but rarely change during the course of play. Your character is a "Senior DevOps Engineer at a Series B fintech startup" — this single piece of background memory changes how every subsequent interaction should be calibrated. The AI should not explain what a CI/CD pipeline is to this user, but it might need to explain specific financial regulations.

Technically, background memory is implemented as a structured document store with rich metadata indexing. Unlike other memory types that are primarily retrieved through vector similarity, background memory is typically loaded proactively at the start of each session. The system reads the user's background context and incorporates it into the system prompt, ensuring that every response is calibrated to the user's situation.

Background memory has the lowest update frequency of all six types. It changes when the user changes jobs, moves to a new city, joins a new project, or experiences a significant life event. The system monitors for these changes by comparing new information against existing background context, but it does not aggressively update — background memory is designed to be stable. When an update does occur, it is versioned, allowing the system to understand how the user's context has evolved over time.

Use cases where background memory is critical: enterprise AI assistants that need to understand organizational context, educational AI that adapts to the learner's level and learning style, medical AI that needs to maintain awareness of a patient's health history and conditions, and any application where the AI needs to "know" the user beyond individual interactions.

3. Factual Memory

Factual memory stores explicit, verifiable statements about the user — their preferences, attributes, beliefs, and relationships. This is the closest analog to what most AI memory systems provide, but MemoryLake's implementation goes significantly beyond simple key-value storage.

The real-world analogy for factual memory is a personal dossier — a structured collection of everything the AI knows to be true about the user. "Prefers dark mode." "Allergic to shellfish." "Birthday is March 15." "Dislikes meetings before 10 AM." "Uses TypeScript exclusively." Each of these is a discrete, verifiable fact that can be confirmed, updated, or contradicted.

Factual memory is stored as structured assertions with confidence scores, timestamps, and provenance tracking. Each fact includes not just the assertion itself but metadata about where it came from (which conversation, which statement), how confident the system is (based on the explicitness and frequency of the user's expression), and when it was last confirmed or updated. This rich metadata enables conflict detection — when a new fact contradicts an existing one, the system can compare confidence scores, recency, and source reliability to determine which fact should prevail.

Retrieval from factual memory uses a combination of vector similarity (for finding semantically related facts) and structured queries (for filtering by category, confidence level, or recency). When the AI needs to know the user's preferences about something, it searches factual memory for both exact matches ("Does the user have a stated preference about X?") and related facts that might inform the answer ("What are the user's preferences in the broader category that X belongs to?").

One of the most important features of factual memory is its conflict detection and resolution capability. Because facts can be contradicted over time (the user becomes a vegetarian, the user switches from Python to Rust), the system needs to handle these transitions gracefully. MemoryLake's factual memory maintains a version chain for each fact, allowing the system to understand not just what is currently true but how the user's preferences have evolved. This is particularly valuable for applications like personal health tracking, where understanding the trajectory of preferences is as important as knowing current values.

Use cases: personalization engines, recommendation systems, customer preference tracking, adaptive user interfaces, and any application that needs to maintain an accurate, up-to-date model of user attributes and preferences.

4. Event Memory

Event memory stores temporally ordered experiences — things that happened at specific times and in specific contexts. It is the AI equivalent of episodic memory in human cognition, and it is one of the most powerful but least common memory types in current AI systems.

Think of event memory as a detailed journal or logbook. Not just "the user discussed budget planning" but "On Tuesday, November 12, the user and I worked through Q4 budget projections for the marketing team. The user was frustrated because the previous projections had been inaccurate. We identified three areas where spending had exceeded forecasts: contractor fees, SaaS tools, and event sponsorships. The user decided to implement a monthly review process."

Event memory is stored in a temporally indexed structure that enables efficient range queries. Each event includes a timestamp, duration, participants, location (if applicable), a narrative summary, key decisions made, action items generated, and emotional context. The temporal index allows the system to answer questions like "What happened last week?", "What did we discuss about budget planning in November?", or "When was the last time the user seemed frustrated?"

The technical implementation uses a hybrid of chronological indexing and semantic embeddings. The chronological index provides O(log n) access by time range, while the semantic embeddings enable content-based retrieval ("Find events related to budget planning"). The combination allows for complex queries that filter on both time and content simultaneously — a capability that is impossible with flat vector stores.

Event memory also captures causal relationships between events. When one event references or follows from another, the system creates a link in the event graph. This enables multi-hop temporal reasoning — answering questions like "What led to the decision to implement monthly reviews?" by traversing the causal chain of events that preceded it.

Event memory is particularly valuable in professional contexts where the AI serves as a persistent collaborator rather than a stateless tool. Project management AI, executive assistants, therapeutic AI, and educational tutors all benefit enormously from maintaining a detailed record of past interactions, not just extracted facts.

5. Dialogue Memory

Dialogue memory stores the conversational history itself — not just the facts extracted from conversations, but the actual flow, tone, and dynamics of past interactions. This is the memory type that gives the AI a sense of its ongoing relationship with the user.

The analogy here is the difference between reading someone's biography and knowing them personally. Factual memory tells the AI that "the user is direct and dislikes small talk." Dialogue memory shows this through dozens of past interactions where the user cut straight to business, expressed impatience with pleasantries, and responded most positively when the AI was concise and specific. The difference is between knowing about someone and knowing them.

Dialogue memory is stored as compressed conversation summaries rather than raw transcripts. Each summary captures the key topics discussed, the user's communication style in that interaction, notable emotional moments, questions that were asked and answered, and unresolved threads. The summaries are linked to both event memories (what happened) and factual memories (what was learned), creating a rich web of cross-references.

Retrieval from dialogue memory uses a combination of recency weighting and thematic similarity. Recent conversations are given higher weight because they are more likely to reflect the current state of the relationship, but older conversations remain accessible when thematically relevant. The system also maintains running statistics about the user's communication patterns — average message length, preferred response format, frequency of specific types of requests — which inform how the AI calibrates its responses.

One subtle but important feature of dialogue memory is its ability to detect relationship dynamics over time. By analyzing the progression of conversations, the system can identify shifts in the user's trust level, engagement, satisfaction, and communication style. This meta-analysis is fed into the reflection memory system (discussed next), where it informs higher-level observations about the relationship.

Use cases: AI companions and coaches, customer service agents that need to maintain relationship continuity, therapeutic applications, and any system where the quality of the interaction itself — not just the information exchanged — matters.

6. Reflection Memory

Reflection memory is perhaps the most innovative of the six types. It stores meta-observations that the AI derives from patterns across multiple interactions — insights that are not explicitly stated by the user but are inferred from their behavior over time.

The analogy is a therapist's clinical notes. A therapist does not just record what the patient says — they observe patterns, note contradictions, identify recurring themes, and develop hypotheses about the patient's underlying motivations and needs. Reflection memory serves the same function for AI systems. When the AI notices that the user always asks about deadlines at the end of conversations, or that they tend to become more terse when discussing a specific project, or that their productivity preferences shift between morning and evening — these are reflections that inform future interactions.

Reflection memory is generated through a periodic process we call "memory consolidation." At regular intervals (or when triggered by significant events), the memory system reviews recent interactions across all memory types and generates new reflections. This process uses the language model itself as a reasoning engine — it reviews the accumulated evidence and produces observations, hypotheses, and predictions about the user's behavior and needs.

Each reflection includes the evidence that supports it (links to specific events, dialogue moments, and factual changes), a confidence score based on the quantity and consistency of the supporting evidence, and an expiration policy that determines when the reflection should be re-evaluated. Reflections are not permanent truths — they are working hypotheses that are continuously tested against new evidence and updated or discarded when they no longer hold.

Reflection memory is particularly powerful because it enables the AI to improve proactively rather than reactively. Instead of waiting for the user to explicitly state a preference, the AI can anticipate needs based on observed patterns. "I notice you usually ask about test coverage right after discussing new features — would you like me to include test coverage analysis in my feature proposals?" This kind of anticipatory behavior is what distinguishes truly intelligent AI assistants from sophisticated search engines.

The reflection memory system also handles a critical function: identifying its own blind spots and errors. When the AI makes a mistake — provides incorrect information, misunderstands the user's intent, or violates an unstated preference — the reflection system generates a "corrective reflection" that prevents the same mistake from recurring. This is the closest analog to learning from experience in current AI systems.

7. Skill Memory

Skill memory stores learned procedures and task-specific knowledge — the how-to knowledge that enables the AI to perform specific tasks in the user's preferred way. If factual memory tells the AI what the user likes, and event memory tells the AI what happened, skill memory tells the AI how to do things.

The analogy is a craftsperson's apprenticeship. When you work with someone long enough, you learn not just their preferences but their methods. You know that when they ask for a "quick report," they mean a one-page executive summary with bullet points, not a detailed analysis. You know that their code review process starts with architecture, then logic, then style. You know that they prefer to discuss bad news at the beginning of a meeting, not the end.

Skill memory is stored as structured procedures with parameterized templates and conditional logic. Each skill includes a trigger pattern (what kind of request activates this skill), a sequence of steps, parameter values that are customized for this user, and quality criteria that the output should meet. For example, a "write weekly status email" skill might include the user's preferred format, their reporting hierarchy, the metrics they always include, and their preferred tone and level of detail.

Skills are learned through a combination of explicit instruction (the user says "When I ask for a code review, always check for security vulnerabilities first") and implicit learning (the system observes that the user consistently modifies a particular aspect of the AI's output and infers a skill adjustment). The learning process is gradual — a new skill requires multiple confirming observations before it is activated, reducing the risk of overreaction to a single interaction.

Skill memory also supports skill composition — combining multiple atomic skills into complex workflows. If the user has a "format code review" skill, a "check security vulnerabilities" skill, and a "generate test suggestions" skill, the system can compose these into a "comprehensive code review" workflow that executes all three skills in sequence, producing a single integrated output.

One of the most interesting properties of skill memory is transfer learning between contexts. A skill learned in one domain can sometimes be applied in another. If the AI learns that the user prefers executive summaries with bullet points for technical reports, it might apply the same formatting preference to other types of reports unless the user indicates otherwise. This kind of cross-context generalization makes the AI more efficient over time, requiring fewer explicit instructions.

Use cases: code assistant AI that learns the user's coding conventions and review processes, writing assistants that learn the user's voice and formatting preferences, workflow automation tools that adapt to the user's preferred processes, and any application where the AI needs to perform recurring tasks in a user-customized way.

8. How They Work Together

The six memory types are not independent silos — they form an interconnected system where each type informs and enriches the others. Understanding these interactions is essential for building effective memory-enabled AI applications.

The most common interaction pattern is the "observation-to-reflection" pipeline. An event memory (something happened in a conversation) generates or updates a factual memory (a new fact was learned) which triggers a reflection (a pattern was observed) which updates a skill (the AI adjusts its behavior). This pipeline runs continuously, meaning the AI is constantly learning and adapting based on new interactions.

Another important interaction is "context enrichment." When the AI retrieves a memory from any type, it enriches the result with related memories from other types. If the user asks about a past event, the response is enriched with the factual context from that time period, the relevant dialogue dynamics, and any reflections that were generated as a result. This cross-type enrichment is what gives MemoryLake's responses their characteristic depth and coherence.

The memory coordination layer manages these interactions through a priority system. When the AI has limited space in its context window (as all current LLMs do), it must choose which memories to include. The coordination layer makes this decision based on the current query type, the relevance scores from each memory store, the recency of each memory, and the predicted utility of each memory for the current interaction. This intelligent prioritization is a key differentiator from systems that simply dump the top-k vector matches into the context.

Conflict resolution across memory types adds another layer of complexity. When memories from different types contradict each other — for example, a factual memory says "the user prefers Python" but a recent skill memory shows the user has been working exclusively in Rust — the system must determine which memory reflects the current truth. The conflict resolution system considers the type-specific characteristics of each memory (factual memories are more explicitly stated, skill memories are more behaviorally grounded) to make these determinations.

Beyond Storage: How Each Type Computes and Enriches

The six memory types are often described in terms of what they store. But each type also has characteristic computational operations and external enrichment patterns that transform it from a passive data container into an active reasoning component.

Factual memory does not merely store "User prefers TypeScript." It performs conflict detection: when a new fact contradicts an existing one, the system computes confidence-weighted resolution using recency, source reliability, and confirmation frequency. It also enriches externally — a factual memory about a user's tech stack can be validated or updated by ingesting their package.json or GitHub language statistics. Event memory does not merely log what happened. It computes temporal chains — ordering events, detecting causal relationships, and inferring what likely happened between two logged events. It enriches from calendar systems, project management tools, and commit histories that provide timestamps and context the conversation never mentioned.

Reflection memory is inherently computational — it exists only because the system reasons over other memory types to synthesize patterns. But it can also enrich from external behavioral data: a user's commit frequency, meeting cadence, or response-time patterns from external tools can feed the reflection engine with signals the user never explicitly described. Skill memory computes by composing atomic procedures into complex workflows and by detecting when a learned skill needs updating because its preconditions have changed. It enriches from documentation, API changelogs, and workflow automation tools that define the external procedures the user operates within.

This framing — each memory type as a storage layer, a computation engine, and an external enrichment target — is what separates a sophisticated multi-type architecture from a simple categorized key-value store. The types are not just organizational bins. They are specialized processors, each with its own reasoning operations and its own interfaces to the external world.

9. Implementation Guide

For engineers who want to implement a multi-type memory system in their own applications, here is our recommended approach based on our experience building and operating MemoryLake.

Start with three types: factual, event, and dialogue. These provide the highest immediate value and are the simplest to implement. Factual memory can begin as a structured JSON store with vector embeddings for semantic search. Event memory requires adding a temporal index but can start with simple timestamp-based ordering. Dialogue memory can begin as compressed conversation summaries linked to the other two types.

Add background memory next. This is primarily a configuration concern — deciding what contextual information to collect and how to incorporate it into the system prompt. The implementation is straightforward (a document store with session-start loading), but the design decisions about what constitutes "background" versus "factual" require thought.

Reflection memory should be added once the other types are stable. It requires a consolidation pipeline that periodically reviews memories across types and generates meta-observations. The quality of reflections depends heavily on the quality of the underlying memories, so it is important to get the foundation right before adding this layer.

Skill memory is typically the last to be implemented because it requires the most sophisticated learning mechanisms. Start with explicit skill declaration (users telling the AI how they want things done) and gradually add implicit skill learning as you accumulate enough interaction data to detect patterns reliably.

Throughout the implementation process, invest in observability. Log every memory operation, track the provenance of every memory, and build tools for visualizing the memory state. When users report issues with AI behavior, the ability to trace the exact memories that influenced a response is invaluable for debugging and improvement.