Context Repositories

A context repository is a durable, inspectable collection of memory files, project state, metadata, schemas, histories, and derived summaries that an agent can read and revise across runs. A chat is one interaction surface over that state. The repository is the body that survives when the chat ends.

The concept appears concretely in Letta Code, where MemFS stores agent context in a Git-backed file tree. It can also describe other systems built from databases, object stores, knowledge graphs, or mixed storage, provided the state has durable identity and an inspectable structure.

Repository and run

The layers serve different purposes:

agent
  identity, behavior, tools, capabilities

context repository
  durable user, project, world, and operating state

conversation or run
  a bounded interaction using selected repository state

Conversation history remains useful evidence. It is a chronological event log, however, rather than a complete working representation. A project specification, current-state record, correction history, and reusable procedure have different ownership and update rules even if each originated in conversation.

What belongs in a context repository

A repository can contain:

• identity and behavior definitions;
• current state and active project records;
• concept notes and source material;
• timelines and raw event history;
• skills, schemas, and operating procedures;
• provenance, approval, and effect receipts;
• indexes and routing rules;
• tests and restoration manifests.

The file tree is not itself the memory architecture. Titles, descriptions, frontmatter, indexes, canonical ownership, and retrieval routes determine whether the state remains usable as it grows.

Versioning and repair

Version control turns memory edits into inspectable transitions. Git stores snapshots through content-addressed objects and commit history, making it possible to compare revisions, identify authorship, and restore an earlier tree. That machinery is useful for memory because correction and deletion have different meanings from silent replacement.

A versioned repository can answer:

• What did the agent's memory say at a particular time?
• Which revision introduced a claim or operating rule?
• What changed during a model or runtime migration?
• Can a damaged summary or mistaken update be rolled back?
• Does a restored copy match the expected state?

Version history does not make the contents true. It makes changes attributable and reversible.

Multiple projections

One context repository can have several projections without forcing every participant into one interface. A human may use an Obsidian vault, an agent may use a machine-oriented MemFS tree, and a public website may expose a reviewed subset. The projections can share concepts while retaining distinct privacy, synchronization, and editing boundaries.

Literal folder unification is often the wrong goal. Two tools can coordinate through explicit links, manifests, and synchronization contracts while keeping separate storage engines. The conceptual repository is the governed state; one directory is only an implementation.

Access and privacy

A context repository can contain the most sensitive state in an agent system. Access control should operate before retrieval, not after private material has already entered a model prompt. Useful controls include source-level permissions, scoped mounts, public/private labels, audit trails, and explicit declassification for publication.

Strong context references add version and authority to a repository path. They make it possible to say which exact state was used without copying the state into every downstream artifact.

Limits

A repository solves durability and inspectability. It does not guarantee relevant retrieval, coherent compaction, accurate content, appropriate permissions, or behavioral continuity after restoration. Those are separate parts of the agent-memory system.