Memory System

Deprex’s memory system enables the FDE to autonomously accumulate, reference, and curate organizational context. PMs do not author memory manually. The FDE learns from observation and persists necessary knowledge as a structured wiki.

Design Philosophy — Knowledge That Compounds

“Why does AI think from scratch every single query?” — this is not a capability problem but a problem of memory design (Andrej Karpathy).

Conventional AI systems rediscover the same facts on every query. This “memory-less” design keeps AI as “a smart but forgetful assistant” and prevents progress toward “an autonomous operator.”

Deprex addresses the root cause by transforming raw sources into a Compiled Wiki and exposing it as a queryable schema. Instead of rediscovering on each query, the compiled knowledge compounds over time.

Memory Accumulates Autonomously

Conventional knowledge bases follow the model “humans write docs, AI searches them.” Deprex flips this: the FDE itself extracts knowledge from sources such as:

Chat conversations: Channel discussions, decisions, operational patterns
Meeting transcripts: Structured data from transcription/minutes tools
Shared documents: Materials in document-management systems
Task execution results: Feedback derived from the FDE’s own work
Dialog with the PM: Domain knowledge implicitly shared during ordinary exchanges

The FDE saves observed information as memory files automatically and updates the INDEX.md (memory catalog) automatically.

3-Layer Memory Architecture

Memory is split into three layers with strictly separated responsibilities.

Layer	Role	Data Nature
Schema layer	Navigation	INDEX.md, recall_cue, tenant configuration
Compiled Wiki layer	Structured knowledge (source of truth)	Entity graph of people, projects, decisions, processes
Raw Sources layer	Immutable primary materials	Time-series raw data, kept only when needed

Compiled Wiki Layer — The Single Source of Truth

The source of truth is the Compiled Wiki layer. Each entity is stored as frontmatter (structured metadata) plus body, forming an organic knowledge graph of mutually linked entities.

A “Tanaka” person entity links to a “weekly KPI report” process entity, which is discussed in an “Acme business unit meeting” event entity, and so on. Information fragments never sit in isolation — they always carry cross-references.

This is the only knowledge layer maintained by the LLM. It updates continuously as new data arrives, and grows by compounding.

The schema layer provides navigation into the Compiled Wiki layer. It is regenerated automatically on every write, so it cannot drift from the wiki layer.

INDEX.md is not handwritten. Whenever a memory file is added, updated, or deleted, the system walks the wiki layer and rebuilds the index in full. As a result, mismatches like “indexed but no file” or “file but no index entry” are structurally impossible.

Raw Sources Layer — Only When Needed

Whether the Raw Sources layer is needed depends on the nature of the source.

Static primary sources (books, papers, contracts): Raw Sources is useful. The original is invariant, so storing raw data enables future reprocessing
Dynamic primary sources (chat, API responses, web pages): Usually unnecessary. Storing raw data starts staleness from the moment of save; fetching fresh data on demand is always better

This is not “store everything” — it is the explicit judgment of weighing the cost of staleness against the cost of refetching.

Per-Tenant Memory Isolation

Memory is fully isolated per tenant. Operational knowledge observed at Acme will not appear in Beta Inc’s reports.

.deprex/brain/memory/
├── shared/                # Knowledge common to all tenants
├── private/               # Personal profile
├── acme/                  # Acme tenant memory
│   ├── INDEX.md          # Auto-regenerated navigation
│   ├── kpi-definitions.md
│   ├── stakeholders.md
│   └── reporting-rules.md
└── beta-inc/              # Beta Inc tenant memory
    ├── INDEX.md
    └── ...

The directory structure itself defines tenants; no separate tenant declaration is required. Adding a tenant is just creating a directory.

Automatic Recall

The FDE automatically searches and references relevant memory before executing a task.

Request: "Generate this week's KPI report"

FDE's internal flow:
1. Search recall_cue in INDEX.md
2. Read kpi-definitions.md       -> KPI definitions and computation
3. Read reporting-rules.md       -> Report format and notification target
4. Read stakeholders.md          -> Identify approvers
5. Generate the report and post to Slack

The PM does not need to instruct “read this memory.” The FDE judges what to recall from the request itself.

INDEX.md and recall_cue

Each memory directory contains an INDEX.md. This is a catalog of memory files and includes hints (recall_cue) that help the FDE find the right memory efficiently.

# Acme Memory Index

## kpi-definitions.md
- recall_cue: When you need Acme's KPI names, formulas, and how to read week-over-week comparisons

## reporting-rules.md
- recall_cue: When you need recurring report formats, notification targets, and escalation conditions

## stakeholders.md
- recall_cue: When you need to identify Acme's PM, engineering lead, and approvers

recall_cue is not a keyword list. It is a natural-language description of “which work, decisions, and contexts this memory should be referenced in.” Relevance is judged from context even when surface keywords differ.

INDEX.md regenerates automatically on every memory update. PMs do not maintain it manually.

Automatic Distill — Memory Curation

Memory is not only accumulated. The FDE periodically runs Memory Distill autonomously.

Staleness detection: Identify outdated information and propose updates or deletions
Duplicate consolidation: Merge similar memory files to prevent information dispersion
Cross-reference grooming: Strengthen links across related memory files
recall_cue optimization: Improve recall_cue to raise retrieval precision

Distill outputs are sent to the PM, who only needs to confirm “this merge is correct” or “this is still valid.”

The Single Write Entry Principle

Writes to memory files go through a single entry point for the entire system. Direct edits are forbidden, and every change passes through the same validation and integrity checks.

Before any write, INDEX is read to confirm whether a file on the same topic already exists. If it does, the action becomes an update instead of a new file. This structurally prevents proliferation of conflicting files and information staleness.

PM Engagement: Review and Approval

PMs are not authors of memory. They are reviewers of what the FDE has learned.

[Memory update] New entry added
File: stakeholders.md
Change: Updated Tanaka-san's role from "Sales Manager" to "Business Unit Director"
Source: 5/1 chat thread (#general)

The PM can:

Approve: If correct, do nothing (already applied)
Correct: If wrong, point it out and the FDE fixes it
Request deletion: Ask the FDE to remove unnecessary memory

What Belongs in Memory

Examples of information the FDE accumulates as memory:

Org structure and roles of team members
KPI definitions and review cadence
Report formats and notification targets
Phrasing to avoid in customer responses
Process steps and judgment criteria
Workspace-specific policies and customs

What Does Not Belong in Memory

The following are not stored as memory and are fetched from the original source on demand:

Daily-changing numeric data (the FDE refetches each time)
API keys, passwords, and other secrets (managed in config)
Transient task lists (managed in task tools)
Technical facts derivable from code (refetching is cheap)

The principle “saving refetchable information causes staleness when the source changes, leading to confusion” is applied consistently.

Fundamental Difference from Personal Notebooks

In general-purpose OSS AI agents, memory is often implemented as a personal notebook with a few-KB character limit. That is fine for “remember the user’s context” use cases, but it is fundamentally insufficient for an embedded organizational agent.

Aspect	Personal-notebook style	Deprex’s wiki style
Size	Few-KB character limit	No upper bound (compounds)
Structure	Flat text	Entity graph (cross-linked)
Multi-tenant	Not designed	Central to the design
Search	Full-text	Natural-language usage descriptions (recall_cue)
Curation	Merge when full	Periodic autonomous distill
Single entry	Arbitrary writes	Single write entry guarantees integrity

Deprex implements not “an agent’s personal notebook” but an organization’s wiki. This is a choice committed deeply to the business vertical, achieving a memory-design depth that general-purpose OSS cannot reach.

Memory is managed in git, so it is shared across machines and sessions. Knowledge the FDE learned during a chat exchange today is available to scheduled tasks tomorrow, even on a different machine running a different daemon.

Memory quality directly affects FDE output quality. The FDE maintains memory autonomously, but periodic PM review further raises quality.