In June 1970, Edgar Codd, a researcher at IBM, published a paper called "A Relational Model of Data for Large Shared Data Banks." His managers were not thrilled. IBM's flagship database product at the time, IMS, was hierarchical, and Codd's tables threatened it directly. The paper stirred a genuinely virulent internal debate, and it took most of a decade before relational databases were taken seriously in production.
Then something quiet and total happened. "Design the schema" became a reflex. A generation of engineers grew up unable to imagine building software any other way: you draw the entities, you draw the relationships, you normalize. The discipline got so deeply internalized that it turned invisible. We stopped calling it a discipline and started calling it "how data works."
The relational model was never really a database feature. It was a modeling discipline for a particular kind of reader. That reader was a deterministic query planner: ACID-compliant, literal, indifferent to nuance, and constrained above all by disk space. You normalized to avoid storing the same byte twice, because bytes were the scarce thing.
That reader just changed. And almost nobody has updated the discipline.
Three scenes from the transition
Scene one. A developer spins up a vector store, embeds the entire CRM, and wires it to an agent. The demo is beautiful. Ask about a customer and the agent surfaces relevant notes, past tickets, the shape of the relationship. Then someone in the room asks a real question: "Which of our active enterprise customers are overdue for renewal?" The agent confidently returns five names. Two of them churned last quarter. One is a free trial. The agent has no idea what "active" means as a constraint, no way to compare a renewal date against today, no concept of "enterprise" as a property you can filter on. It found the text most similar to the question. Similarity is not correctness.
Scene two. A company runs three agents in parallel: one handles support, one runs outreach, one processes renewals. A customer writes in furious about a billing error. The support agent starts drafting an apology. At the same moment, the outreach agent, which knows nothing about the open ticket, fires off an upsell email. And the renewal agent, seeing a contract about to expire, sends an automated renewal notice. Three agents, one customer, the same thirty seconds, no shared state. This is the failure mode people don't see coming. It isn't a wrong answer. It's a coordination collapse, and it scales with the number of agents you deploy.
Scene three. Codd's engineers, circa 1978, arguing that relational databases would never be fast enough for real workloads. They were right about the performance and wrong about the direction. The constraint they were optimizing for stopped being the constraint that mattered.
That is exactly where we are with agent memory.
The reader changed, so the objective flips
The old reader optimized for disk. The new reader is a stochastic, multimodal model reasoning inside a context window that is both bounded and expensive. Tokens are the new disk space.
Not metaphorically. Even after Anthropic dropped its long-context surcharge in March 2026, filling a one-million-token window still ranges from cents to roughly ten dollars per call depending on the model, and output tokens run about 4x input at the 2026 market median. Attention cost grows quadratically with sequence length, so a giant prompt is not just a bigger bill; it is a slower, noisier reasoning surface. The scarce resource is no longer storage. It is the model's attention.
So the objective inverts. You no longer normalize to save bytes. You curate to maximize signal density per token. Every fact you load into context has to earn its place against the fact you didn't load. That is a modeling problem, and it is the one nobody was trained for.
Four ideas at altitude
Here is the shape of the discipline, stated plainly. Each of these has a deeper piece behind it.
One: "embed everything" is a trap. Vector search returns what is plausible, not what is true. It cannot enforce an exact constraint (status = active AND owner = X), cannot express a negation ("incidents we did not resolve"), and cannot aggregate or count reliably. Agents need three retrieval modes, not one: sub-symbolic (vector similarity), symbolic (structured filters), and graph (relationship traversal). This is why RAG makes a poor memory on its own, and why retrieval works better as a conversation than as a single similarity lookup.
Two: the new normalization is choosing the boundary. For every piece of knowledge you decide, deliberately, whether to crystallize it into a typed property (cheap, exact, filterable) or leave it as embedded prose (rich, semantic, retrievable). Most systems pick one and suffer. You want both a free-text layer and a typed-property layer, with write-time extraction as the bridge: one save produces both representations at once, so three modalities collapse into one save surface.
Three: capacity is not the bottleneck; curation is. In practice, answer quality saturates fast. Past roughly seven well-chosen memories per entity, more retrieved context tends to hurt more than it helps. The 2026 memory benchmarks make the same point from the other side: the best LongMemEval systems win on precise extraction and temporal reasoning, not on how much they can cram into the prompt. Selection beats volume.
Four: this is a schema you are designing, whether or not you admit it. The teams shipping agent memory in 2026, Letta treating context like an operating system paging between RAM and disk, Zep giving every fact a valid_at and invalid_at so you can ask what was true on Wednesday, are all rediscovering entity-relationship modeling for a probabilistic reader. The full mapping from relational schemas to a memory model for agents is the deep version of this piece.
The reflex we haven't built yet
Codd's contribution was not tables. It was giving engineers a disciplined way to think about data independent of how a machine would read it. The reflex he created, "model the entities and their relationships first," survived every hardware generation since.
We need that reflex again, aimed at a different reader. The question is no longer "how do I store this without duplication." It is: what does this agent need to know about the world, in what form, retrievable in what way, at the smallest cost to its attention. That is a modeling discipline. It deserves a name, and it deserves the same seriousness we once gave the schema.
Right now most teams are still in 1971, embedding everything and hoping. The engineers who internalize the new discipline first will build the agents that don't send an upsell email to a furious customer.