cass_memory_system boundary

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

Boundary and evidence

This run analyses cass-memory (cm) as a memory system for coding agents, not as their enclosing execution runtime. Intended use is to characterize how its shipped software and instructions turn sessions into retained guidance, maintain that guidance, and expose it to later agent work. The target class is memory/knowledge/context-engineering system; the boundary kind is whole-system. The repository ships a CLI, an MCP-facing server, reflection and onboarding drivers, feedback and maintenance commands, and host hook templates. These are included responsibilities, not external applications merely because they call shared APIs (SRC-1: package.json, src/cm.ts, src/commands/serve.ts, src/commands/hook.ts, src/commands/onboard.ts).

The frozen evidence is repository https://github.com/Dicklesworthstone/cass_memory_system at full commit 8aca3bbb6732321dca041b32c155617784687897. The acquired checkout's HEAD equals that revision and its working tree was clean on inspection. The applicability cutoff is the opening's run date, 2026-10-13, not a claim that this revision represents every deployment on that date. The overall tier is code-grounded: executable source establishes the shipped mechanisms; target-authored instructions establish intent. No target execution, tests, model calls or services were run. Later revisions and outside repositories are not evidence in this run.

Classification and shipped loop

The target explicitly describes a transformation from sessions to rules, and its implementation has both a retained-state producer and a later consumer. This establishes an in-scope memory system rather than merely a returning search utility (SRC-1: README.md, src/orchestrator.ts, src/playbook.ts, src/commands/context.ts).

cass-memory implements a three-layer cognitive architecture that transforms raw session logs into actionable, confidence-tracked rules: --- README.md

The package compiles src/cm.ts and exposes both cass-memory and cm; that driver registers context, reflection, onboarding, playbook, mark, outcome, guard and other commands. Reflection discovers or accepts sessions, exports their content through the cass adapter, generates and saves diaries, proposes deltas through a model-backed reflector, validates them, curates them, and writes global and repository playbooks before recording processed sessions. Onboarding is a second shipped production route: it supplies extraction instructions to the calling agent, which uses playbook-add commands to persist its rules. Both routes belong to the boundary (SRC-1: package.json, src/cm.ts, src/commands/reflect.ts, src/orchestrator.ts, src/diary.ts, src/reflect.ts, src/llm.ts, src/validate.ts, src/commands/onboard.ts, src/commands/playbook.ts).

You are analyzing a coding session to extract reusable rules for the playbook. --- src/commands/onboard.ts

await savePlaybook(globalToSave, globalPath, { updateLastReflection: true }); --- src/orchestrator.ts

Context generation reloads and merges retained playbooks for the requested workspace, scores active rules, selects within a budget, and combines them with history from cass. MCP cm_context uses the same generator; memory_reflect invokes the shipped orchestrator. Feedback commands update stored rule events and maturity. Project export can write instruction text to a caller-selected file. The installed session-end hook starts the CLI reflection driver; it is therefore inside the system's production loop, even though a host emits its input (SRC-1: src/commands/context.ts, src/commands/serve.ts, src/commands/mark.ts, src/commands/project.ts, src/commands/hook.ts).

const playbook = sources.playbook;

const keywords = extractKeywords(task); const cassQuery = buildCassHistoryQuery(task); --- src/commands/context.ts

const argv = [...selfInvocation(), "reflect", "--session", decision.transcriptPath!, "--json"]; --- src/commands/hook.ts

The instruction surfaces also belong to the consumption and feedback loop: the skill and repository memory protocol tell agents to retrieve context before work and leave feedback references during work. Their claim that learning happens automatically is declared protocol, not an observed guarantee that every installation has automation configured (SRC-1: SKILL.md, AGENTS.md, docs/planning/AGENTS.md.blurb, src/commands/hook.ts).

1. START: cm context "" --json
2. WORK: Reference rule IDs when following them (e.g., "Following b-8f3a2c...")
3. FEEDBACK: Leave inline comments when rules help/hurt
4. END: Just finish. Learning happens automatically. --- SKILL.md

The safety-state path is included too: trauma storage persists global or project entries, and generated Python hooks reload active entries to check host commands or staged changes. This is a shipped consumer of retained content, not merely developer tooling (SRC-1: src/trauma.ts, src/commands/guard.ts, src/trauma_guard_script.ts). Evaluators include the source-level retrieval benchmark and stubbed CLI learning-loop tests. They are inspectable test designs, not results observed in this run (SRC-1: test/context-retrieval-benchmark.test.ts, test/learning-loop.e2e.test.ts).

External dependencies and limits

• cass search/index/export and originating agent logs: the included adapter invokes the external cass executable and can query remote hosts through SSH. cass's index construction, remote corpus completeness and the hosts' transcript production are outside this repository boundary. This prevents claims about their internal behavior, exhaustive historical coverage, or cross-machine deployment success; it does not exclude CM's discovery, export, sanitization or retrieval adapter (SRC-1: src/cass.ts, src/diary.ts, src/orchestrator.ts).
• Models and embedding backends: provider SDKs and transformer dependencies are declared, and CM constructs model prompts and calls its generation wrapper. Provider internals, model weights, API availability and returned model quality are not frozen evidence. This prevents claims that generated lessons are correct or that configured backends work in deployment; prompt construction, validation and fallback code remain included (SRC-1: package.json, src/llm.ts, src/reflect.ts, src/validate.ts).
• Enclosing agents, MCP clients, schedulers and Git: CM supplies commands, protocol text and hook payload consumers, not the full hosts. No host transcript demonstrating actual compliance was supplied. This prevents attributing the hosts' task planning, command execution, hook delivery or adherence to returned guidance to CM (SRC-1: SKILL.md, src/commands/hook.ts, src/commands/serve.ts, src/trauma_guard_script.ts).
• Execution evidence: all available evidence here is source text. Tests were inspected but not executed, and no independently inspectable deployment trace or causal experiment was supplied. This prevents observed success-rate, performance, safety-effectiveness or causal learning claims. The benchmark's assertions and stubbed loop's expected behavior may be described as test contracts only (SRC-1: test/context-retrieval-benchmark.test.ts, test/learning-loop.e2e.test.ts).
• Historical proposals and repository administration: deliberately excluded from shipped behavioral claims as detailed below. Their existence does not narrow the shipped memory loop. No material shipped path was unavailable; files awaiting deeper analyst inspection are not access gaps.

Top-level tracked coverage

The table accounts for every top-level tracked file or directory from the pinned Git tree. “Included” fixes the functional scope, not a claim of exhaustive line-by-line inspection. “Inventory only” and “selected inspection” distinguish material still to inspect from unavailable evidence. All anchors in this table refer to SRC-1. No top-level directory was inaccessible.

Source register