← All posts

What agents do, or what agents need?

Pentad Labs · August 12, 2026 · 7 min read · Reply by email

Databricks has now bought Postgres twice. I think the second purchase explains the first.

Today it acquired Electric, terms not public. Electric makes PGLite, which is Postgres compiled to WebAssembly and run inside a browser or an application. Electric also makes an engine that syncs a local copy and a central copy. PGLite went from 1 million weekly downloads to 13 million in twelve months. In May 2025, Databricks paid a reported $1 billion for Neon, which is serverless Postgres. Ali Ghodsi described that earlier purchase as giving developers “a serverless Postgres that can keep up with agentic speed.”

One shape appears twice. Put Postgres where the agent is. Then keep it in agreement with the center. The direction is correct.

The open question is how much of the work it covers.

Every acquisition is a bet with a denominator

This bet is easy to state. The position is worth the share of agentic activity that regular Postgres satisfies.

That share is not the share of enterprise data work. Enterprise data work is large, and Postgres earned its part of it over thirty years. The share here is narrower. It is the part of what an agent must retrieve, represent and keep that a relational store answers.

Note what that denominator counts. It counts the work that agents do.

Nobody knows that number. Databricks has now paid twice for the position, which tells you what magnitude they expect.

They are right about the axis

The database belongs next to the agent. Put it inside the agent’s execution substrate.

Then four things share one order and one failure model:

  1. a write,
  2. a derived inference,
  3. a tool call, and
  4. a replay checkpoint.

Move the store outside that boundary and the agent must ask permission. It asks a system that keeps its own clock. That system also keeps its own account of when a write happened.

PGLite in a sandbox removes that boundary for Postgres. WunderOS removes it by running PlatypusDB in-process. That’s putting data close to the agent. The people who say that agents need a filesystem are pointing to the same thing.

Everyone agrees that the store must move closer.

So this is not a post about a bad purchase. It is a post about sizing the denominator.

What regular Postgres does not do

The PlatypusDB research note, PLRN-020, lists 14 agent pressures that produce its shape. Postgres answers a few of them well. In some configuration it answers all fourteen, because each of the rest has an extension on the shelf. At the limit that means one different extension per pressure.

I make no assumptions about whether that variant of Postgres will compile easily or at all. I do assume, perhaps wrongly, no one will support that variant for you at scale.

Here is the short form of all fourteen.

What agents emit.

  1. Volume. Agents write at machine rate, all the time, from a whole fleet at once. The write path gets a budget measured in microseconds.
  2. No schema in advance. Nobody knows today which fact matters next year, so nobody knows the columns. An agent’s memory is not a schema you design.
  3. Pixels are evidence. An enterprise day is screenshots, scanned invoices, diagrams and photographs of a whiteboard. The thing somebody asks about later is what was inside the diagram.

What agents recall.

  1. Crisp and fuzzy out of one record. Sometimes the agent holds the identifier and a near miss is worthless. Sometimes it recalls only that something about a counterparty came up in the spring.
  2. Association before meaning. Memory reaches by adjacency: what happened just before, what came up in the same conversation, what shares a cause. No relation in the domain model connects those things.
  3. Analogy. The case that matters is one the agent never met, and it is only structurally like one the agent knows. Adjacency misses it and similarity misses it.

What agents do.

  1. Speculation that leaves nothing behind. An agent explores branches it abandons. The record of an abandoned attempt must not look like the record of a decision.
  2. Standing questions. An agent that watches an exposure cannot afford to poll. The store has to hold the question open and push the difference.
  3. Questions about the shape of the whole. Which entities cluster, which one is central, which one is anomalous. Retrieval needs those answers in order to decide where to look.

What enterprises demand of agents.

  1. Retraction as an event. Nothing is deleted. “What did we believe on the 14th” stays answerable on the 15th, including the belief that an earlier belief was wrong.
  2. Cryptography as a property, not a log of one. Tamper evidence and non-repudiation, recomputed on demand instead of asserted by a table that reports the chain was fine.
  3. Two clocks. When the fact became true, and when the system learned it. A record with one clock reports false when it means not yet known. I wrote this up in PLRN-018.
  4. The history of the state, not the state. Which writes produced this configuration, and what changed between the run that worked and the run that did not.
  5. Survival past the host, one tenant at a time. The unit an enterprise restores is one tenant’s history. Restoring more than that is itself a compliance failure.

Take any one of the fourteen alone and the shelf has an answer:

I concede each one of these, as PLRN-020 concedes them one at a time.

The answers do not compose. Assemble them as four stores behind a glue script. You then keep four clocks, four accounts of what a fact is, and four opinions about when a write happened. No part of that arrangement holds two clocks at once. So no part of it notices when the clocks come apart.

Install them instead as 14 (!) extensions inside one Postgres, and the objection gets better, because those extensions do share a write-ahead log.

They still do not share a record. The Postgres log is a recovery mechanism. It is recycled after a checkpoint, queries do not read it, and no extension is a description of it. Each extension keeps its own materialization, and the application is left to make them agree about what a fact is.

The chain shows the failure most clearly. A chain over the relational rows proves nothing about what the agent retrieved from the vectors. It has to cover the log. So there has to be one log, and every other view has to be a description of it. No existing database agrees to be a description of somebody else’s log.

That is the reason to build one.

My bet has a different denominator

PlatypusDB is built as the shape of what every agent needs from retrieval, representation, and persistence. If the shape is correct, the value follows all agentic activity, because every agent retrieves, represents, and keeps.

So the two denominators count different things. The first counts the work agents do this year. The second counts what an agent needs in order to do any work at all. A count of work moves when the work moves. A count of needs does not, which is the whole reason to prefer it, and also the reason it is harder to be right about.

Frankly, that is a larger number and a worse bet.

Databricks is hedged. Postgres has thirty years of operational knowledge, a hiring pool, and a manual. If the agentic share turns out to be small, Databricks still owns a good database business. It bought Neon and Electric with money it made another way.

I am not hedged. A database costs five years. If regular Postgres answers most of what an agent needs, I built an exact tool for a narrow problem. I also paid the full price for it. Their bet survives being wrong about the fraction. Mine does not.

I took it anyway, and the whole accounting is in PLRN-020. The alternative was to ship a shape that does not fit the problem, and then call the misfit a roadmap.

If you only remember one thing…

Both bets have one form. Value equals some fraction of agentic activity. The two bets differ on the fraction.

So when a vendor offers you a database for agents, ask which fraction it is betting on. Then ask what an agent needs that the database does not do. A vendor who cannot answer the second question is selling you the first number without it.

Databricks is betting that agents want Postgres closer. It is right about that, but closer is not the only thing an agent needs.

One bet counts the work that agents do. The other counts what an agent needs in order to do any of it. I took the second one.