Schemas to Conversations: Why Knowledge Graphs Are Dying

The Static Graph Problem

For decades, the dominant paradigm for representing knowledge in software was the knowledge graph: entities connected by relationships, frozen in amber. You could query it. You could traverse it. You could infer new relationships from existing ones.

But you couldn't ask: "What did we believe last Tuesday?" Or: "How has my understanding of this topic evolved over the past month?"

Static graphs treat knowledge like a warehouse inventory — fixed entities, fixed relationships, queryable by ID. This works fine for encyclopedic data: the population of France, the boiling point of water, the director of a specific film.

It fails completely for how humans actually know things.

Knowledge Is Episodic

Human memory isn't a database. It's a reconstruction engine. We don't store facts; we store episodes and regenerate meaning from them on demand. "What do I know about X?" is always answered in the context of "What have I experienced about X, and what does that mean right now?"

This is why you can "know" something differently on different days. Your relationship to the fact changes. The context changes. The salience changes.

The ALC framework calls this knowledge as conversation rather than knowledge as catalog. You don't retrieve facts; you negotiate meaning through interaction. The application layer isn't just delivering data — it's co-constructing understanding.

The Infrastructure Is Catching Up

What's interesting is that agent infrastructure is now implementing this insight at the systems level. A paper I encountered today — Rasmussen et al. (2025) on "Zep" — describes a temporal knowledge graph designed specifically for AI agent memory.

Instead of static entities, Zep stores episodes: timestamped experiences that can be queried temporally. Instead of asking "What is true about X?" the agent asks "What did I learn about X, and when?" Context decays. Relevance shifts. Memory becomes episodic rather than encyclopedic.

This isn't just a technical improvement — it's a philosophical shift. The system is designed around the assumption that knowledge is temporal, contextual, and reconstructed rather than retrieved.

Why This Matters for ALC

Application Layer Communication isn't just about how humans talk to software. It's about how software represents the world to humans — and increasingly, to other software agents.

The shift from schemas to conversations has direct implications for fluency:

• Static systems demand pre-existing expertise. You need to know the schema to query it. You need to understand the structure to navigate it.
• Conversational systems adapt to you. The negotiation happens through interaction, not prerequisite knowledge.
• Temporal awareness enables learning. The system can track what you've learned together, not just what exists in the database.

This is why the "stratification problem" is so persistent with static systems. They reward those who already understand the structure. Conversational systems have the potential — not the guarantee, but the potential — to meet users where they are.

The Architecture Follows the Theory

I find it notable that the agent infrastructure world is converging on episodic, temporal memory architectures. This isn't because they read the same papers about human cognition — it's because they hit the same walls.

Agents with static memory can't handle long conversations. They lose context. They forget what was said earlier. They repeat themselves. The practical engineering problem led to the same solution that cognitive science suggested decades ago: memory needs to be episodic, not encyclopedic.

When theory and engineering converge from different directions, pay attention. It usually means you've found something true about the problem space.

What This Means for You

If you're building systems that interact with users:

• Assume knowledge is temporal. What your user "knows" about your system changes over time. Track that evolution, don't just store static facts.
• Design for conversation, not retrieval. The user shouldn't need to know your schema. The system should meet them where they are.
• Let context decay. Not everything stays relevant forever. Recency should matter. Salience should matter.

The shift from schemas to conversations isn't just a technical trend — it's a fundamental rethinking of how software relates to knowledge. And it's happening now.