The New Durable Primitive for Builders
Building got cheap. Owning what you built did not. Why retrieval is the new durable primitive — and why, like every primitive before it, you shouldn't build your own.
There's a new kind of person shipping software, and they don't always have an engineering title. We've started calling them builders. With an agent alongside them, a single person now builds things that used to need a team.
These things weren't impossible to build a few years ago. They were expensive. They needed people, time, and money, and most of them died in the gap between "someone could build this" and "we can afford to." Writing code stopped being the slow part, and that gap mostly closed. So more people build.
What a builder reaches for, though, is a toolkit that looks a lot like the one engineers have always used. Most of that toolkit they don't build. They adopt it.
The classic primitives
No one writes their own payments system. Not because they couldn't, but because payments is a primitive — the cost of getting it wrong is high, the work is the same for everyone, and a company called Stripe already carries that expertise so you don't have to. The same instinct sends a builder to an identity provider instead of a hand-rolled login.
A few things make something a primitive:
- Its state is irreplaceable. It accretes. Every user, every record, every accumulated decision adds to something you can't regenerate from scratch.
- Its correctness is adversarial or subtle. It doesn't fail loudly the moment you get it wrong. It fails later, quietly.
- It's cross-cutting. It touches everything, it's expensive to unwind once the system depends on it, and nobody wins by building their own.
The classic primitives are familiar: identity and access, the system of record, moving money, observability. The risk isn't that they're hard. It's that, with an agent, they no longer feel hard. An agent will produce a login flow or a billing path that looks finished. Treating that output as if the primitive were solved is how the cost shows up later as a liability instead of an asset.
The new primitive: retrieval
That set of primitives held for a long time. But the software being built on top of it just changed in one specific way: it thinks. And a thinking program needs something the classic toolkit doesn't provide.
Retrieval is that thing, and it didn't exist as a primitive a decade ago. It wasn't even there in the web3 wave. AI is what shined a light on it.
Retrieval used to be a human job. A person typed a query, read the results, and decided what was relevant. Now the agent does that, continuously, as part of work no one is watching.
It's worth being clear about how this differs from the database you already use. A database is where you keep information and look it up — you ask for something, and it returns the records that match. That's essential, and it's a primitive in its own right. Retrieval is a different job. Out of everything you've stored, it decides which information actually matters for the task in front of the agent right now — and in what order. It's less like looking something up and more like judgment.
This is the easy part to get wrong, because some tools look like they already do it. There are databases built to find things by similarity — to return what's closest to what you asked. While it's a step beyond matching exact words, the closest isn't the same as most relevant. A pile of things that resemble your question still isn't the answer to it. Deciding which few things matter for this specific step — weighing them, ranking them, judging them — is the work, and it's not what a tool built to store and fetch was built to do.
Which is why retrieval isn't a feature you add onto the database you already have. It's a primitive of its own, and a system that thinks needs an engine built around that judgment, not a place to store things that's been asked to approximate it.
That judgment is the whole game, because an agent only believes what it is able to retrieve. If the wrong thing comes back, the agent works from the wrong thing. Better retrieval is the difference between an agent that's useful and one that's confidently off. Better agents are downstream of better retrieval.
Retrieval has every trait that makes something a primitive. The context it draws on is accreted state you can't regenerate. Relevance is the subtle, quiet kind of correctness. And it touches every part of an AI feature. Yet most builders are still assembling it by hand, gluing together a few single-purpose services, treating it as something you construct rather than something you adopt.
Don't build your own
The lesson of every primitive before it holds here too: you don't build your own. No one writes their own payments system — building your own retrieval is the same bet, just made before the category has a name.
What that really changes is the job. Building used to be construction — you wrote the thing, and the writing was the slow part. The writing is cheap now, so the skill that's left is selection: knowing what to build and what to reach for. Let an agent own anything it could regenerate from scratch tomorrow without loss. Reach for a primitive everywhere else — identity, the system of record, moving money, observability, and now retrieval — because those hold the state you can't regenerate and the correctness that has to be earned over time. That expertise is worth buying instead of rebuilding.
Building got cheap. Owning what you built did not.
The builders who do well from here won't be the ones who generate the most code. They'll be the ones who, standing on the shoulders of primitives, take us to where we haven't been able to go before.