REM boundary
Type: agentic-system-analyses/types/agentic-system-boundary.md
Boundary and evidence
This run examines REM as a memory service for agents: how interaction descriptions become retained episodes, how model-dependent maintenance proposes semantic memories, and how later queries obtain context for another task. The target class is memory/knowledge/context-engineering system, not an enclosing agent runtime. The boundary is whole-system: the repository's API, worker, persistence interfaces, shipped clients and integrations, seed driver, evaluation drivers, setup instructions and presentation surfaces are included. Whole-system describes source coverage, not a claim that the declared operational loop works end to end.
The frozen evidence is SRC-1, https://github.com/satyammistari/REM at 935e8be0a1fca5b23dbabfe16c48b562c1cd24cc, with applicability cutoff 2026-10-14. The acquired checkout's HEAD matches that revision and its working tree was clean at inspection. The overall tier is code-grounded. No target code, tests, examples, model calls or services were executed. No observed-run or causal-experiment evidence is established by this boundary.
Classification and loop coverage
The source's declared loop is explicit (SRC-1, README.md):
REM runs a simple but powerful loop: Write → Consolidate → Retrieve. ---
README.md
The implementation places REM inside that loop rather than making it a passive document store. The Go service parses and embeds incoming content through the Python worker, persists episodes through database clients, and publishes a consolidation job; retrieval reloads retained episodes, searches semantic vectors, expands temporal neighbors and formats context (SRC-1, go-api/internal/services/write_service.go, go-api/internal/services/retrieve_service.go). The worker's reachable consolidation engine issues a model request (SRC-1, python-worker/main.py, python-worker/workers/tasks.py, python-worker/services/consolidation/engine.py):
resp = await self.client.chat.completions.create( model=self.model, messages=[{"role": "user", "content": prompt}], response_format={"type": "json_object"}, temperature=0.3, ) ---
python-worker/services/consolidation/engine.py
This establishes model-dependent memory processing within scope. It does not establish that the resulting memories are accurate or durably admitted. The boundary includes both the worker's proposed write-back calls and the API routes that would have to accept them; neither side is treated as an external application (SRC-1, python-worker/workers/tasks.py, go-api/internal/api/router.go).
The shipped LangChain adapter supplies a before/after consumer: it retrieves context through the SDK before model invocation and writes the human/assistant exchange afterward. Its declared persistence behavior is explicit (SRC-1, sdk/python/rem_memory/integrations/langchain.py):
def clear(self) -> None: """REM memories persist. This is intentional.""" return ---
sdk/python/rem_memory/integrations/langchain.py
The AutoGen adapter also exposes retrieval and turn persistence, but calling those helpers and assembling the enclosing agent remain host responsibilities (SRC-1, sdk/python/rem_memory/integrations/autogen.py). The SDK itself defines the handoff to that host:
Retrieve relevant memories before your agent starts a task. Inject result.injection_prompt into your LLM system prompt. ---
sdk/python/rem_memory/client.py
The source boundary therefore covers the supplied context and integration hooks, not proof that an external agent actually uses or follows the memories.
Shipped-path coverage
Every top-level tracked file or directory is classified below. All paths refer to SRC-1 at the frozen commit. “Included” makes a path available for subsequent analysis; initial inspection is stated separately. Files not yet read in detail are not access gaps and are not silently excluded.
| Top-level tracked path | Decision and role | Material paths and initial inspection | Exclusion or inspection limit and conclusion prevented |
|---|---|---|---|
.cursorrules |
Included: repository development instructions, not an agent-memory maintenance process | Read completely; specifies worker/service organization and consolidation design | Declared instructions alone do not establish their implementation |
.env.example |
Included: advertised configuration and dependency contract | Read completely; API, stores, worker, Celery, OpenAI and public frontend variables | Example values do not establish a deployed configuration |
.gitignore |
Included: evidence-retention context | Read completely; excludes environments, logs, build products and local state | Ignore rules do not establish contents of an actual installation |
Makefile |
Included: shipped process and development entry points | Read completely; dev, go, worker, dashboard, seed, tests, migrations and initialization targets |
Commands were inspected, not run; startup success is unestablished |
README.md |
Included: declared architecture, write/consolidate/retrieve loop, SDK and host-consumption examples | Read completely, including dashboard claims and roadmap | Claims are doctrine/design, not evidence of measured operation |
benchmarks/ |
Included: memory producers, later consumers and evaluation logic | Read adapters/rem_adapter.py; inspected scoring/run bodies in longmemeval.py, locomo.py, convomem.py; tree includes run_all.py and adapters/__init__.py |
Runner orchestration and complete sample definitions not yet inspected; source code is not a benchmark result or proof of official-dataset coverage |
dashboard/ |
Included: shipped presentation surface and claims about memory operation | Read src/app/page.tsx; searched src/ for API consumption; inspected claim matches in src/lib/config.tsx and src/lib/site.ts; tree includes section/UI components, public assets, package/build files and template README.md |
Initial inspection identifies a landing-page composition, not proof of the live dashboard functions described in the root README; components and build dependencies remain available for deeper checking |
docker-compose.yml |
Included: external-store deployment specification | Read completely; PostgreSQL, Redis, Qdrant, Neo4j and volumes | Does not establish launched services, stored state, or service compatibility |
docs/ |
Included: operator/API contracts and shipped usage instructions | Searched headings and memory-related passages of api-reference.md and quickstart.md, including retrieval, semantic listing, SDK use and continuous-consolidation setup |
Full documents not yet inspected; documented examples are not observed runs |
go-api/ |
Included: state admission, persistence, reloading, retrieval and access control | Read cmd/api/main.go, internal/api/router.go, internal/services/write_service.go, internal/services/retrieve_service.go, internal/db/redis/client.go, internal/db/postgres/migrations/001_initial.sql and tests/integration_test.go; searched DB methods in internal/db/postgres/{episodes,semantic}.go, internal/db/qdrant/client.go, internal/db/neo4j/client.go |
internal/api/handlers/, middleware, domain/config, remaining services and DB method bodies, Dockerfile and dependency manifests remain in scope but are not all read in detail; no execution or security assurance follows from this entry-point trace |
python-worker/ |
Included: model-dependent parsing, embeddings, consolidation prompts, maintenance scheduling and write-back | Read main.py, services/parse_service.py, services/consolidation/engine.py, services/consolidation/compressor.py, workers/celery_app.py, workers/tasks.py; searched api/router.py, handler bindings and services/consolidation/clusterer.py |
Router/handler bodies, clusterer, embedding/LLM helper bodies and packaging remain available for detailed analysis; the separate compressor and clusterer must not be assumed to be the engine's active path merely from their names |
scripts/ |
Included: setup and shipped memory-producing driver | Read seed_demo.py completely, including SDK writes and direct /consolidate call; searched schema/collection setup in init_neo4j.py and init_qdrant.py |
Initialization bodies not fully inspected; demo strings and calls do not establish real agent history or successful semantic persistence |
sdk/ |
Included: API clients and shipped retention/consumption integrations | Read python/rem_memory/client.py, python/rem_memory/integrations/langchain.py, python/rem_memory/integrations/autogen.py; searched usage/API headings in python/README.md; tree includes types.py, exceptions.py, __init__.py, pyproject.toml |
Remaining types, exports and packaging not yet read in detail; host invocation and downstream model behavior are not supplied run evidence |
test_rem.py |
Included: root test placeholder | Verified zero lines | Supplies no test behavior or results |
This coverage includes the inline parsing and consolidation prompts, worker scheduling and write-back instructions, API storage/reloading paths, integration hooks that later consume retained content, and shipped evaluators. There is no deliberately excluded material shipped memory responsibility. Initial inspection is sufficient to select the whole-system functional boundary, not to resolve every implementation question.
Dependencies and limits
PostgreSQL, Qdrant, Neo4j and Redis are external storage/queue dependencies; REM's configuration, client calls, schemas and initialization code are included, but those products' internal implementations and live state are not frozen here (SRC-1, docker-compose.yml, go-api/cmd/api/main.go). This prevents conclusions about the actual deployment's durability, availability, performance or recovery behavior.
OpenAI is an external model/embedding provider. The prompt text, request construction and response handling shipped in REM are included; provider internals, model revisions and returned outputs are not (SRC-1, python-worker/main.py, python-worker/services/parse_service.py, python-worker/services/consolidation/engine.py). This prevents accuracy, semantic-fidelity and reproducibility claims about generated memories without additional run evidence.
LangChain and AutoGen enclosing agents are external dependencies, but REM's shipped adapters and examples remain inside the target. Host task selection, full conversation control, model invocation and actual use of returned memory are not REM responsibilities merely because an adapter can supply context (SRC-1, sdk/python/rem_memory/integrations/langchain.py, sdk/python/rem_memory/integrations/autogen.py). This prevents crediting REM with autonomous task execution or measured downstream answer improvement.
No additional repository, dataset capture, hosted REM service or external link has been admitted as evidence. The benchmark source is included as implementation of evaluators, not as an observed run or an independent characterization (SRC-1, benchmarks/adapters/rem_adapter.py, benchmarks/longmemeval.py, benchmarks/locomo.py, benchmarks/convomem.py). No source access failure was encountered. Uninspected available files listed above are inspection limits, not inaccessible evidence.
Source register
| Source ID | Kind | Identity/location | Revision or capture | Evidence layer | Inspected scope | Citation anchors | Access gaps and conclusion prevented |
|---|---|---|---|---|---|---|---|
| SRC-1 | git | https://github.com/satyammistari/REM |
935e8be0a1fca5b23dbabfe16c48b562c1cd24cc | implementation; doctrine/design | Access root: /home/zby/llm/commonplace/.commonplace/worktrees/rem-a81fdc774400/related-systems/satyammistari--REM. Implementation: tracked tree; API entry point/router, write/retrieve services, Redis client, SQL schema, Python entry point/parser/consolidation engine/compressor/tasks/scheduler, SDK client and both integrations, seed driver, benchmark adapter and scoring/run bodies, integration-test source, frontend page composition. Doctrine/design: complete root README, Cursor rules, environment template, Makefile and Compose; scoped searches of docs, SDK README and frontend claims. Exact initial coverage and remaining inspection limits are in the table above. |
Implementation: API entry point, write path, retrieval, maintenance tasks, LangChain consumer, benchmark adapter. Doctrine/design: README, development instructions. | No repository access gap. No frozen deployment state, provider responses, enclosing-host run, benchmark output or intervention evidence: cannot establish successful end-to-end consolidation, real-world recall, downstream usefulness, performance or causal improvement. Listed initial paths are not an allowlist; any tracked path at this commit remains available for inspection. |