ORBiS TREE · ENGLISH DOCUMENT
Concepts →AI Memory
Stored conversation state, preferences and task records, distinguished from context windows and model training, with examples of freshness and access boundaries.
한국어
English
This English page is a curated translation layer linked to the Korean source article. Community changes are currently made on the Korean source, where the full revision history and anonymous edit trail are preserved.
Overview
AI Memory is a broad name for retaining conversation state, preferences and task records for later use. LangGraph distinguishes short-term state within a thread from longer-term information used across conversations.[1] Supplying a stored statement as input is different from changing model weights through training.
Context, storage and learning
A Context Window bounds the input available in one request. Storage retains information outside that request; retrieval selects what to bring back. RAG can provide external evidence, including records used as memory. CoALA organizes language agents around memory components, action spaces and decision-making.[2]
Server-side memory
Server-side AI memory retains state in a server-managed store. Restoring one task and carrying preferences across tasks have different requirements. Separate users, organizations and projects, and apply access rules at retrieval time. More stored text does not automatically mean more accurate recall.
Worked example: an updated meeting preference
This example is hypothetical. An old record says 18:00; a recent instruction says 19:00 for future meetings. Retrieving both without their dates and scopes can create a conflict. Determine whether the change replaces a general preference or applies to one event, and preserve the supporting instruction.
Updates, deletion and evaluation
Distinguish user statements from inferred summaries. Record scope, freshness and provenance. Explain whether deletion covers source records, summaries and indexes; deleting storage does not automatically revise trained weights. Test cross-user mixing, stale records overriding new instructions and unsupported preferences. Data Provenance and AI Agent Oversight offer related evidence and permission context.
Five stages of using memory
LangGraph's memory guide ↗ distinguishes conversation-scoped state from information retained across conversations.[1] In an application, storing a record and using it in the current answer are separately observable events. The following pipeline is an ORBiS Tree design example, not a required library schema.
- Extract an explicit user statement without promoting an inference into a fact. A preference for evenings does not establish permanent availability at 19:00.
- Store it with organization, user and project scope. Keep another person's records outside the requester's authorized search space.
- Retrieve candidates for this request. Embedding similarity can find candidates; authorization and validity are separate filters.
- Assemble selected records into the input while preserving source and time. A store is not the same as the context window available to one model call.
- Update a record only after deciding whether the new instruction replaces a general preference or describes one exception.
Worked example: a changed preference record
This record is hypothetical. Its scope is user-42/project-A; key is meeting-time; value is 19:00; source is message-108; valid_from is the date of the instruction; supersedes points to memory-17. Retaining the distinction between the old 18:00 record and the new 19:00 record makes the earlier answer inspectable. Include a time zone: a bare time string does not identify which local time was intended.
For one exceptional meeting, associate the change with that meeting's identifier rather than replacing the general profile. This applies data provenance to user state. The CoALA paper ↗ provides research context for reasoning about memory together with action selection.[2]
Deletion and asynchronous update failures
A background summarizer may recreate stale information after the source record is deleted. Have update jobs inspect deletion status and source versions. Document separate deletion behavior for originals, summaries, vector indexes and caches. Backup removal follows its operational policy; do not claim that every copy disappears immediately.
Concurrent writers can also read the same profile and overwrite one another's updates. A version comparison or conflict-handling mechanism makes the lost change visible. Thread checkpoints and long-term preference updates require different checks even when a product calls both features memory.
Test cases and reading path
Test deleted-record reuse, project A decisions leaking into project B, old preferences overriding new instructions and inferred preferences being stored as facts. Record retrieved items, selection reasons, applied versions and the final answer. Continue with RAG for retrieval, agent oversight for permitted actions and hallucination for unsupported claims.
SOURCES
Sources
-
Memory overviewLangChain / LangGraphOpen source ↗
-
Cognitive Architectures for Language AgentsSumers et al. / TMLROpen source ↗
KNOWLEDGE LINKS
Continue from here
BACKLINKS