The unit of value is not memory. It is the handoff.
Every competitor built a place to store context and a way to query it. Querying requires knowing what to ask, and the defining condition of picking up work is not knowing what you do not know.
Nobody types the most valuable question
Here is the test we keep coming back to. Someone joins a piece of work on Wednesday that someone else started on Monday. They have a memory store, fully populated, perfectly indexed. What do they type?
They type something about the task in front of them. They do not type "what approaches did we already reject?" - and that is almost always the most valuable thing in the store.
This is not a search-quality problem that a better embedding fixes. It is structural. A query returns what you asked for, and the thing that hurts you when resuming work is precisely the thing you did not know to ask about. A store can only answer; it cannot volunteer.
The failure is silent, which is what makes it expensive. Nobody notices the constraint they were never shown. They notice three days later, when the approach they took gets rejected in review for a reason that was settled a week before they arrived.
Push, not pull
So the operation we build is not "retrieve". It is "hand over". An artifact produced at the moment work stops and consumed at the moment it resumes, containing the things the receiver would not have thought to pull.
| A memory store gives you | A handoff gives you |
|---|---|
| Somewhere to put context | An object that arrives |
| Results ranked by similarity to your query | The single next action, and what blocks it |
| Whatever you knew to ask for | The constraints you must not violate, asked for or not |
| A flat list of facts | What was tried, rejected, and must not be proposed again |
That last row is the one nobody else produces, and it is the one we would keep if we could only keep one. A deleted item cannot warn anyone. When something is superseded here, the replacement points at what it replaced and the old item stays, marked, with its reasoning intact - because what a team tried and rejected on Monday is exactly what a fresh agent proposes on Tuesday.
What a transfer forces that a store does not
Choosing the transfer over the store is not a framing exercise. It changes the data model on the first migration, and in ways that cannot be bolted on afterwards.
- Several writers, so provenance stops being optional. Once work moves between people, every item has to record who asserted it - a human or an agent, which one, when. A human-confirmed constraint and an unconfirmed agent guess are not the same object and must not render the same way.
- Disagreement becomes a first-class state. Two writers will contradict each other. An agent contradicting a human-confirmed item is stored as disputed rather than applied; two humans contradicting each other is never auto-resolved, because arbitrating between colleagues is not a decision software should make on their behalf.
- Permissions, because a transfer crosses a boundary. Context does not stop at a team edge - a decision in payments changes what sales can promise - so the model assumes the company rather than the individual.
A single-user memory product has none of these problems, by construction. It also cannot grow into a product that does, because each one is a schema decision rather than a feature.
And it has to survive crossing tools
The other half of the bet: a handoff that only works inside one vendor’s client is not a handoff, it is a session feature.
Work does not stay in one tool. It stops in Claude Code and resumes in Cursor, or stops with an agent and resumes with a person who does not use agents at all. Model providers are structurally incentivised against that kind of neutrality - their memory makes their client stickier, which is the point of building it.
That gap does not close on its own, which is why we sit beside the frameworks and the clients rather than above them, and why the MCP server exposes no vendor-specific behaviour.
What actually keeps a team
Not the feature list. Features get copied in a quarter.
What compounds is the record: after a year, the project carries its own history of what was decided, why, who confirmed it, and what was already ruled out. A competitor cannot copy that, because it is not our software - it is the customer’s own history, and it gets more useful every month it grows.