Every “AI memory” product on the market right now is racing to do the same thing: store conversations, embed them, retrieve them, dump them into the next prompt. The companies building these products are competent. The space is real. The customer pain is real. But the entire category is converging on a primitive that becomes commodity in 2026 — and the people racing to win it are racing toward a finish line that isn’t there.
That’s not where the value lives.
The value lives one layer up. Not in what gets remembered. In what gets delivered, when, and how disciplined the cycle around it is.
This is a manifesto, so let me state the thesis plainly:
Memory is commodity. Just-in-time context engineering is the moat.
The rest of this post is the argument for why.
The race to commoditize memory
Look at any “AI memory” product release in the last twelve months. The pattern is identical. Store the user’s prior interactions. Generate embeddings. Build a vector index. Retrieve the top-k nearest neighbors when the user starts a new session. Inject those neighbors into the next prompt as recovered context.
It’s a real capability. It solves a real problem — the AI that helped you build something yesterday has no idea who you are this morning, and that’s an unacceptable user experience. The market is right to attack it.
But here’s what’s about to happen: every frontier lab and every major coding surface will ship memory within months. It will be table-stakes by year-end. Building a company around the primitive itself is building a company on the same ground a dozen well-funded competitors are about to flatten with their first-party features.
A primitive that every platform ships is a primitive that’s worth zero standalone.
This doesn’t mean memory is unimportant. It’s necessary. It’s just not sufficient — and it’s not where defensibility lives.
Why memory alone doesn’t move the floor
Here’s the part the memory-only frame misses.
Even with perfect retrieval, the model still has to figure out which memories matter for this turn. It still has to read a system prompt that bloats with every convention you’ve ever asked it to follow. It still has to spend reasoning tokens deciding what context it actually needs. It still has to issue tool calls to fetch context, and retry those calls when the first fetch was wrong. The session pays a tax on every turn — and the tax compounds across the length of the session, and across every session of your week.
Retrieval-of-stale-context is still expensive context. A bigger memory store doesn’t change that. A better embedding model doesn’t change that. A faster vector database doesn’t change that.
The tax gets paid every turn because the mechanism that decides what to deliver, and when, doesn’t exist in a memory-only world. The model is the mechanism. And the model is general-purpose; it doesn’t know what your team’s standards are, what your decision history looks like, what quality criteria your output needs to satisfy.
So even if you give the model perfect memory, you’re still giving it the job of figuring out what to do with that memory. The frontier model is the most expensive component in your stack, and you’re spending its cycles on context arbitration instead of on the work.
That’s not a moat. That’s an inefficiency you’ve made permanent.
Where the value actually lives
The thing that moves the productivity floor — and keeps it moved — is not what gets remembered.
It’s the layer that sits between the user’s request and the model, and decides, before the model runs, what this turn actually needs. It’s the layer that delivers exactly that context, just-in-time, structured for the model to act on immediately. It’s the layer that enforces the standard the output has to meet before the work ships. It’s the layer whose disciplined cycle, running on every request, makes the next request start at a higher level than the last one.
That layer is just-in-time context engineering. We call our implementation the Loop.
The Loop is not a feature. It’s a five-stage disciplined cycle that runs on every request, every session, every supported AI surface:
- Classify — every request is shaped, in milliseconds, by a layer that runs before the model. The model starts with the work already framed, instead of inferring the shape mid-turn.
- Deliver — the turn gets only what it needs — no more, no less — assembled fresh rather than carried as session bloat.
- Execute — the agent doesn’t free-run. The work proceeds in disciplined steps rather than a single uncontrolled pass.
- Shape — every output is checked against the standard before it ships. AI behavior gets shaped to your standard, not the model’s default.
- Learn — every gated outcome becomes signal the system learns from. The next request starts smarter than the last. The cycle doesn’t just repeat — it levels up.
Five stages. Same five every time. Every request runs through them. Every output is shaped by them. Every gated outcome makes the next interaction sharper.
That’s the moat. The moat isn’t any individual stage — not the routing, not the retrieval, not the gate enforcement, not the feedback loop. The moat is the entire disciplined cycle running just-in-time, every time, with a mechanism that compounds.
Why this is defensible
Defensibility in software almost always comes down to one of three things: scale advantages (more users than competitors can match), switching costs (sticky data or workflows), or compounding mechanisms (the system gets better faster than competitors’ systems).
A memory-only product has none of these. Scale is easy to acquire; switching costs are low (export, import, done); the mechanism doesn’t compound — bigger memory just means bigger memory.
Just-in-time context engineering has the third one. Every gated outcome becomes signal the system learns from. The cycle gets sharper with use — in a way a competitor has to reproduce by running an equivalent cycle for an equivalent amount of time. The validated patterns, decisions, and conventions stay in the system and inform every future request.
Speed without discipline is a spike. Discipline without speed is a meeting. Speed inside disciplined gates, with audited outcomes feeding the next decision, is a permanent level-up — and that level-up is what competitors have to reproduce, not a feature list.
What “AI memory” providers are missing
Look at the major memory-product positioning today. The pitches are all about retention. How many tokens we remember. How we cluster prior conversations. How we summarize them for token efficiency. How we keep your preferences across sessions.
The implicit assumption: if we just remember the right things, the AI will do the right things.
That assumption is wrong in a specific, measurable way. Even with perfect retention, the AI has no enforced cycle, no gate that says “this output meets the standard before it ships,” no feedback mechanism that converts gated outcomes into a sharper classifier for the next request. The model still has to figure everything out at runtime, on its own, in the most expensive part of your stack.
The memory primitive is the bottom of the iceberg. The cycle that runs on top of it — the part the customer experiences — is what moves the productivity floor. And it’s invisible to a memory-only product because they’re not building it.
Memory is the storage layer. Just-in-time context engineering is the operating system. You don’t ship an operating system by shipping a better storage layer.
How we know this works
I’ll keep this brief because the long version is on /proof.
The last twelve months of my public GitHub contribution calendar at github.com/bhandrigan is the audit trail — and it covers the entire arc: noticing what was broken, building the thing to fix it, and the step-change once it ran on every request. Three distinct eras:
- May 2025 to November 2025, before any intelligence-context platform existed: average ~100 contributions per week. Solo work, no enforced structure, nothing compounded.
- November 2025 to March 2026, building the substrate — the Loop existed but wasn’t yet running on every request: average ~210 contributions per week. Building the mechanism itself produced a measurable lift before the Loop went live.
- March 24, 2026 onward, with the Loop running on every request: trailing-eight-week average ~1,170 contributions per week — a sustained step-change visible in the public contribution chart.
Compare that to a public benchmark — DORA / State of DevOps puts a typical 8-person dev team’s total weekly contributions at around 80 per week. One operator with the Loop running has sustained an order of magnitude above that benchmark — chart and methodology on /proof.
That’s the existence proof. The mechanism that produced it isn’t memory. It’s the disciplined cycle described above, running on every request.
What a team should plan for
The operator ceiling is what one practitioner showed, with no other variables to confuse the comparison. The team multiplier we cite — 1.5× to 3× sustained throughput — is much more conservative. It’s derived from the same chart, and it sits well below the operator ceiling. Even before the Loop ran on every request, the earlier-stage system alone produced ~2.6× a typical team’s output. The 1.5–3× claim is what a team should budget against, not the ceiling.
That’s the honest pitch. Not 10×. Not heroic. A defensible sustained multiplier, with the operator chart as the existence proof for the mechanism behind it.
What to take from this
Three things, if nothing else.
First: memory is necessary, not sufficient. Stop building products around the memory primitive itself. It’s about to be a commodity feature on every AI surface. The companies that win 2026 will be the ones building the cycle that sits on top of the storage layer.
Second: defensibility comes from the disciplined cycle running just-in-time, on every request, with a mechanism that compounds. Speed alone is a spike. Discipline alone is a meeting. The combination, applied every single interaction, is what moves a productivity floor and keeps it moved.
Third: ask your AI vendor what their cycle is. Not what they remember — what they do with every request, end-to-end, before the model runs and after the model finishes. If the answer is “we retrieve relevant context and inject it,” they’re a memory product. If the answer is “we classify, deliver just-in-time, execute through a structured template, shape against typed gates, and learn from every gated outcome” — they have a moat.
The moat isn’t memory. It’s the cycle.
That’s the entire piece.
If you want to see the five-stage cycle in detail, /how-it-works walks through each stage. If you want to see what the moved floor looks like as twelve months of public data, /proof carries the chart and methodology. If you want to try the cycle on your own work, private access is open by application.