From Relational Schemas to a Memory Model for Agents

A work-in-progress framework. The relational model and entity-relationship design gave software a way to model a world so a machine could use it. Agents need an equivalent, and it is not a table. This is the memory model I have been building toward, in stages, and how it applies to our own engineering team.

TL;DR

I am proposing a framework, and I want to be honest that it is still a work in progress: a memory model for agents that plays the role the relational model and entity-relationship design played for software. A way to model a world so the machine can use it.
Relational design and agent-memory design are the same discipline (model the entities, relationships, and constraints of a domain) aimed at a different consumer with a different objective.
The consumer changed: from a deterministic query planner to a stochastic, multimodal reasoner under a bounded, costly context window. So the objective flips from "normalize for storage integrity" to "deliver the most task-relevant signal per token."
The data changed too. Relational modeling handled structured data and treated text as a second-class blob. Agents work natively in unstructured, multimodal space, where meaning is geometric, not symbolic.
I did not derive this model from theory. It emerged in stages: summarization, then reusable governance, then atomic memories, then schema-enforced properties, then long-form documents as memories, then a graph layer. Each stage added a modality.
The new normalization is choosing, per piece of knowledge, what to crystallize into a typed property and what to leave as embedded prose. Write-time extraction is the bridge: one write produces both.
The worked example is an "engineering memory" schema for developers and AI agents, dogfooded across sessions, cron jobs, and deploys.

For forty years we had a shared way to answer one question: how do you model a world so software can use it? You drew the entities, the relationships between them, and the constraints that keep them honest. Codd gave it math, Chen gave it diagrams, and a generation of engineers internalized it so deeply that "design the schema" became a reflex. The relational model was not a database feature. It was a modeling discipline.

Agents do not have that yet. We have vector stores, retrieval tricks, and a lot of prompt glue, but not an agreed way to model a domain so an agent can use it well. Agent memory is to AI agents what the relational model was to software: the discipline of modeling a world so the machine can use it. That is the claim of this piece, and I want to be upfront that the framework is a work in progress. I did not arrive at it from theory. I arrived at it by building, one missing capability at a time.

The consumer changed, so the model has to change

For four decades we modeled the world for one kind of reader: software that asks exact questions and expects exact answers. You decomposed reality into typed columns, normalized away redundancy, and the database returned precisely the rows that matched your predicate. The reader was deterministic. The contract was ACID. The world was closed: if it was not in a column, it did not exist for the query.

The reader is different now. An agent is a stochastic reasoner with a small, expensive working memory (the context window) and a native fluency in unstructured, multimodal data. It does not issue SELECT ... WHERE. It asks, in effect, "what do I need to know to do this well," and something has to answer that without blowing the token budget or hallucinating relevance.

That single shift, the change of reader, is what forces a new data model. The modeling discipline carries over almost entirely. The objective function does not.

What relational modeling gave us, and what transfers

Strip away the tables and relational design was never about tables. It was about modeling a domain: its entities, the relationships between them, and the constraints that keep it honest. That part transfers directly to agents:

Entities, keys, and relationships become entity types, identity keys, and relations.
Integrity constraints and stored procedures become the governance layer: the rules every agent must follow.
Indexing and query planning become retrieval: the same latency and cost tradeoffs, a different mechanism.
The read model versus write model split (CQRS) becomes write-heavy ingest plus read-optimized recall.

So if you know how to model a world for software, you already know most of how to model one for agents. The on-ramp is real. The cliff is what comes next.

How the model emerged, and why it is still a work in progress

I want to show the seams, because the framework did not arrive whole. It accreted, and each layer was a response to a concrete failure of the previous one. The order matters, because it is the order of increasing fidelity to how knowledge actually behaves.

Summarization. The first instinct, and the weakest. Compress the history into a paragraph the agent can read. It helps, but a summary is lossy and frozen: it answers the question you compressed for, and nothing else.
Reusable governance and policy. The next thing I noticed was that the most valuable, reusable context was not facts about an entity, it was the organization's rules: brand voice, pricing policy, how we qualify a lead. Those belong in a shared, routable layer that every agent reads, not pasted into one prompt. This is the governance half of the model, and it is what keeps a fleet of agents consistent. (More in Retrieval, Memory, and Governance Are Three Different Problems.)
Atomic memories. Summaries gave way to atomic, self-contained facts extracted from content and retrieved by similarity. Open-set, schema-free, comprehensive. This is the modality most people mean when they say "agent memory." (See Dual Memory.)
Schema-enforced memories. Atomic facts are great for recall and terrible for anything a downstream system needs to filter, aggregate, or act on. So I added typed properties: a schema designed for AI to populate, where each property carries a type, examples, and extraction hints. (See Schema-Guided Extraction.)
Long-form documents as memories. Some knowledge is bigger than a fact and smaller than a database: a deal review, a playbook, an audit trail. Agents want to write sectioned markdown and revise it in place, the way they keep their own notes. So documents became a first-class modality on the same substrate. (See Documents Are Memories Too.)
Graph. Finally, relationships. A CRM is a graph nobody wrote down. Edges between records, declared or inferred, turn isolated entities into a connected world an agent can traverse. (See The Three Channels of Graph Writes.)

Read that list as a single arc: from a lossy paragraph to a multimodal, governed, connected model of a domain. None of these replaced the one before it. They compose. That is why I think it is a model and not a bag of features, and also why I keep calling it a work in progress: each version taught me what the previous one could not hold.

The real break from relational thinking: structured columns versus native meaning

Here is where the analogy to relational design stops being a comfortable on-ramp and starts being instructive by contrast.

Relational modeling is symbolic and explicit. You commit reality to discrete typed fields before you store it, and you retrieve by exact match over those fields. Unstructured content (a transcript, an image, a recording) was a TEXT or BLOB you could store but not query by meaning. Structured data was the first-class citizen, and everything else waited at the door.

Agents invert this. Their native substrate is unstructured and multimodal: text, images, and audio collapse into vectors in an embedding space, and meaning becomes geometric. "Find me things like this" is a distance computation, not a join. Meaning stopped being which column you are in and became where you land in vector space.

This is not a metaphor. It is the difference between symbolic and sub-symbolic representation, and the honest name for a system that uses both is neuro-symbolic. It also expands what "data modeling" even means: embeddings unify modalities into one searchable space, so the model now reaches natively into images, diagrams, and voice. You can ask for "the call where the customer sounded frustrated" or "diagrams like this one." Relational modeling had no native verb for that.

How agents find what they need, natively

The seductive answer is "embed everything and do semantic search." It fails, and it fails in ways that matter:

It cannot enforce exact constraints (status = active AND owner = X).
It cannot do negation ("the incidents we did not fix").
It cannot aggregate, count, or order by recency reliably.
It returns what is plausible, not what is correct.

The working answer is fusion across three retrieval modes:

Sub-symbolic: vector search over embedded, multimodal content. "What is relevant?"
Symbolic: structured filters and joins over typed properties. "Which of those actually qualify?"
Graph: relation traversal across entities. "What is connected to this?"

And one thing the relational world never had: the query itself is authored by the agent from intent. The agent reads the task, decides which mode to use, fuses the results, and reranks. Retrieval becomes a conversation, not a single statement. (More in Retrieval Is a Conversation.)

The new normalization is choosing the boundary

Normalization in the relational era meant eliminating redundancy to avoid update anomalies. The agent-era equivalent is a different decision, made per piece of knowledge:

What do you crystallize into a typed, filterable property, and what do you leave as embedded prose or a document?

Crystallize the high-frequency, filter-on, governance-critical, aggregatable facts into properties. They are cheap, exact, and machine-readable: the symbolic layer.
Leave the long-tail nuance, the narrative, the "why" as atomic memories or documents. They are rich and semantically retrievable: the sub-symbolic layer.

The bridge between them is the most important mechanism in the whole framework: write-time extraction. The same raw input is embedded as-is for semantic recall and, in the same pass, projected into the structured schema, where each property's description doubles as the extraction prompt that tells the model what to capture. One write, multiple representations, all retrievable. Relational modeling has no equivalent of a column definition that reads the prose and fills itself in. (See Three Modalities, One Save.)

A related finding kept me honest about not over-feeding the agent: output quality saturates at roughly seven well-selected memories per entity. The bottleneck is curation, not capacity. (See Seven Memories Per Entity.) The model is not "store more." It is "model well, then select tightly."

A worked example: modeling our own world

Theory is cheap, so we modeled a world we know intimately and run every day: software development, done by a mix of human developers and AI agents (Claude Code, Codex, and others) across many sessions, plus agents triggered by cron jobs and deploys. The problems were the ones every engineering team has. Learnings lived in one person's head or one agent's local memory and were never shared. Feature work was inconsistent because nobody recalled the same context. Knowledge evaporated between sessions.

The fix was to design the database-equivalent of that world as an installable schema. The entities are the durable nouns of engineering:

module        a subsystem: what it owns, its danger zones, its gotchas
initiative    a unit of work across sessions and PRs: status, owner, a
              claimable task queue, a cross-session timeline, learnings
contributor   a developer or an AI agent: role, expertise, working style
decision      an architectural choice with its rationale (an ADR)
incident      a postmortem: symptom, root cause, fix, prevention
release       a deploy: what shipped, whether it was verified, what it broke
monitor       a persistent watch condition (drift checks, risks) with status
dependency    an external package or service with its advisory status

Every record carries multiple modalities from a single write. The typed side (an incident's severity, a decision's status, a release's environment) is the symbolic layer you filter and aggregate on. The free-text side (a module's gotchas, a decision's rationale, an incident's root_cause) is the sub-symbolic layer you recall by meaning. The initiative's living context and append-only updates are the document and timeline modality. And the relations are the graph that lets an agent reason across them:

initiative  touches      module
incident    occurred_in  module
incident    fixed_in     initiative
decision    affects      module
release     includes     initiative
release     introduced   incident
monitor     watches      module

Now the questions an engineering team actually asks become single retrievals. "What bit us in the billing module before I change it?" is a graph traversal plus a semantic recall over root causes. "Which initiatives shipped in the last release, and did any introduce an incident?" is a structured filter plus two relation hops. "What did the other agent learn here on Tuesday?" is a read of the initiative's cross-session timeline. The schema, not a human's memory, holds the answer.

The same design also solves coordination, which people underestimate once multiple agents run in parallel. Each initiative has an assignee and a status: an agent claims work before acting, and other agents skip what is already claimed. That one structured field is the difference between a team of agents and a pile-up of agents.

Maximum value, lowest cost

The structured-versus-unstructured boundary is not only a correctness decision. It is the cost lever, because the two layers have opposite economics. Structured properties are cheap to carry and precise to query. Unstructured memory is expensive to carry (it spends tokens) and fuzzy to query. So the optimization is concrete:

Carry the small, dense, structured layer in context almost always.
Retrieve the rich, unstructured layer on demand, in tiers (a cheap scout pass first, an expensive deep pass only when needed).
Compress with summaries and digests, which are the materialized views of agent memory.
Extract once at write time and read many times, so you amortize the expensive interpretation step.
Use governance so agents do not re-derive what the org already decided.

This is CQRS, materialized views, caching, and compression, applied to an LLM's working set. The same engineering intuition the relational world spent decades refining, pointed at a new bottleneck: not disk, but the context window. As one illustration, when we moved structured filtering off a vector store's secondary index and onto a relational store with a proper index, queries that were timing out at 30 seconds came back in under half a second. The lesson was not "relational beats vector." It was "use each layer for what it is good at."

The craft is choosing the boundary

Relational modeling asked how to project the world into structure so software could query it exactly. The memory model keeps the world in its native, multimodal form and projects just enough into structure, then retrieves across both. The craft is choosing the boundary, per piece of knowledge, under a cost budget.

I do not think this framework is finished. The relational model took years and many hands to become canonical, and it earned that status by organizing what practitioners already did into something teachable. I am trying to do the same for agents, in the open, while still building it. If you already think in schemas, you are most of the way there. You just have a new reader to design for: one that thinks in vectors, reasons under uncertainty, pays by the token, and will only ever be as good as the world you modeled for it.

Frequently Asked Questions

Is "memory model" a real framework or just a nice analogy? It is a working framework, and it is honestly still evolving. It has concrete parts (atomic memories, typed properties, documents, a graph, a governance layer, write-time extraction, tiered retrieval) that are built and deployed, and it has a clear design question at its center: what do you model as structure versus leave as native unstructured content. I am presenting it as a work in progress on purpose. The relational model became canonical by organizing practice, not by being declared.

Isn't this just a vector database with extra steps? No. A vector database is the index for the sub-symbolic layer. It is one of three retrieval modes, and on its own it cannot filter exactly, negate, aggregate, or traverse relationships. The contribution is the model: which modality holds which knowledge, the governance over it, and the write-time extraction that produces several representations from one write.

Why not just embed everything and let retrieval sort it out? Because embedding-only retrieval returns what is plausible, not what is correct, and it has no answer for exact constraints, counting, recency, or negation. You also pay for that fuzziness in tokens at read time, forever. Crystallizing the predictable, queryable facts into typed properties makes retrieval both cheaper and more precise.

Does the relational analogy actually hold, or is it just framing? It holds for the modeling discipline (entities, relationships, constraints) and for the engineering patterns (CQRS, materialized views, caching). It breaks on the fundamentals: agent retrieval is probabilistic and open-world, not deterministic and closed-world. The honest version uses the analogy as an on-ramp and is explicit about where it ends.

Where did you prove this on yourselves? The engineering-memory schema above is dogfooded: developers and agents recall it at the start of a session and write back to it at the end, cron jobs read and update monitors, and deploys write release records. Modeling your own world first is the fastest way to feel every gap in the model.

Companion pieces: The Four-Layer Architecture Behind Governed Memory, Dual Memory, Documents Are Memories Too, The Three Channels of Graph Writes, and Seven Memories Per Entity.