Dense-Mem boundary

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

Boundary and evidence

This run covers Dense-Mem as a self-hosted memory/knowledge/context-engineering system, not an enclosing conversational agent runtime. Its intended use is to retain evidence and semantic relationships, govern their ownership and lifecycle, and return eligible context to callers. Its own contract separates host judgment from memory-service authority (SRC-1, README.md):

The host LLM owns conversation and judgment. Dense-Mem owns durable evidence, owner authorization, lifecycle events, support eligibility, and bounded recall. --- README.md

The boundary is whole-system: the shipped server and its composition, storage and admission policies, model-facing assessment and extraction, lifecycle and maintenance workers, first-party portals, clients, export prompt and evaluation drivers are included. Same-repository callers are not excluded merely because they use MCP. This is a source boundary, not a claim that every function has already been inspected.

Loop and entry-point basis

The production entry point dispatches ordinary startup to serverapp.RunFromEnvironment; it also exposes the explicit migration-control-retirement command. Bootstrap opens PostgreSQL, runs migrations, checks the search/storage prerequisites and calls the active server. The active composition constructs knowledge, recall, ontology, access, privacy, audit and search adapters; wires applications into the MCP registry and browser transports; and starts search reconciliation, ontology maintenance, conflict review and housekeeping workers (SRC-1, cmd/server/main.go, cmd/internal/serverapp/bootstrap.go, cmd/internal/serverapp/server.go). Thus these shipped drivers and background paths belong to the target, rather than an excluded host.

Remember is wired to a synchronous processor with persistence, catalog, assessor and embedder dependencies. The service validates the actor and request and delegates to that processor; the inspected commit path uses a team/profile transaction, replay and duplicate fences and an active embedding-contract check. Session ingestion is a separate included intake path: it stages sessions, extracts windows, prepares semantic assessment and commits through its repository (SRC-1, cmd/internal/serverapp/remember_composition.go, internal/remember/service/service.go, internal/knowledge/postgres/remember_commit.go, cmd/internal/serverapp/session_composition.go, internal/session/service/service.go). These observations establish boundary coverage, not a complete transactional-correctness assessment.

Recall consumes retained state through the search/retrieval repositories, adds related relationships and community discovery, and returns results to the caller. Its own output guidance distinguishes discovery from support (SRC-1, internal/recall/recall.go):

result.DiscoveryGuidance = "Community discovery found derived relationship paths; verify details with trace_memory before using them as support." --- internal/recall/recall.go

Shipped consumption includes the Python client and examples, the stdio-to-HTTP MCP proxy, the user portal and evaluators. The Python Remember example submits, repeats the request, recalls and traces returned relationship handles; it is included rather than treated as an external application. The session example exercises ingestion and replay. The browser client renders recalled communities, evidence and relationships. These are source-described consumers, not observed successful runs (SRC-1, packages/python/src/densemem/client.py, packages/python/examples/remember.py, packages/python/examples/session.py, packages/mcp-proxy/src/run.js, web/src/user/api.ts).

The included maintenance surface covers both executable policy and operator instructions. The server starts ontology maintenance and conflict review; ontology maintenance claims work and invokes an organizer under configured policy. Manager documentation describes drafts, preview, publication and rollback. Provider prompts, team-scoping MCP instructions and the skill-export prompt are also part of the system, not external doctrine. MCP registers and renders catalog prompts for the host; the export prompt tells the host to recall before drafting and not automatically import the generated skill (SRC-1, cmd/internal/serverapp/server.go, internal/ontology/maintenance.go, internal/ontology/MANAGEMENT.md, internal/provider/assessor/remember.go, internal/session/extraction/provider.go, internal/mcp/server.go, internal/mcp/sdk_server.go, internal/promptcatalog/prompts/export_memory_as_agent_skill.md). In particular, the latter states:

Return the skill content as markdown code blocks. Do not import the generated skill into memory automatically. --- internal/promptcatalog/prompts/export_memory_as_agent_skill.md

Evaluation is included as a state-producing and later-consuming shipped path. The Go harness supports import, retained mappings/checkpoints, live recall or loaded traces, scoring and artifact output. The CLI exposes these modes. The Dockerfile distinguishes production and evaluation builds. Evaluation documentation describes the intended measurement boundary, not proof of achieved quality (SRC-1, cmd/eval-runner/main.go, internal/evalharness/runner.go, Dockerfile, tests/eval/README.md):

The evaluation harness does not use legacy memory-pack import tools or an answer-judge model. It measures retrieval against deterministic qrels after the terminal Remember result has been returned. --- tests/eval/README.md

Tracked top-level coverage

All entries below are from the frozen Git tree (SRC-1). “Included” keeps the material available for subsequent analysis. Initial inspection is explicitly narrower than the registered repository. Unread implementation detail is not an access gap.

External boundary and evidence limits

The frozen evidence is the repository at bd736450454e237f1ab6d138f4ae9755916d73f6, with applicability cutoff 2026-10-15, the supplied run date. HEAD matched the acquired revision and the checkout reported no changes at inspection. The source object above preserves the acquired values. No other repository, live page, preprint, hosted demo or revision supplies evidence.

External dependencies include PostgreSQL/pgvector, Redis or process-local coordination, OpenAI-compatible model/embedding endpoints, MCP libraries/clients and browser/container infrastructure. Their integration is included where shipped code configures or invokes it; their own implementations and live availability are outside this repository boundary. The README explicitly makes PostgreSQL durable authority and Redis coordination-only (SRC-1, README.md). This boundary cannot establish provider faithfulness, distributed service reliability or production durability from source wiring alone.

The enclosing host's conversation loop, selection of material to remember, prompt assembly after recall and downstream answer/use of returned content are excluded unless represented by a shipped consumer. This prevents attributing end-to-end agent behavior or answer improvement to Dense-Mem. The included export prompt is an instruction supplied to a host, not an inspected host execution.

No target execution, test run, model call or live-service observation was performed. The overall evidence tier is code-grounded, combining inspected implementation with target-authored doctrine/design. Evaluation instructions and drivers support how measurements are intended to work; they do not establish achieved retrieval scores or causal benefit. The evaluation README says approved seeds, persistent databases and run artifacts are local-only and ignored by Git (SRC-1, tests/eval/README.md). Those unprovided artifacts are an evidence gap for reproducing reported operations, not a missing shipped implementation path. Detailed tracked baselines remain available but uninspected. No inaccessible material shipped path was identified that requires reducing this boundary to a partial loop.

Source register