Skip to content

Memory Architecture

The memory architecture is the proposed next step after the batch build system: a continuously maintained memory store with explicit lifecycle management, provenance, and governance.

Status: In design and early implementation.

The build system works for cold data but is a poor fit for:

  • real-time state changes
  • concurrent writers
  • continual review and decay
  • governance over who can change shared state

The memory architecture is the proposed answer: keep the object-store and provenance ideas, replace periodic rebuilds with explicit write, review, and governance paths.

The architecture has four layers:

The memory architecture as four stacked layers: data model, governance, agents, and roadmap.
The architecture separates storage structure, governance, worker behavior, and implementation status into distinct layers.

Data Model — Immutable content-addressed objects, an append-only event log, policies stored as documents, and procedures stored as text. Infrastructure provides content-addressing, atomic writes, full-text search, and the event log.

Governance — Evidence-based writes, conflict resolution with audit trails, hypothesis tracking, and controlled convention changes. The goal is to prevent concurrent agents from degrading shared state.

Agents — Workers with defined roles and triggers. A minimal deployment has ingestion, synthesis, decay/archival, conflict resolution, and health-monitoring roles.

Roadmap — What is built, what is designed, and what is planned.

This architecture is not fully implemented.

  • The object store and search index come from the build system.
  • The event log, policy engine, and governance mechanisms are still design work.
  • The multi-agent parts should be read as proposed architecture, not observed system behavior.

What carries forward from the build system

Section titled “What carries forward from the build system”
ComponentSurvivesChanges
Object storeContent-addressing, atomic writesAdd author, region, confidence fields
SearchFTS5 keyword indexerBecomes a materialized view of the event log
TransformsPrompt templates, synthesis logicBecome procedure documents, not Python classes
ServerMCP endpoint, REST APIAdd event log and policy evaluation