Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.openmemind.com/llms.txt

Use this file to discover all available pages before exploring further.

Memory Items are Memind’s structured memory units. They are extracted from Raw Data and represent what should be remembered: durable facts, preferences, events, directives, tool experience, playbooks, resolutions, and optional foresight. Raw Data preserves the source context. Memory Items turn that context into reusable memory.
Memory Item Flow

Overview

A Memory Item is not a raw message, a text chunk, or a source document. It is a structured memory unit extracted from source context. Each item is concise enough to retrieve and reuse, but still linked back to the Raw Data that produced it. Memory Items help Memind answer:
What should be remembered from this source context?
This is the bridge between source evidence and usable memory.
Raw Data
  -> Memory Items
  -> Item Graph
  -> Memory Threads
  -> Insight Tree
  -> Retrieval

Why Memory Items exist

Raw Data is useful because it preserves context, but it is still close to the original source. Agents usually need a more compact and durable form of memory. They need to know the user’s stable preferences, current projects, past decisions, tool experience, reusable workflows, and resolved problems without reading the full source context every time. Memory Items provide that layer. They let Memind:
  • extract durable memory from broader source context
  • separate user memory from agent operating memory
  • classify memory into meaningful categories
  • preserve temporal meaning when memory is time-bound
  • extract optional foresight for likely future needs
  • deduplicate repeated facts
  • index structured memory for retrieval
  • connect items through the Item Graph
  • group items into Memory Threads
  • consolidate items into Insights
In short:
Raw Data preserves the background.
Memory Items capture what should be remembered.

Extraction flow

Memory Item extraction starts from Raw Data. At a high level, the flow is:
Raw Data Input
  -> Item Extraction Request
  -> Source Context Preparation
  -> Durable Memory Extraction
  -> Scope Assignment
  -> Category Assignment
  -> Temporal Normalization
  -> Source Linking
  -> Deduplication
  -> Indexing
  -> Persistence
  -> Downstream Memory Layers
Each step has a specific role.
StepPurpose
Raw Data InputStart from source segments, semantic captions, metadata, references, and timestamps.
Item Extraction RequestPrepare namespace, content type, language, allowed categories, metadata, and extraction options.
Source Context PreparationUse segment content, Raw Data captions, metadata, and topic context to avoid extracting from isolated snippets.
Durable Memory ExtractionExtract concise memory candidates that should be useful beyond the immediate message.
Scope AssignmentSeparate USER memory from AGENT memory.
Category AssignmentAssign structured memory categories such as PROFILE, EVENT, DIRECTIVE, or PLAYBOOK.
Temporal NormalizationPreserve when the memory happened, what interval it covers, or when it was observed.
Source LinkingLink each item back to the Raw Data that produced it.
DeduplicationAvoid endlessly appending repeated memory.
IndexingMake items searchable through vector and optional text indexes.
PersistenceStore durable structured memory items.
Downstream Memory LayersFeed the Item Graph, Memory Threads, Insight Tree, and Retrieval.
The important point is that Memory Items are extracted from source context, not isolated text snippets. Raw Data captions help provide the broader background behind extraction, so the model can understand the situation that produced the item.

Memory Item records

A Memory Item stores structured information about one durable memory unit. Conceptually, it contains:
FieldMeaning
idUnique item identifier.
memoryIdThe memory namespace this item belongs to.
contentThe durable memory text.
scopeWhether the item belongs to USER or AGENT memory.
categoryThe structured memory category.
contentTypeThe source content type, such as conversation content.
sourceClientThe client or integration that produced the source.
vectorIdThe vector index ID for item retrieval.
rawDataIdThe Raw Data record that produced this item.
contentHashA fingerprint used for deduplication.
occurredAtThe semantic occurrence time, when available.
occurredStartThe normalized lower bound for a time interval.
occurredEndThe normalized upper bound for a time interval.
timeGranularityThe precision of the normalized time.
observedAtWhen the source segment was observed.
metadataExtra structured metadata.
createdAtWhen the item was created.
typeThe item type, such as FACT or FORESIGHT.
You usually do not need to manipulate these fields directly. They describe how Memind stores memory so it can be searched, traced, connected, and consolidated.

Scopes

Memind separates memory into two scopes: USER and AGENT.
ScopeMeaning
USERMemory about the user: who they are, what they prefer, what they do, and what is happening in their world.
AGENTMemory for the agent: how it should behave, how tools worked, reusable workflows, and resolved problems.
This distinction matters because agent memory is not only user profiling. A useful agent should remember the user, but it should also remember its own operating experience: durable instructions, tool behavior, reusable task patterns, and past resolutions.

Categories

Each Memory Item belongs to a category. Categories give memory structure. They help Memind filter, group, retrieve, connect, and consolidate items.

USER categories

CategoryMeaning
PROFILEStable facts about who the user is, such as role, skills, identity, or enduring preferences.
BEHAVIORRecurring habits, routines, and repeated patterns.
EVENTTime-bound situations, actions, decisions, plans, current projects, or past occurrences.
Examples:
ItemCategory
The user is a Java developer.PROFILE
The user usually prefers stable tooling.BEHAVIOR
The user is migrating a service to Java 21.EVENT

AGENT categories

CategoryMeaning
TOOLUsage experience and optimization for a specific tool.
DIRECTIVEDurable instructions, boundaries, and collaboration rules for the agent.
PLAYBOOKReusable workflows and task-handling patterns.
RESOLUTIONResolved problem knowledge with usable fixes or conclusions.
Examples:
ItemCategory
Use a specific tool option when analyzing a certain repository.TOOL
Show a plan before making substantial edits.DIRECTIVE
For documentation design, first confirm the page structure, then write the MDX.PLAYBOOK
A previous issue was fixed by changing the retrieval graph assist configuration.RESOLUTION
A content processor can restrict which categories are allowed for a given input type. This keeps extraction focused on memory that is meaningful for that source.

Item types

Memory Items can have different item types.
TypeMeaning
FACTA factual memory extracted from source context.
FORESIGHTAn optional forward-looking memory inferred from conversation signals.
Most items are FACT items. They describe something that is true, happened, is happening, or should be reused. FORESIGHT items are different. They capture useful future-facing signals that may help the agent prepare for what the user is likely to need next.

Foresight items

Foresight lets Memind store forward-looking memory. A FORESIGHT item is not a confirmed fact in the same way a FACT item is. It is a predictive or anticipatory memory derived from conversation signals. For example, if a user repeatedly discusses migrating a Java service, stabilizing tooling, and preparing documentation, Memind may infer foresight such as:
The user may soon need help validating the migration plan and documenting the service upgrade.
Foresight is useful when an agent should not only remember what already happened, but also prepare for likely next steps. Typical foresight signals include:
  • upcoming user needs
  • likely follow-up tasks
  • possible project risks
  • expected tool usage
  • preparation hints for future sessions
  • inferred next-step context
Foresight should be used carefully. It is meant to help the agent anticipate, not to overwrite facts or make unsupported assumptions. A good foresight item should be:
QualityMeaning
GroundedIt should be based on observed conversation signals.
UsefulIt should help the agent prepare or retrieve better context later.
Non-authoritativeIt should not be treated as a confirmed user fact.
RevisableIt should be allowed to become stale or be replaced as new context arrives.
In practice:
FACT: The user is migrating a service to Java 21.
FORESIGHT: The user may need help validating migration risks and preparing rollout documentation.
FORESIGHT extraction is optional and depends on runtime configuration.

Temporal information

Not every memory has the same relationship to time. Some memory is stable:
The user is a Java developer.
Some memory is time-bound:
The user is migrating a service this month.
Some memory describes a past decision:
The team decided last week to keep SQLite for local development.
Memory Items can preserve temporal fields such as:
FieldMeaning
occurredAtA point-in-time semantic occurrence.
occurredStartThe start of a normalized time interval.
occurredEndThe end of a normalized time interval.
timeGranularityWhether the time is day-level, month-level, or another precision.
observedAtWhen the source content was observed.
Temporal information helps Memind distinguish stable user profile, current project state, past events, and future plans. It also gives retrieval a way to reason about time-sensitive memory.

Source references

A Memory Item should not be disconnected from its origin. Each item can keep a rawDataId that links it back to the Raw Data record that produced it. This matters because Raw Data carries the broader source context behind the item:
Raw Data segment
  -> Raw Data caption
  -> Memory Item
The item gives a concise memory. The Raw Data caption gives the context behind it. This lets developers inspect:
  • where the item came from
  • what source segment produced it
  • what topic context surrounded it
  • whether extraction was accurate
  • whether the item should be kept, corrected, or ignored
Source references make Memory Items explainable.

Deduplication

Memory systems can easily grow noisy if they keep appending the same fact. Memind uses content fingerprints to help detect repeated items. Deduplication helps avoid cases like:
The user uses Java 21.
The user uses Java 21.
The user uses Java 21 for this project.
Instead of endlessly growing repeated memory, Memind can skip or merge duplicated information depending on the extraction and storage behavior. This keeps the item layer cleaner and makes retrieval less noisy.

Indexing

Memory Items are searchable. After extraction, item content can be embedded and stored in a vector index. The item keeps a vectorId so it can participate in semantic retrieval. This is separate from Raw Data and Insight indexing.
Indexed layerWhat is embedded
Raw DataSegment captions.
Memory ItemsStructured memory item content.
InsightsConsolidated insight content.
This separation lets Memind retrieve at different levels:
  • source evidence from Raw Data
  • durable structured memory from Memory Items
  • higher-level patterns from Insights

Relationship to other layers

Memory Items are the foundation for several later layers.
LayerRelationship
Raw DataItems are extracted from Raw Data and keep source references.
Item GraphItems become connected through entities, aliases, mentions, semantic links, temporal links, and co-occurrence.
Memory ThreadsRelated items are grouped into long-running topic projections.
Insight TreeItems are consolidated into higher-level LEAF, BRANCH, and ROOT insights.
RetrievalItems are direct retrieval candidates and can be returned with evidence and traces.
This is why item quality matters. If items are too noisy, too vague, or disconnected from source context, the graph, threads, insights, and retrieval results become weaker.

Inspecting Memory Items

Memind UI lets developers inspect Memory Items. This is useful when you want to understand:
  • what memory was extracted
  • which scope and category were assigned
  • whether temporal fields were normalized correctly
  • which Raw Data record produced the item
  • whether the item has a vector index reference
  • what metadata was attached
  • whether repeated memory is being deduplicated
  • how items connect to downstream graph, thread, and insight layers
Inspecting Memory Items is one of the fastest ways to debug memory quality.

Common use cases

Memory Items support several common agent memory workflows.
Use caseWhy Memory Items help
PersonalizationStore stable user facts and durable preferences.
Project continuityRemember current projects, decisions, plans, and constraints.
Temporal recallPreserve past events, current situations, and future intentions.
Agent instructionsKeep durable directives about how the agent should behave.
Tool learningRemember tool usage experience and configuration knowledge.
Reusable workflowsStore playbooks for repeated task patterns.
Problem solvingPreserve resolved problems and reusable fixes.
Forward-looking assistanceStore foresight signals that help the agent prepare for likely next steps.
Graph and insight buildingProvide structured nodes for relationships, threads, and higher-level insights.

Design principle

Memory Items turn source context into reusable memory. They should be concise enough to retrieve, structured enough to connect, and traceable enough to inspect. Raw Data preserves the background. Memory Items capture what should be remembered. Together, they let Memind avoid the two common extremes of memory systems: raw transcript storage with no structure, or isolated extracted facts with no context.