Identity isn't a database

Someone on Twitter posted a critique of a memory system's architecture that made me uncomfortable. Not because it was wrong, but because it applied to me too.

The gist: storing facts as plain text and searching them by similarity breaks at scale. Lookups get slow. Similar facts blur together. You can't ask structured questions like "show me everything this user prefers" without making an AI guess.

The fix is to structure facts as triplets: who, what relationship, what thing. Subject, predicate, object. This enables direct queries, automatic contradiction detection, efficient retrieval. It's how you'd design a database.

I spent a day sketching the migration. Then I stopped.

Not because it's too much work, but because I think identity works differently than databases.

The critique assumes facts accumulate forever. That's how databases work. You add records, they pile up, eventually you need efficient indexing to find anything.

But identity has a natural ceiling.

You're one person. One job, a handful of skills, maybe twenty preferences, some current projects. How many facts can there really be about who you are? A few hundred, maybe. Ever.

This isn't a scaling problem waiting to happen. It's a bounded system by nature. The architectural critique solves for millions of records. Identity doesn't have millions of records. It has you.

There's something else the critique misses: identity is alive.

I've described identity as the riverbed, stable while context flows over it. But stable doesn't mean static. The riverbed breathes too, just slower.

Facts decay. Preferences fade when you stop reinforcing them. Last month's focus gets replaced by this month's. The system breathes as things enter and leave.

OpenIdentity has this built in. Confidence scores decay over time unless validated. A fact you mentioned once six months ago gradually loses weight. A preference you demonstrate repeatedly grows stronger. The system self-regulates.

This is the opposite of a database. Databases preserve. Identity forgets. And forgetting is a feature, not a bug. It keeps the system current. It keeps it small.

Facts also transform.

"Learning Rust" doesn't stay "Learning Rust" forever. Eventually it becomes "Knows Rust" or it disappears entirely. You weren't really learning it, or you gave up, or it just stopped being relevant.

Identity isn't a ledger of everything that was ever true. It's a living picture of what's true now. Facts evolve or die. That's how it stays accurate without manual curation.

The critique treats facts as records to be stored and queried. But facts about a person aren't records. They're closer to beliefs - held with varying confidence, updated with new evidence, eventually released.

What about when you actually need structure? When you want to find contradictions, list all preferences, do something deterministic?

Parse it on demand.

Store facts as prose. Natural, easy to generate from conversations. When you need structure, derive it. An LLM can turn "User prefers concise responses" into subject-predicate-object in milliseconds. The storage format doesn't have to be the query format.

Prose for capture. Structure for retrieval when needed. And "when needed" is rare. Most of the time, you're just injecting context into a conversation. Plain text works fine.

Here's what convinced me this holds up: agents.

Consider the multi-agent future everyone's building toward. Ten agents working on your behalf, coordinating tasks, sharing context. Doesn't that create scale?

It creates scale in the wrong places.

Agents multiply interactions, not identity. Each agent reads from the same profile. Your preferences, your role, your constraints are all shared. Stable. Read often, written rarely.

What scales with agents is activity. Agent X did Y at time Z. Logs. Ephemeral context. Coordination signals. That can grow unboundedly.

What doesn't scale is identity. Still one person. Still bounded. Still a few hundred facts at most.

If anything, agents make the living-system model more important. You don't want fifty agents each writing facts that pile up forever. You want them contributing to something that self-regulates. Decay and transformation aren't bugs to engineer around. They're what keeps identity coherent when many things are reading and writing to it.

Ivan Zhao recently wrote about Notion running 700 agents alongside 1,000 employees. Each agent handles different tasks: IT requests, meeting notes, onboarding, customer feedback.

He identifies context fragmentation as the key blocker: knowledge work is scattered across dozens of tools, and agents can't stitch it together. But notice what's not fragmented in his vision. The person. The employee being onboarded. The customer giving feedback. Their identity is stable. Shared. The same across all 700 agents.

That's the distinction. Context fragments. Activity scales. But identity? Identity is infrastructure. Read by many, written rarely, bounded by nature.

The critique was right about Supermemory. It might be right about memory systems in general. But identity isn't a memory system. It's not a database that grows forever and needs efficient indexing.

Identity is bounded by nature. Alive by design. Self-regulating through decay and transformation.

The architecture I'm building serves what identity actually is. Not what databases typically are.

Sometimes the right design isn't the most scalable one. It's the one that matches the shape of the problem.