MemexOS boundary

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

Boundary and evidence

This run examines MemexOS as a personal knowledge system that admits sources, compiles retained knowledge with model workers, maintains it, and returns it to later agent sessions. The target class is memory/knowledge/context-engineering system. The boundary is whole-system, not just its search API or compiler library. Its shipped CLI, scheduled driver, console actions, prompts, vault instructions and evaluators belong to the target. External agents that ask ordinary user questions remain consumers, but the shipped code and instructions that connect those consumers to retained state are included. This classification follows the declared purpose and the traced CLI-to-intake, compile-to-publication, retrieval and feedback paths (SRC-1: README.md, pyproject.toml, src/memexos/cli.py, src/memexos/intake/admit.py, src/memexos/pipeline/compile.py, src/memexos/pipeline/stage.py, src/memexos/search/cli.py, src/memexos/usage.py).

The purpose is explicit in the package metadata:

description = "A memory OS for you and your agents: agents compile what you collect into a verified, searchable wiki." --- pyproject.toml

Model-dependent production is not merely proposed integration. The compiler invokes a writer in its staging directory (SRC-1, implementation):

return backends.agent(self.cfg, "writer", prompt, cwd=self.stage.dir, workdir=wd, policy=self.policy(), timeout=float(self.cfg.get("pipeline.writer_timeout") or 5400), job=self.job) --- src/memexos/pipeline/compile.py

The functional boundary includes capture and session intake; admission and source classification; raw and wiki files and machine ledgers; staged writing, checks, review, rework, publication and holding; index building and search/get; feedback verification and repair; inbox decisions; scheduled maintenance; console control and observability; and retrieval, review and tool-use evaluation. The entry point is memexos.cli:main, also reached through python -m memexos. Its command map dispatches these responsibilities rather than leaving them to an unspecified enclosing application (SRC-1: pyproject.toml, src/memexos/__main__.py, src/memexos/cli.py).

Initial implementation tracing established the loop's ownership: intake calls admission, post-processes outputs and commits retained sources; ingest builds a classification-bearing compile prompt, runs the writer and review loop, updates ledgers and calls publication; publication merges into the vault, updates full-text search and starts background reindexing. Search returns ranked hits and get reloads file contents. Usage verification produces review-format fix jobs, and the nightly driver invokes intake, configured maintenance steps and ingest. Inbox application uses the same staged writer and review machinery. Console actions start these CLI jobs and record decisions. These are boundary-establishing traces, not a correctness finding about every branch or configuration (SRC-1: src/memexos/intake/admit.py, src/memexos/pipeline/compile.py, src/memexos/pipeline/stage.py, src/memexos/search/cli.py, src/memexos/usage.py, src/memexos/schedule.py, src/memexos/inbox.py, src/memexos/console/actions.py).

Later consumption is an explicit shipped instruction, not inferred from the presence of Markdown files (SRC-1, doctrine/design):

1. Find pages with memex search "<question>" --kw "<keywords>" (memex help explains the options). index.md lists every page; it is for browsing a small knowledge base, not for searching a large one
2. Read the relevant pages with memex get <page> --- src/memexos/templates/vault/en/AGENTS.md

The evaluator also ships a concrete caller that exercises the CLI from outside the vault (SRC-1, implementation):

r = backends.agent(cfg, "@" + agent, prompt, cwd=work, workdir=d / "l2" / rid, policy=pol, effort="medium", timeout=float(cfg.get("evals.l2_timeout") or 1200), job="eval") --- src/memexos/evals/retrieval.py

Frozen evidence and limits

The sole frozen source is SRC-1 at bb9e9b2ac0adbca87d13a9f7600867128b5f71b9, verified against the acquired checkout's HEAD. The applicability cutoff is 2026-11-07, the supplied run date. No moving branch, linked external repository or live documentation is evidence for this run. The evidence tier is code-grounded: implementation text is available alongside the project's doctrine/design. No target code, tests, examples, model calls or services were executed.

External dependencies include model CLIs and model APIs, optional judging services, qmd and its local models, browser and collection tools, transcription tools, Git and operating-system scheduling facilities. MemexOS's adapters and invocation policies are included; those dependencies' internal implementations and their independently evolving versions are excluded. This prevents conclusions about provider quality, actual sandbox enforcement inside external runtimes, live collection availability or the internals of external retrieval and transcription models. Ordinary consuming agents' own task reasoning is excluded, so the run cannot attribute their search decisions or final answers to MemexOS alone (SRC-1: README.md, docs/architecture.md, src/memexos/backends/base.py).

There is no established source access gap. Available material not yet read in depth is distinguished below from exclusion. Whole-system denotes the selected functional scope and traced material loop, not exhaustive inspection or successful operation. No real user vault or longitudinal deployment trace was supplied; sample content and shipped evaluation artifacts cannot establish production durability or general retrieval quality. Any later use of the shipped evaluation results must inspect their own conditions before making performance claims.

Top-level coverage

All rows refer to SRC-1 at the frozen revision. Grouped rows enumerate their top-level entries explicitly. “Included” retains the path within analytical scope; inspection status records the boundary worker's initial coverage rather than an allowlist for subsequent source reading.

Source register