Persistent memory for internal tools — so context doesn't vanish the moment someone closes a tab.
Internal tools forget everything between sessions. Decisions get re-litigated. Context lives in someone's head or a lost Slack thread — not in the tool.
The reasoning behind a system is almost never written where the system lives. It's in a thread that scrolled away, a call nobody recorded, a PR comment three refactors deep. The code records what was decided; nothing records why, or which two alternatives were considered and rejected for reasons that still apply. Six months later that gap is indistinguishable from the decision having been arbitrary.
The cost shows up as repetition. The same argument gets had twice because the first outcome left no trace. A fix that took a day to work out gets worked out again by whoever hits it next. A new hire asks why something is the way it is and gets four partial answers, none of them from the tool they're actually using. Documentation is supposed to solve this, but documentation describes the current state — it's written deliberately, at a moment separate from the work, and it goes stale precisely because keeping it fresh is somebody's side task.
None of this is a knowledge-capture problem in the way the phrase is usually meant. The knowledge exists, and it was already written down once, in the moment, by the person who had it. It just landed somewhere with no index, no lifespan, and no relationship to the tool it describes.
A persistent memory layer that sits alongside internal tools — indexing decisions, context, and past work so anyone on the team can retrieve it later, not just the person who made the original call. It's not a database bolted on after the fact: the tool actively reads from and writes to shared memory as people use it.
The write path is the part that has to be nearly invisible. If capturing context is a separate step someone has to remember, it inherits the same failure mode as documentation. So memory is written from the work itself — a note left in passing, a decision recorded where it was made — rather than from a form filled in afterwards.
The read path is retrieval by meaning rather than by location. Nobody remembers which tool or thread held the answer, so the question is asked in ordinary language and matched against what was captured, with the answer surfaced next to the work it applies to instead of in a separate place someone has to think to check.
Explored through hackathon work on memory-platform internals — design and architecture research, not yet a shipped client deployment.
Context that would slip away, kept and findable.
Three things this gets mistaken for, and why each one falls short of the job.
A wiki is written on purpose, separately from the work, by someone who already decided the thing was worth writing down. That filter is exactly what loses the small stuff — the one-line aside that explains an entire subsystem. Memory has to catch what nobody would sit down to write.
Chat history records everything said, which makes it a record of nothing in particular. Searching it hands back the conversation rather than the conclusion — you still have to read the thread and work out how it ended, assuming it ended at all.
Embedding text and querying it is a component, not a product. Without a view of what supersedes what, who said it, and whether it's still true, retrieval returns confident-sounding history and leaves the reader to figure out which parts still hold.
Five layers. The interesting engineering is in the first two and the last one — the middle is comparatively well-trodden.
Memory is easy to describe and hard to get right. These are the design problems the exploration keeps returning to.
Semantic search over captured text is well-understood, and a related retrieval pattern already ships in a voice memory tool. The unsolved part sits upstream: getting the right things into memory in the first place, in a form worth retrieving.
A memory layer that is confidently wrong once gets checked twice and then ignored. Which means provenance — who recorded this, when, in what context — matters as much as the content, and anything surfaced has to be traceable back to where it came from.
Memory in a separate destination is documentation with extra steps. The version that seems to hold up is the one embedded in the tools people already have open, reading and writing as a side effect of ordinary use.
The bar we'd hold this to before putting it in front of a client team.
Anywhere a persistent, shared memory layer changes how a team's internal tools behave.
Every internal tool we build eventually runs into this. The software works; the knowledge about why it works the way it does lives somewhere else. A year in, that gap — not the code — is what slows a team down, and no amount of shipping features closes it.
The same problem shows up in agent work, in a sharper form. An agent without durable memory re-derives its context on every run, which is merely expensive when it gets the answer right and genuinely dangerous when it doesn't. Whatever solves memory for a team's tools is close to what makes an agent useful past a single session, which is why this keeps coming back around rather than staying a side interest.
So it stays an exploration we return to, not a product with a launch date. When it does reach client work, it will most likely arrive as infrastructure inside something else — the reason a tool we built remembers what happened last quarter, rather than a thing sold on its own.
Active exploration, not a shipped client product — backed by hands-on work on memory-system internals. A related retrieval pattern already ships in a voice memory tool, where spoken thoughts become semantically searchable later.