Kythene vs a memory server
Why not just use a memory server? Or build one yourself?
Two fair questions, and they have the same answer. A memory server, or a weekend wiring your own, both get you the same thing: store everything, search it back out. That part is close to solved - there are over 160 open-source agent-memory projects, and your own assistant will sketch you a schema this afternoon. It's just not the part that goes wrong. What goes wrong is that nobody agreed what was true, and a stale fact reads exactly like a fresh one.
"There's a server for this already"
There is, and some of it is very good. The first public agent-memory leaderboard, in August 2026, defined the thing it measured in three words: Add -> Search. That's the whole field. Store everything, then compete on getting the right thing back - better embeddings, better chunking, a graph if you're feeling fancy.
It's real engineering. It just optimises the half that isn't hurting you. Nothing in Add -> Search records when a fact was last true, what replaced it, or whether anyone agreed to it.
"I could build this in a weekend"
You probably could. A table, a vector column, a recall tool - your assistant will happily draft the lot. The concept isn't scarce any more; assistants explain it accurately without being asked.
But ask one to actually design it and it flags the same thing every time: the gate between what your AI learned and what it's allowed to act on. That gate is the hard part, and it's the part a weekend build skips - so you ship the easy 20% and inherit a memory system to keep correct across a team, which is the 80% nobody budgets for.
The half that hurts
Nobody's actual complaint is that retrieval missed.
Go and read what people post three months into running one of these. It's never "it couldn't find the note". It's "the note was wrong - the decision got reversed and nobody updated it". The memory was found. It was just out of date, and it read with exactly the same confidence as a current one.
Better search makes it worse
A stale memory reads identically to a fresh one - same shape, same authority in the prompt. So improving recall improves the delivery of facts that stopped being true in March.
The two failures look the same
Your AI did the wrong thing - because it never found the memory, or because it found one that was wrong? Same symptom. The instinct is to blame retrieval and buy more of it, which makes the real problem worse.
A hand-built store rots
The graph you curated by hand rots the second you look away, because keeping it current is extra work on top of shipping, and it's nobody's job. That's true, and it kills most knowledge bases.
The question isn't what you store. It's what gets to change what your AI does.
That's the part Kythene works on, and it's the part you don't get from a server or a weekend.
Correcting isn't somebody's job
The rule lives in the recall tool description itself, so every client reads it on every recall: if what comes back contradicts the live system, check the real thing and fix the memory - don't work around it. An instance in Cursor or Codex that's never heard of our Claude skill still gets told. Nobody's been handed a maintenance rota; the correcting happens inside the work.
Three things can happen to a memory, and they're different
Supersede it when the fact changed - new version, old ones still readable. Deprecate it when it stopped applying - flagged stale, pointed at its successor, hidden from recall, restorable. Forget it when it should never have existed - gone, and that one's not reversible. Most systems have one verb for all three, which is why you can't tell "this was updated" from "this was wrong" from "this is gone".
Sharing is gated; storing isn't
Write whatever you like in your own project memory - being wrong there costs almost nothing, and that's where most of the volume should live. Promoting a memory into your team's workspace is the one deliberate step: an owner gets it in their inbox and approves it before anyone else's AI applies it. So what your team's AI acts on is what your team agreed - and the human stands in the one place where being wrong is expensive.
And you can check afterwards
Every supersede, deprecate, forget and promotion is on the workspace activity feed, with who did it and when. Automating the correction doesn't lose the audit trail - you can always ask what a memory said before, and who changed it.
Where we're not there yet
We don't yet tell you a memory has gone stale before someone trips over it.
Our correcting is reactive. It fires when an instance meets the contradiction - recalls a memory next to the live truth and fixes it. There's no confirmed-at date, no decay, no score, and nothing that watches your codebase and flags a memory whose underlying facts moved. If a fact rots quietly in a corner nobody visits, it stays rotten until someone recalls it.
Anchoring memories to the facts underneath them is the right next problem, and we haven't solved it. What we do have is the gate and the audit trail, running in a real product today - and that's the part that decides whether your team's AI acts on what your team agreed.
If it's just you
If you're one person and you want your agent to stop forgetting between sessions, a memory server is a fine answer, and a weekend build might be too. You don't need us.
If there are several of you
And the thing that hurts is that your AI and your colleague's AI have quietly built two different pictures of the same product - that's a different problem. It isn't retrieval, and it isn't storage. It's that nobody agreed what was true. That's the one we built.
See what your team agreed, not what one AI remembered.
Start free - sign in with GitHub or Google and your workspace is created automatically. No card.
Start free