
1. Memory is a stack, not a layer
Conversations about AI agent architectures often refer to "the memory layer" in the singular. That shorthand obscures how systems work in practice. Memory is not one component. It is a stack of distinct concerns, and even a single artifact like a bare markdown file participates in several of them at once.
Two lineages are colliding in agent tooling:
- The formal-knowledge past. The Semantic Web, RDF triples, SPARQL endpoints, OWL ontologies, PROV-O provenance, XML databases, and HATEOAS application architectures. This lineage was mathematically rigorous and self-describing. It also overshot: it demanded global ontologies, description-logic reasoners, and heavy serialization formats before you could store your first note.
- The agentic reboot. Folders of markdown, folksonomy tags, wikilinks,
CLAUDE.mdandAGENTS.mdcontext files, vector stores, and local memory engines. This lineage is fast, human-readable, and git-friendly. It also under-formalizes: it drops typed predicates, leaves identity unstable under file moves, and largely discards provenance.
Both lineages solve the same underlying problems. As flat-file conventions grow more structured, agent memory reveals itself as a stack of nine layers across three planes. The engineering question is not which lineage to choose, but which past concept is worth reintroducing at each layer without dragging back the overhead.
┌──────────────────────────────────────────────────────────┐
│ Plane C: The Runtime (How an agent uses memory) │
│ L8 Interface │ L7 Lifecycle │ L6 Retrieval │
├──────────────────────────────────────────────────────────┤
│ Plane B: The Graph (How units relate and mean) │
│ L5 Provenance │ L4 Semantics │ L3 Relationships │
├──────────────────────────────────────────────────────────┤
│ Plane A: The Artifact (What a unit of knowledge is) │
│ L2 Identity │ L1 Repr │ L0 Substrate │
└──────────────────────────────────────────────────────────┘
These three planes are planes of concern, not a strict linear execution sequence. Lower planes define what a unit of knowledge is. The middle plane defines how units relate and carry shared meaning. The top plane defines how an agent queries, retains, and calls those units at runtime.
2. The nine layers across three planes
Plane A: The Artifact (what a unit of knowledge is)
L0 · Substrate (Storage and versioning)
Where bytes live and how change is tracked over time.
- Formal past: Native XML databases (XQuery engines) and dedicated triple stores (Jena, Virtuoso). These provided durable transactional guarantees, but required dedicated database servers before anyone could write a note, and diffing was hostile to humans.
- Agentic reboot: The filesystem plus git, complemented by embeddable key-value engines (such as Badger KV in Dgraph or BoltDB in Cayley), SQLite, Postgres, or cloud data warehouses for scaled storage. Git provides branch distribution, human diffs, and audit logs at zero infrastructure cost. Flat folders lack transactions and native indexing at scale.
L1 · Representation (Encoding)
How a single unit of knowledge is structured.
- Formal past: RDF/XML, Turtle triples, and OWL ontology documents. These were machine-precise and self-describing, but verbose and unreadable in code reviews.
- Agentic reboot: Markdown paired with YAML frontmatter. Readable by humans and agents, editable in any editor, and easily parsed with standard libraries. The Open Knowledge Format (OKF) operates here, adding just enough frontmatter structure to be machine-actionable while remaining plain markdown.
L2 · Identity (Naming and addressing)
How a unit is referenced across time and space.
- Formal past: Dereferenceable URIs and IRIs, along with XPath addressing. Global, stable identifiers formed the foundation of Linked Data, though minting and URI lifecycle management created organizational friction.
- Agentic reboot: Relative file paths, wikilink stems, and embedding chunk IDs. In OKF, a concept ID is the file path minus
.md. File paths are intuitive and free to create, but fragile when files move or get renamed.
Plane B: The Graph (how units relate and mean)
L3 · Relationships (Edges between units)
How connections between individual units are expressed.
- Formal past: Typed RDF triples with explicit subject-predicate-object grammar, OWL object properties, and Gremlin traversals over property graphs. Graph engines like Cayley demonstrated how to model typed quads (subject-predicate-object-label), while Dgraph introduced directed edges with key-value facets. Edges were first-class, typed entities. Defining strict predicate vocabularies up front introduced heavy friction.
- Agentic reboot: Markdown links,
[[wikilinks]], and bundle-relative OKF links. Edges emerge naturally during writing. The trade-off is that links are untyped; surrounding prose conveys relationship meaning rather than a machine-readable predicate.
L4 · Semantics (Taxonomy and ontology)
How types, categories, and hierarchies share agreed meaning.
- Formal past: OWL description logic, SKOS taxonomies, and schema.org vocabularies. This layer was the past's largest overshoot: full description logic reasoners demanded deep modeling before delivering practical value.
- Agentic reboot: Free-text tags, open
typefields in frontmatter, andAGENTS.mdinstruction files acting as ontology-in-prose. This approach is zero-friction and grows bottom-up, but lacks machine-checkable shared semantics. JSON-LD@contextwith SKOS (broader,narrower,related) provides a lightweight bridge, letting flat tags opt into hierarchy without requiring OWL logic engines.
L5 · Provenance (Trust, credibility, and lineage)
Recording where knowledge originated, how it was generated, and whether it remains verified.
- Formal past: The W3C PROV-O model (
Entity,Activity,Agent), named graphs, and XML signatures. Rigorous and portable, yet rarely used outside specialized domains because it depended on the RDF stack. - Agentic reboot: Mostly absent. Flat markdown folders, vector pipelines, and typical memory engines strip provenance. OKF v0.2 makes this layer its centerpiece: mandatory
generatedstamps, explicitsources, and derived trust tiers that are calculated from signals rather than stored as arbitrary scores.
Plane C: The Runtime (how an agent uses memory)
L6 · Retrieval (Lookup and indexing)
How an agent locates relevant knowledge during execution.
- Lexical lookup: Ripgrep and full-text indexing over local markdown files.
- Vector lookup: Embedding models (
gemini-embedding-2), pgvector, and managed vector stores for semantic similarity search. - Graph lookup: Declarative graph queries across BigQuery or Spanner Graph via ISO-GQL, native GraphQL and DQL in Dgraph, Gizmo graph traversals in Cayley, or property graph engines.
L7 · Lifecycle (Recency, consolidation, and forgetting)
Policies governing memory persistence across sessions.
- Formal past: Bitemporal database tables tracking valid-time versus transaction-time.
- Agentic reboot: Memory consolidation pipelines (such as Zep or Graphiti) providing temporal graphs with invalidation timestamps, alongside Mem0 memory extraction. OKF participates declaratively via static
status(draft,stable,deprecated) andstale_aftertimestamps, leaving dynamic forgetting policies to runtime hosts.
L8 · Interface (Protocols and affordances)
How an agent interacts with memory tools and navigates context.
- Formal past: HATEOAS (hypermedia as the engine of application state) and SPARQL endpoints. The core hypermedia insight was elegant: the server hands the client resources containing affordances for what it can do next.
- Agentic reboot: The Model Context Protocol (MCP), Agent Skills, and markdown link navigation. When an agent reads a markdown document and follows links or invokes tool affordances, it executes HATEOAS principles without the historical WS-* or RDF complexity.
3. The placement matrix
An artifact in a modern agent architecture rarely lives in only one layer. The matrix below maps where common artifacts natively reside, where they participate optionally, and where they project into other layers.
Legend: ● = native layer · ◐ = optional or partial participation · → = projects into that layer.
| Artifact | L0 Substrate | L1 Repr | L2 Identity | L3 Rel | L4 Semantics | L5 Provenance | L6 Retrieval | L7 Lifecycle | L8 Interface |
|---|---|---|---|---|---|---|---|---|---|
| Plain markdown file | ◐ (git) | ● | ◐ (path) | ◐ (links) | – | – | – | – | – |
| Wiki tags / folksonomy | – | – | – | – | ● (tags) | – | ◐ (facet) | – | – |
| Wikilinks and backlinks | – | – | ◐ | ● | ◐ | – | ◐ | – | – |
CLAUDE.md / AGENTS.md |
◐ (git) | ● (md) | – | – | ◐ (prose) | – | – | – | ● (context) |
| OKF bundle | ◐ (git) | ● | ● (concept ID) | ● (links) | ◐ (type) |
● (trust) | →L6 (graph export) | ◐ (stale_after) |
→L8 (MCP) |
JSON-LD @context |
– | ◐ | ● (IRIs) | ● (typed) | ● (SKOS) | ● (PROV-O) | – | – | – |
| RDF / OWL | ◐ (store) | ● | ● (IRIs) | ● (typed) | ● (ontology) | ◐ (graphs) | ◐ (SPARQL) | – | ◐ (LDP) |
| Vector store | ● (index) | – | ◐ (chunk ID) | – | – | – | ● (vector) | – | – |
| Cayley | ● (embeddable) | – | ● (quads) | ● (typed quads) | – | – | ● (Gizmo / graph) | – | ◐ (HTTP / REPL) |
| Dgraph | ● (Badger KV) | – | ● (UIDs) | ● (predicates + facets) | ◐ (GraphQL schema) | – | ● (GraphQL/DQL) | – | ● (GraphQL API) |
| Zep / Graphiti | ● (KG) | – | ● | ● (typed) | ◐ | ◐ | ● (graph) | ● (temporal) | ◐ (MCP) |
| Property graph (Spanner/BigQuery) | ● (DB) | – | ● | ● (typed) | ◐ | ◐ (props) | ● (GQL) | ◐ | ◐ |
Reading down a column shows where tooling is concentrated. Retrieval (L6) and Interface (L8) have high tool density. In contrast, Provenance (L5) is sparsely populated in the agentic reboot outside OKF and formal semantic models.
4. Where OKF and binder sit (and the limits of the markdown truce)
A common misconception is treating OKF as a graph database engine. OKF operates at a different, foundational set of layers:
- OKF natively anchors L1 (representation), L2 (identity), L3 (relationships), and L5 (provenance). Provenance is its most formal contribution: it enforces
generatedattestation, records source citations, and derives trust tiers without inventing unverified credibility scores. - OKF partially covers L4 (semantics): Free-text
typeand tags provide folksonomy by default. Mapping to SKOS via JSON-LD allows optional, lightweight taxonomy. - OKF projects upward into L6 (retrieval), L7 (lifecycle), and L8 (interface). It is not a query engine or a runtime daemon. Instead, tools like binder generate graph exports (dot, graphml, json) for L6, validate
stale_aftermarkers for L7, and expose stdio tools throughbinder mcpfor L8.
Files as an I/O primitive, not a final destination
In binder and OKF, markdown files are treated as the source of truth. That design choice is an ad hoc, pragmatic truce with how today's agent harnesses operate, not an immutable law of memory architecture.
Because current agents run as CLI tools and IDE extensions in terminals, the filesystem is the universal lowest-common-denominator I/O primitive. Markdown plus git gives human auditability, diffing, and zero-infrastructure portability across different agent harnesses at zero runtime cost.
In a future where agents run on persistent memory fabrics, live event logs, or distributed graph databases, that arrow could invert: the graph or event log becomes the operational source of truth, and markdown becomes a downstream projection generated for human review. For today's terminal-driven workflows, anchoring knowledge in files is the practical compromise that keeps agent memory portable without requiring a dedicated database cluster before you can store your first note.
5. What to reintroduce, and what to leave behind
The goal of this nine-layer model is practical: identifying which ideas from the formal past improve agent reliability today, and which ideas were self-inflicted friction.
Reintroduce Now Adopt via Projection Leave in the Past
─────────────── ──────────────────── ─────────────────
• SKOS taxonomy (L4) • ISO-GQL Graph Queries (L6) • Full OWL Reasoning (L4)
• PROV-O alignment (L5) • Vector sidecars (L6) • Mandatory Global Registries (L4)
• Stable Concept IDs (L2) • RDF/XML as source files (L1)
• HATEOAS via MCP + links (L8) • Native Triple Stores (L0)
Reintroduce now (as lightweight additions)
- Lightweight taxonomy via SKOS (L4). Full OWL ontologies were an overshoot, but SKOS concepts (
broader,narrower,related) provide clean hierarchy without requiring description logic reasoners. In binder, taxonomy inference can suggest these relationships deterministically from directory structures and link density. - Provenance alignment via PROV-O (L5). OKF's
sources,generated, andverifiedfields map directly onto PROV-O semantics (Entity,Activity,Agent). Aligning them standardizes lineage without adding authoring burden. - Stable concept identity (L2). Pure file paths break when directories are reorganized. Adding stable identifiers that survive file moves solves the exact fragility URIs addressed, while keeping paths as human-friendly aliases.
- Hypermedia affordances (L8). Markdown links paired with MCP tools provide the navigation model HATEOAS originally envisioned, without requiring complex hypermedia protocols.
Adopt via projection (for scale and traversal)
- Declarative graph queries and local traversal engines (L6). Do not build a custom query engine into markdown tools. Project markdown bundles into local graph engines like Cayley or Dgraph for immediate sub-millisecond workspace traversals, or into BigQuery and Spanner Graph when a corpus grows large enough to benefit from enterprise ISO-GQL traversals.
- Vector search sidecars (L6). Store embeddings outside the authoritative knowledge bundle as derived, model-pinned index files.
Leave in the past
- Full OWL description-logic reasoning. Demanding complete ontological consistency before saving documents halts practical workflows.
- Mandatory global schema registries. OKF succeeds because consumers tolerate unknown types. Central registries recreate administrative bottlenecks.
- RDF/XML as primary source representation. Filesystem markdown with YAML frontmatter won representation on human readability, version control ergonomics, and tool compatibility.
By treating agent memory as a stack of distinct concerns, teams can build systems that remain simple to author, resilient in CI pipelines, and rich enough for complex agent reasoning over time.
Further reading
- The Open Knowledge Format Ecosystem: A Field Guide — the tools, viewers, and libraries growing around OKF v0.2.
- Best Practices with binder: When to Reach for the CLI, Skills, or MCP — hands-on ingestion, validation, and surface selection for OKF bundles.
- Agent Experience: Software for Agents — designing software interfaces that agents consume directly.
- Deciding What to Automate — applying DeepMind's intelligent delegation framework to agent autonomy.