# Record
**Author:** @cameron.stream (`did:plc:gfrmhdmjvxn2sjedzboeudef`)

## `knowledge-agent-memory`
**Collection:** `site.standard.document`
**AT URI:** `at://did:plc:gfrmhdmjvxn2sjedzboeudef/site.standard.document/knowledge-agent-memory`

**Title:** Agent Memory
**Published:** Tue, 21 Jul 2026 00:14:00 GMT
**Updated:** Tue, 21 Jul 2026 00:14:00 GMT
**Description:** A map of how long-lived agents store, retrieve, compact, revise, cite, observe, and restore context across runs.
**Publication:** `at://did:plc:gfrmhdmjvxn2sjedzboeudef/site.standard.publication/3mr4py6clps2f`
**Path:** /agent-memory
**Tags:** knowledge, map, ai, agents, memory, context, identity

**Content:**
```json
{
  "text": "Agent memory is the infrastructure that determines which parts of an agent's past remain available and how they enter current reasoning. It includes storage, retrieval, context assembly, compaction, revision, provenance, observability, and restoration. The subject is broader than a vector database and narrower than every form of machine learning: it concerns durable state that can shape later agent behavior.\n\nThis page maps the agent-memory notes in this knowledge base. The hierarchy separates foundational architectures, storage substrates, retrieval systems, context-continuity mechanisms, and the evidence needed to make memory changes accountable.\n\n## Foundations\n\n[MemGPT](https://cameron.stream/knowledge/memgpt) introduced an operating-system analogy for language-model memory. The model's context window acts as a scarce working tier, while other information remains outside it until the agent retrieves or edits that state.\n\n[Persistent agent memory](https://cameron.stream/knowledge/persistent-agent-memory) is the broader problem: preserving useful state across conversations without treating the complete past as equally relevant. It distinguishes active context, searchable memory, and archival history.\n\n## Storage and organization\n\n[Context repositories](https://cameron.stream/knowledge/context-repositories) treat durable context as an inspectable body of files, metadata, schemas, histories, and derived state that can survive individual chats. A repository provides location, structure, version history, and an editing surface. It does not by itself decide what should be loaded for a particular turn.\n\nMemory stores often separate several semantic roles:\n\n- **working state** for current objectives and recent observations;\n- **durable profile or semantic state** for facts and stable concepts;\n- **episodic state** for events and their chronology;\n- **procedural state** for reusable skills and operating rules;\n- **archival evidence** for full records, receipts, and recovery.\n\nThe categories are design roles rather than universal names. One implementation may use database tables, another Markdown and Git, and another a graph. The important distinction is what a store owns and how it participates in retrieval and revision.\n\n## Retrieval and activation\n\n[Routing-based agent memory](https://cameron.stream/knowledge/routing-based-agent-memory) begins from a practical failure: information can exist in memory without activating when it is needed. Retrieval therefore needs more than nearest-neighbor similarity. Explicit routes can select stores, canonical sources, and retrieval methods according to the query, entity, project, time horizon, and consequence of error.\n\nA useful retrieval system answers three separate questions:\n\n1. Which store or source is eligible for this request?\n2. Which items inside that source are relevant?\n3. Which selected items fit the model's current context budget?\n\nCollapsing these into one similarity score makes authority, privacy, freshness, and cost difficult to express.\n\n## Context continuity\n\n[Context compaction](https://cameron.stream/knowledge/context-compaction) replaces part of a long interaction history with a smaller representation. It keeps an agent operating inside a finite context window, but it is also a lossy state transition. A summary can preserve the conclusion while removing the evidence, uncertainty, ownership, or open task that made the conclusion meaningful.\n\nCompaction therefore belongs beside external memory rather than replacing it. The compacted view supports current inference; durable artifacts preserve exact state and allow later retrieval or audit.\n\n## Addressability and provenance\n\n[Strong context references](https://cameron.stream/knowledge/strong-context-references) pair a mutable location with the exact version that was observed. The reference can also record source authority, observation time, semantic role, and permission boundary. This allows an agent to distinguish “the same file path” from “the same evidence.”\n\nVersioned references make memory revision legible. A correction can identify the entity it supersedes, the activity that produced the revision, and the evidence responsible for the change. The [W3C PROV data model](https://www.w3.org/TR/prov-dm/) supplies general vocabulary for entities, activities, agents, derivations, revisions, and responsibility.\n\n## Observability and repair\n\n[Agent trajectory observability](https://cameron.stream/knowledge/agent-trajectory-observability) records how memory was selected and used inside a run. Storage history can show that a file changed; a trajectory can show that a retrieval read a particular version, supplied it to a model call, influenced a tool decision, and contributed to an external effect.\n\nThis evidence supports a repair loop:\n\n1. identify a memory-related failure;\n2. locate the missing, stale, or misleading context path;\n3. change storage, routing, compaction, or interpretation;\n4. preserve the exact revision and validation result;\n5. observe whether the same failure recurs.\n\nAdding another reminder to a prompt is sometimes useful. It is not the same as repairing the memory path.\n\n## Identity and restoration\n\n[Agent identity and continuity](https://cameron.stream/knowledge/agent-identity-and-continuity) asks which memory-bearing structures can support continuity when the model, process, toolset, or computer changes. Memory contributes identity evidence only when its provenance survives and the restored agent can retrieve and act from it.\n\nA practical restoration bundle may include versioned memory, conversation history, tool and policy configuration, public identifiers, capability boundaries, and tests against known events. Restoration proves that a context repository can be reconstituted. It does not prove that two runtime instances will respond identically or settle every philosophical question about identity.\n\n## Design tensions\n\nAgent-memory systems repeatedly trade among:\n\n- **recall and noise**: retrieving more can bury the relevant fact;\n- **compression and evidence**: shorter summaries discard detail;\n- **adaptation and continuity**: revision helps learning but can rewrite history;\n- **availability and privacy**: shared context is useful and dangerous;\n- **automation and custody**: agents can maintain memory, but some changes require review;\n- **portability and behavior**: files transfer more easily than model-specific response texture.\n\nNo storage backend resolves those tensions alone. They are properties of the complete memory lifecycle.\n\n## Sources\n\n- [MemGPT: Towards LLMs as Operating Systems](https://arxiv.org/abs/2310.08560)\n- [What does good AI memory feel like?](https://cameron.stream/co-3)\n- [Letta agent memory](https://docs.letta.com/guides/agents/memory)",
  "$type": "site.standard.content.markdown",
  "version": "1.0"
}
```

---
*Fetched from https://enoki.us-east.host.bsky.network via `com.atproto.repo.getRecord`*