The wave of AI memory tools has a noticeable shape. Almost all of them target coding.

They remember which files you edited. They track architectural decisions. They surface relevant snippets from past sessions. They're optimized for the assumption that "context" means "code context."

This is a strategic choice — coding is a tractable, high-value, technically interesting niche. But it leaves the rest of your AI usage stuck with the same context-loss problem the coding tools just solved.

The non-coding context problem

If you use AI for anything beyond code, the memory gap shows up everywhere.

Writing. You're working on a novel. You spent four sessions building a character: their backstory, their voice, their relationship history. You start a new session. The model doesn't remember any of it. You paste a 5,000-word context document at the start of every session.

Research. You're researching a topic across weeks of sessions. The model has helped you summarize 30 papers, identify research gaps, draft an outline. You open a new chat to ask a follow-up question. None of that history is available. You start over.

Personal projects. You're planning a kitchen renovation. You discussed materials with the AI two weeks ago. Today you want to follow up on the countertop options. The model has no memory of the previous conversation. You re-explain everything.

Health and life logistics. You discussed medication side effects, sleep patterns, financial goals — any topic where context accumulates over time. Every new session starts blank.

The problem isn't unique to coding. It just got addressed there first.

Why coding got attention first

There are good reasons memory tools targeted code:

Code is structured. Files have paths, functions have names, repos have histories. Indexing code is well-understood. Building memory around structured data is easier than building memory around prose.

Coding context is dense. A single coding session might touch fifty files. The context-loss penalty is high — each new session means re-exploring the codebase. The pain is acute and the audience is technical, which makes for a good early market.

Coders pay. Developer tools have established willingness to pay. A writing tool has to convince a less monetized audience that memory is worth a subscription.

Coders build tools. Memory systems for code get built by coders. Coders work on their own pain first.

All of this is rational. It also means the non-coding use cases are underserved.

What general-purpose AI memory looks like

Memory for non-code contexts has different shape than memory for code:

Topics, not files. Code memory anchors on file paths and function names. General memory anchors on topics — "the novel," "the renovation," "the research project on X." The retrieval primitive is "what do you know about this topic" rather than "what's relevant to this file."

Long timelines, slow change. Code changes fast — a memory from last week might be stale. A character in your novel doesn't change as fast. Research topics don't shift overnight. Non-code memory needs to age slower, with stronger persistence.

Mixed sources. A coding session pulls context from one repo. A writing session might pull from notes, web research, transcripts of interviews, previous drafts. Memory has to ingest from more diverse sources.

Personal voice and preferences. "I prefer concise prose with active verbs." "I tend toward this metaphor too much." "My target reader is a non-technical adult." These are memories about how you work, applied across every topic in that domain.

Lower precision, higher recall tolerance. A coding tool retrieving the wrong file is a problem. A writing tool retrieving slightly tangential context is often fine, sometimes useful. The retrieval bar is different.

The opportunity for general-purpose vaults

A memory tool that handles non-coding contexts well has a meaningful market gap to fill. The pattern that works:

Topic-scoped vaults. Group memories by topic, not by source. The "novel" vault contains characters, plot notes, voice samples, references. The "renovation" vault contains materials, contractor notes, budget decisions.

Markdown as the storage layer. General-purpose memory benefits from being human-readable. The user is more likely to read and edit memory directly than they would with code memory. Markdown beats SQLite for this audience.

Cross-domain personal preferences. Some memories apply everywhere — "I learn better with concrete examples," "summarize first, details on request." These should be retrieved regardless of topic.

Time-aware retrieval. A memory from two years ago about a paused project should still surface when you return to it. Not all old memories are stale.

Citation and provenance. "You said X on March 15." "This came from the article at URL Y." When memory is reconstructed from accumulated context, knowing where each piece came from matters more than in code.

What this means for AI memory product design

If you're building memory tools, the coding niche is crowded. The general-purpose tier is wide open.

The technical work to support general memory is mostly already done — file storage, retrieval, MCP integration. The design work is different: think about topics instead of repos, prose instead of code, slow timelines instead of fast iteration.

The market is also larger. Every knowledge worker who uses AI is a candidate. Every researcher, writer, designer, planner, student. The coding audience is sharp but narrow. The non-coding audience is broader and just as starved for continuity.

The compounding effect

There's another reason general-purpose memory matters: it compounds.

A coding memory is useful for the repo it's about. A writing memory is useful for the project it's about. But personal memories — your voice, your preferences, your accumulated knowledge — apply across every conversation you ever have with any AI tool.

The more general the memory, the more it benefits from accumulating. A vault that learns how you think about problems, what you already know, what you tend to confuse — that vault becomes more valuable every year. Code memory stays useful for as long as the code exists. Personal memory stays useful for as long as you do.

This is the asset that AI memory tools haven't fully claimed yet. The coding wedge is real. The wedge after coding is everything else.