MemoryOS boundary

Type: agentic-system-analyses/types/agentic-system-boundary.md

Boundary and evidence

This run analyses MemoryOS as a memory/knowledge/context-engineering system, not as a general agent runtime. Its intended use is persistent, personalized dialogue: accept user–assistant exchanges, maintain short-, mid- and long-term memory, retrieve retained context, and supply or generate subsequent responses. The boundary is whole-system across the material shipped library variants, server, application, prompts and evaluation driver. These callers are part of the target rather than excluded applications (SRC-1: memoryos-pypi/memoryos.py, memoryos-mcp/server_new.py, memoryos-playground/memdemo/app.py, eval/main_loco_parse.py).

The frozen evidence is the repository at 587ed7755c7aed179965792830ff1b5ad9a6fa92, applicable through 2026-10-16. The acquired checkout's HEAD was checked against that pin; its working tree was clean. The evidence tier is code-grounded. No target code, tests, examples or providers were executed. Repository documentation supplies declared design and attributed performance claims, not observed operation or a causal experiment.

Functional scope and entry-point trace

The Python-facing path includes initialization of user- and assistant-specific storage, JSON reload, admission of dialogue pairs, migration to mid-term sessions, model-assisted summaries and continuity metadata, heat-triggered profile/knowledge updates, retrieval and response generation. The response path itself writes the generated exchange back to memory. Maintenance entry points, including forced analysis, are included (SRC-1: memoryos-pypi/memoryos.py, memoryos-pypi/short_term.py, memoryos-pypi/mid_term.py, memoryos-pypi/long_term.py, memoryos-pypi/updater.py, memoryos-pypi/retriever.py). The following implementation passage establishes that the consumption path closes back into admission:

10. Add this interaction to memory

self.add_memory(user_input=query, agent_response=response_content, timestamp=get_timestamp()) --- memoryos-pypi/memoryos.py

Model instructions are part of this mechanism, not incidental documentation. Generation prompts consume recent history, historical memory and user traits; summarization, preference analysis, knowledge extraction and continuity prompts govern derived state. The utilities call these prompts through the model client (SRC-1: memoryos-pypi/prompts.py, memoryos-pypi/utils.py). For example:

PERSONALITY_ANALYSIS_SYSTEM_PROMPT = """You are a professional user preference analysis assistant. Your task is to analyze the user's personality preferences from the given dialogue based on the provided dimensions. --- memoryos-pypi/prompts.py

The ChromaDB variant is included separately rather than presumed identical to the JSON variants. Its Memoryos constructs a shared storage provider, uses persistent vector collections and reloadable JSON metadata, and registers an exit-time metadata save. Its generation path also retrieves retained content and calls add_memory (SRC-1: memoryos-chromadb/memoryos.py, memoryos-chromadb/storage_provider.py).

The MCP server initializes its bundled memory implementation from configuration and exposes add_memory, retrieve_memory and get_user_profile over stdio. Retrieval returns memory and profile data; final client-side answer generation remains the responsibility of the external MCP host. The repository's own server and bundled implementation remain included (SRC-1: memoryos-mcp/server_new.py, memoryos-mcp/memoryos/memoryos.py).

The shipped Flask Playground is also included. Its /chat route calls get_response; its import route admits supplied exchanges; its analysis route calls forced analysis; its clear route deletes retained user and assistant directories and reconstructs the memory object. The browser template calls these routes. Import paths, the fixed embedding-cache location and launcher assumptions require later compatibility analysis; source inclusion is not evidence that this application launches successfully as checked out (SRC-1: memoryos-playground/memdemo/app.py, memoryos-playground/memdemo/templates/index.html, memoryos-playground/memdemo/start_demo.sh).

The evaluation workflow is a material state producer and consumer, not merely an external benchmark. It uses its own memory modules, imports conversation histories from LoCoMo, stores and updates memory, retrieves it to answer benchmark questions, and writes all_loco_results.json. A separate scorer reads those results and computes category-level token-set F1. These are implementation paths, not supplied run results (SRC-1: eval/main_loco_parse.py, eval/evalution_loco.py). Its own imports establish the separate implementation:

from short_term_memory import ShortTermMemory from mid_term_memory import MidTermMemory from long_term_memory import LongTermMemory from dynamic_update import DynamicUpdate from retrieval_and_answer import RetrievalAndAnswer --- eval/main_loco_parse.py

Top-level tracked coverage

Every top-level tracked file or directory is classified below. “Included” fixes functional scope; it does not claim every line has already been examined. Initial inspection followed the shipped entry points and their storage, maintenance and consumption responsibilities. Available but not yet deeply inspected helpers and documentation remain distinguishable from unavailable evidence and deliberate exclusions. All rows refer to SRC-1.

Dependencies, exclusions and evidence limits

External model endpoints and embedding weights, dependency implementations such as OpenAI's client, sentence-transformers, FlagEmbedding, FAISS, ChromaDB, Flask and FastMCP, and the enclosing MCP applications are outside the frozen repository. Their call sites and supplied configuration are included, not their internals (SRC-1: memoryos-pypi/requirements.txt, memoryos-pypi/utils.py, memoryos-chromadb/storage_provider.py, memoryos-mcp/server_new.py, memoryos-playground/memdemo/app.py). This prevents claims about provider reliability, dependency correctness, host-side memory use or end-to-end deployment success. The Playground's machine-specific embedding-cache path is visible in source; the referenced local cache is not supplied, so successful local model loading is not established.

Live websites, remote images, videos, other repositories, the registry package and published container image are not frozen evidence. Their behavior and equivalence to this checkout cannot be concluded. No execution trace or experimental comparison was supplied: this prevents verified latency, benchmark improvement, crash recovery and causal effectiveness claims. These limits do not remove any shipped memory-loop responsibility from the functional boundary.

Source register