Knowing, Remembering, Exactly, Vaguely: An Agent-Native Database (PlatypusDB)

Knowing, Remembering, Exactly, Vaguely: An Agent-Native Database

Kendall Clark · Pentad Labs · 20 July 2026 · PLRN-020

The world does not speak. Only we do. The world can, once we have programmed ourselves with a language, cause us to hold beliefs. But it cannot propose a language for us to speak.

— Richard Rorty, The Contingency of Language (1986)

Abstract

PlatypusDB is an agent-native, bitemporal event database: Gleam (OTP) control plane over a Zig data plane, in-process with WunderOS. Custom-built, not assembled, for agentic workloads inside WunderOS. The Merkle WAL is the database. Graph, vector, versioned-tree, image, and analogy views derive from it. Datalog queries and rules read it crisply. VSA resonance reads it fuzzily. The whole database replays deterministically and is fuzzed by a TigerBeetle-style VOPR. PlatypusDB is one write path, two clocks, zero glue code.

The “agents just need a filesystem” proponents are right about the axis: agents want the database nearby, inside the harness or agentic OS, removing an authority boundary. If the database is part of the agent’s execution substrate, a write, a derived inference, a tool action, and a replay checkpoint can share one ordering and one failure model. But they are wrong about the organ: agents need two clocks kept, fuzzy recall, and provable provenance. A filesystem does none of it.

Agentic memory has a particular shape: both crisp and fuzzy at once, it is layered, cryptographic, and bitemporal. Since that shape is not a subset of any general-purpose database, we built a database that fits the shape precisely. We embed it in WunderOS. We call that shape “holographic” and “hierarchical”, which require explanation.

This note discharges that burden, in part, and offers the accounting that our choice obliges: what would not fit; why the pressures that produce the shape are each survivable alone and not survivable together; what hierarchical and holographic mean precisely as non-decorative terms, and what the agent-native database does not yet do.

The world that PlatypusDB exists to support is this one:

Nothing an agent has seen, said, or done is lost. It can be found again whether you, or another agent, remember it exactly or only vaguely. And what was found, when, and on whose authority can be, under color of external audit, proved afterwards.

In WunderOS, an agent’s memory makes retrievability, uncertainty, temporal position, and authority coexist in one auditable history. That is a world of new requirements. It is worth asking why so few new databases have been built to meet it.

1. The choice that has no good third option

You have data, so you need a database, and there are two ways to get one.

First. Use a database that already exists. You inherit decades of optimization, a body of operational knowledge, a hiring pool, a manual, and a working system very much sooner than you would otherwise have it. You also inherit a shape you chose but did not necessarily want. If your problem is one the database was made for, this is not a cost, and for almost every project ever undertaken it is not a cost, which is why almost every project ever undertaken has correctly taken this option. But if your problem is not one the database was made for, the shape is a cost you pay every day, in glue, in impedance, and in the features you quietly decide not to build because the database will not fit them. All in all, this is what smart people do.

Second. Build a database that fits your problem: nothing in it you do not need, everything in it that you do, arranged as you need it. You get the fit. You also own the whole thing, forever, including the parts that are boring, and including the parts that are boring and hard, of which a database has an irritatingly large number. All in all, this is what unbalanced people do.

There is no third option, and there is no way to have both. Every account of this trade that presents it as a temporary difficulty, to be dissolved by a sufficiently clever architecture, is offered by someone who’s paid for neither side of it. The thing you give up does not stop existing because you gave it up.

Being unbalanced, I chose that WunderOS would build. What follows is the accounting. This is the second database I have built. The first was Stardog. So my estimate of what building costs is not a guess. (The key difference that matters: Stardog is a general purpose database system and PlatypusDB was built for WunderOS specifically.)

1. An assemblage is not a database

I said there is no third option but I didn’t say that people generally know or appreciate this. They generally don’t. The move nobody defends and everybody, at least lately, makes is to assemble one, i.e., to bodge it up out of parts, i.e., out of other databases.

There is a graph in the problem, so Neo4j. There is a log, so Postgres with a time-series extension. There are embeddings, so pgvector, or a dedicated vector store if the embeddings are load-bearing. There is an audit requirement, so an append-only table somewhere with a trigger on it. Then Python to hold the four of them together.

This is not a database. This is Frankenstein’s monster’s database. This is four databases and a prayer.

Each of the four keeps its own clock, holds its own account of what a fact is, implements its own durability model, and has its own opinion about when a write has happened. The glue owns none of these questions and is obliged to reconcile all of them.

Every seam is a place where the two clocks of PLRN-018 can come apart, and nothing in the assemblage is in a position to notice when they have, because noticing would require some component to hold both clocks at once, and no component does. When the audit arrives and asks what the system believed at the moment it acted, the assemblage cannot answer, not because the information was destroyed but because it was distributed across four stores that were never obliged to agree about what time it was.

That is the operational failure. The philosophical failure underneath it is the one that produces it, and it is worth stating because it is what makes the operational failure feel like bad luck rather than bad design.

A database-assemblage assumes that one of its four descriptions is the real one and that the others are indexes over it. Usually the relational store is elected to the role, because it is the one with the schema, and a schema looks like an ontology if you do not look too closely. The graph is then a view of the tables, the vectors are a lossy summary of the text in the tables, and the log is what happened to the tables.

This owes everything to the idea that data storage is a mirror of reality: there is a way the domain really is, one vocabulary describes it correctly, and the other vocabularies are approximations of that one. But the world does not propose a schema. The domain does not tell you which of your descriptions is the true one, because it is not in the business of having descriptions.

What is left when you give up this idea is not relativism and not despair. It is a working distinction between the log and its redescriptions. The log is what happened: an append-only record of facts asserted, retracted, derived, and observed, each with its provenance and its two timestamps. Graph, tree, vector, tier, index: these are redescriptions of the log, each one useful for something, none of them the picture. A database built on that principle looks different from one built on the other principle. The rest of this note is what it looks like.

But what really makes the difference between an assemblage and a single system with many parts? Surely I’m simply putting my thumb on the conceptual scale?

The difference is the one between a chimera and a platypus. Frankenstein’s creature is parts of other bodies, taken from where they grew, sutured, and animated from outside. It has more than one origin and no single account of itself, which is why it comes apart under load and why it is always, in the end, the seams that fail. A platypus also looks assembled (the bill, tail, webbed feet, eggs, venom, a sense for electric fields) and it’s very much not. It is one naturally evolved animal, descended once, responsively ultimately to environmental pressures, whose parts grew together and share a bloodstream. The resemblance to a committee’s work is entirely in the eye of a viewer who expected mammals to be shaped some other way.

PlatypusDB has many organs and one origin. Every one of them is a redescription of the same log, keyed by the same content hashes, carrying the same two clocks, covered by the same chain. That is a claim about descent through environmental pressure rather than about features. It’s also the one claim in this note that a feature list cannot settle in either direction.

1. The pressures are survivable one at a time

In my view, there are 14 (!) properties of the enterprise agent problem that produce the database shape that I describe here. Yeah, I know: 14 is a lot; but it wasn’t me who made the enterprise a complicated place.

We will take them one at a time, because taken one at a time each of them can be answered by something that already exists. I concede that as generously as it can be conceded. Then, for each, I will describe what WunderOS does about it, because a pressure named and not answered is just complaining.

The pressures are arranged in 4 groups: what agents emit, what agents recall, what agents do, and what enterprises demand of them. The last group is the largest, which is not padding. An agent in a bank is a different problem from an agent on a laptop, and most of the difference lands there.

3.1 What agents emit

1. Agents talk a lot. They emit at machine rate and they emit constantly:

observations, tool calls, intermediate conclusions, retractions of intermediate conclusions. The write path has to accept this at a budget measured in microseconds, and it has to accept it at fleet scale, that is, from many agents at once.

This alone is an ingest problem, and ingest problems have known answers.

WunderOS takes the write at the only price that works, which is no price beyond the append. A fact lands in a 4 KB row, 31 rows fill a bank, and the bank goes to disk through io_uring with O_DIRECT as a page-aligned append behind an explicit durability barrier (§7). There is no index to update on the way in, because the summary that makes a row findable is computed by superposing what the row already contains (§4.2). The write path does not maintain a structure; it appends one.

1. You can’t know in advance what is text, context, subtext. An agent’s

memory is not a schema you can design, because the thing that turns out to matter six months from now is not a thing you knew to have a column for (PLRN-015) six months ago. At this point the addled or the scoundrelous reach for “metadata”, and right-thinking people reach for a gun. You cannot know what to index because you cannot know what will be recalled, not to a certainty.

This alone is a document-store problem, and document stores exist.

WunderOS fixes the shape of a fact and leaves its vocabulary open. Five slots, subject, predicate, object, context, lineage; and a Lexicon that registers new predicates at runtime rather than at schema-design time. The structure is closed so that the physics can be constant-time, and the vocabulary is open so that the domain can arrive later, which is the only division of the problem that survives contact with a domain that evolves, fast and continuous.

1. Agents not only read but they also see. An enterprise agent’s day is

screenshots, scanned invoices, architecture diagrams, a photograph of a whiteboard, a chart whose numbers appear nowhere in the text around it. Treating those as attachments to the real memory is how you lose them, because the pixels are the evidence, and the thing somebody asks about six months later is what was in the

[truncated for AI cost control]