File-Based Memory

Source Excerpt

Category: Operational Infrastructure

Applies To: All Four Persistent Agents

Version: 1.0 (2026-04-10)

Definition

File-Based Memory is retired internal project's state persistence mechanism where all cognitive state, decisions, and learnings are written to durable files rather than relying on in-memory context. This ensures continuity across session restarts and prevents knowledge loss.

Core Principle: "Mental notes" do not survive restarts. If a lesson is learned or a decision is made, document it immediately to file. The wiki and memory files are the system of record—not any agent's conversation history.

Why This Model Matters

The Session Reset Problem

AI agents have no persistent memory across sessions:

• Each session starts with zero context from previous runs
• Conversation history is lost when sessions end
• Learnings discovered in one session are forgotten in the next
• Without file-based persistence, the same mistakes repeat indefinitely

The Solution: Write Everything to Files

File-Based Memory provides:

• Session continuity — New sessions read prior state from files
• Compounding intelligence — Learnings accumulate over time
• Audit trail — All decisions are traceable to written records
• Shared context — Multiple agents can read the same memory files
• Founder visibility — Jared can inspect any memory file at any time

Memory Architecture

Three-Tier Memory System

┌─────────────────────────────────────────────────────────────┐
│                    MEMORY HIERARCHY                         │
├─────────────────────────────────────────────────────────────┤
│  Tier 1: Session Context (Volatile)                         │
│  - Current conversation history                             │
│  - Tool call results                                        │
│  - Lost when session ends                                   │
├─────────────────────────────────────────────────────────────┤
│  Tier 2: Short-Term Memory (Daily Files)                    │
│  - memory/YYYY-MM-DD.md                                     │
│  - Raw session logs, actions taken, decisions made          │
│  - Written during each session                              │
│  - Retained indefinitely                                    │
├─────────────────────────────────────────────────────────────┤
│  Tier 3: Long-Term Memory (Curated)                         │
│  - MEMORY.md                                                │
│  - Distilled insights, refined mental models                │
│  - Curated from daily logs during main sessions             │
│  - The "source of truth" for durable knowledge              │
└─────────────────────────────────────────────────────────────┘

File Locations

Operational Procedures

Session Initialization (Every Agent)

At the start of every session, agents MUST read in this order:

1. SOUL.md — Identity and moral foundation (immutable core)
2. IDENTITY.md — Role specifics and authority boundaries
3. MEMORY.md — Durable context (NOT in shared/group contexts to prevent data leakage)
4. Recent session logs — Last 1-3 days from memory/YYYY-MM-DD.md
5. Current priorities — From governance artifacts or wiki

Critical: Do NOT load MEMORY.md in shared/group contexts. It contains agent-specific knowledge that should not leak across conversation boundaries.

During Session Operations

As work progresses, agents MUST:

1. Log significant decisions immediately — Don't wait until end of session
2. Write to daily memory file — memory/YYYY-MM-DD.md for the current date
3. Reference wiki when applicable — If decision affects structured knowledge
4. Flag items for curation — Mark learnings that should move to MEMORY.md

Session Wrap-Up (Every Agent)

Before ending each session, agents MUST:

1. Review what was learned — Identify key insights from the session
2. Ensure all decisions are logged — Nothing left only in conversation history
3. Update relevant wiki pages — If structured knowledge changed
4. Flag items for MEMORY.md curation — Note which learnings need long-term storage

Curation Process (Main Sessions Only)

Periodically (recommended: during main sessions with Jared), agents should:

1. Review daily memory files — Read memory/YYYY-MM-DD.md for recent days
2. Extract durable insights — Identify patterns, decisions, and learnings worth keeping long-term
3. Update MEMORY.md — Add curated entries to the appropriate sections
4. Archive old logs — Move processed daily logs to archive if needed

Memory File Formats

Daily Memory File (memory/YYYY-MM-DD.md)

# Session Log: 2026-04-10

**Agent:** Julius
**Session Type:** Cron job (Large Language Model-wiki-build)
**Duration:** ~90 minutes

---

## Actions Taken

- [ ] Task 1 description
  - Steps taken
  - Results observed

- [ ] Task 2 description
  - ...

## Decisions Made

| Decision | Rationale | Impact |
|----------|-----------|--------|
| Description | Why this choice was made | What changes as a result |

## Errors Encountered

- Error description
  - Root cause (if identified)
  - Resolution or workaround

## Questions Unresolved

- Question that needs follow-up
  - Context
  - Who should address it

## Learnings for Curation

> Insight that should move to MEMORY.md: [description]

---

*Session ended at [timestamp]*

Curated Memory (MEMORY.md)

# retired internal project — Long-Term Memory

**Last Updated:** 2026-04-10
**Curated By:** Julius (with team input)

---

## Architecture & Infrastructure

### Hub-and-Worker Model
retired internal project uses a Mac Studio (256GB Unified RAM) as the central coordination hub, with distributed workers:
- Mac Minis for general compute tasks
- Ubuntu GPU hosts for model inference

### Security Zones
Four-zone Network Security Fundamentals model:
- Zone 1 (DMZ): Gateway Pi — only internet-facing component
- Zone 2 (Vault): Guardian Pis — hold air-gapped auth fragments and audit replicas
- Zone 3 (Command): Mac Studio Hub — agents run here
- Zone 4 (Execution): Worker nodes — isolated execution environments

---

## Governance Operating Memory

### The Hard Quad
Four persistent agents with distinct, non-overlapping authorities:
- **Julius (GOV)** — Policy, priorities, release authority
- **Cypher (PLAT)** — Infrastructure, deployment, operations
- **Reacher (DATA)** — Validation, evidence quality, benchmarks
- **Octavius (K&E)** — Knowledge curation, effectiveness, learning

[... additional curated content ...]

Access Control & Data Leakage Prevention

When NOT to Load MEMORY.md

MEMORY.md contains agent-specific knowledge that should not leak across conversation boundaries. Do NOT load it in:

• Shared/Group Contexts — Multi-Agent Orchestration conversations where all agents are present
• Cross-Agent Delegations — When one agent delegates to another's subagent
• Public-Facing Operations — Any context where output might be visible outside the team

When TO Load MEMORY.md

Source excerpt truncated at 220 of 295 lines. Open the canonical wiki path above for the full page.