{"slug": "two-kinds-of-memory", "title": "Two Kinds of Memory", "summary": "A developer introduced virage, a new tool that creates a searchable vector index of a codebase, complementing the previously released kms tool for capturing curated decisions. Virage uses AST-aware chunking and semantic search to answer 'where' and 'what' questions about code, while kms handles 'why' questions with citations. The developer emphasized that the two tools address distinct memory problems and are not integrated.", "body_md": "I asked my AI agent where the retry logic lived. Four seconds later:\n\nthree files, one shared helper, a comment linking to a Slack thread\n\nthat doesn't exist anymore. Found it cleanly.\n\nThen I asked why the retry count was capped at three instead of five.\n\nSilence, then a guess. It could find the code. It had no idea why the\n\ncode said what it said.\n\nTwo failures wearing the same complaint — \"the AI doesn't know this\n\nproject.\" One's a search problem. The other's a memory problem. I'd\n\nalready fixed the memory one; that's what this whole series has been\n\nabout. The search problem needed a genuinely different tool.\n\nkms only knows what someone deliberately wrote down as a decision,\n\nfact, or guardrail. Curated, citable, checkable — `query` answers \"why\n\ndoes this work this way\" with a real citation, because the answer is\n\nsitting in a file someone wrote on purpose.\n\nMost of a codebase isn't a decision, though. It's just code —\n\nfunctions, old comments, a README paragraph, a PR nobody formalized\n\nbecause it never rose to that level. kms has nothing to say about any\n\nof it. Not broken. Never the job.\n\n`virage` is a separate vivantel tool for exactly that gap — a\n\ngit-aware pipeline that turns a codebase and its docs into a\n\nsearchable vector index.\n\n```\nvirage init\nvirage index\nvirage query \"how does authentication work?\"\n```\n\n`init` writes `virage.config.json` via an interactive wizard. `index`\n\nchunks the repo — AST-aware, so a function stays one semantic unit\n\ninstead of getting sliced at an arbitrary line count — and embeds it.\n\n`query` searches by meaning, not keyword: ask about authentication and\n\nit finds the relevant code even if that word never appears in it —\n\nsomething grep structurally can't do.\n\nEvery stage is swappable: an OpenAI-compatible embedder or a fully\n\nlocal ONNX model, an embedded file-based vector store for a solo repo\n\nor Postgres/Qdrant for a team, an optional reranker on top. Same CLI\n\nregardless of what's behind it.\n\n\"AI memory\" tools promising a single system for this exist — Mem0,\n\nLetta, Cognee, and similar. They solve a third, different problem: raw\n\nrecall of accumulated facts or conversation history, closer to\n\nvirage's mechanism than kms's, but aimed at remembering what happened,\n\nnot retrieving a curated decision a human stood behind. None separate\n\n\"a fact\" from \"a commitment the team made\" the way kms does, and none\n\nare built for a git repo's own structure the way virage is.\n\nAn earlier piece in this project's kms series described a real mess:\n\nauth split across three places, nobody could say why.\n\n`virage index` finds all three in seconds — every file touching auth,\n\nranked by relevance, whether or not \"auth\" shows up in a variable\n\nname. Search problem, solved.\n\nIt can't tell you *why* it's split three ways. That answer, if it\n\nexists, lives in a decision someone wrote down — the kind\n\n`bootstrap`'s gap-fill mode goes looking for, or `query` retrieves\n\nwith a citation once it's captured. `virage` has no opinion on that\n\nquestion. Never asked one.\n\nNeither tool is weaker — they answer different questions, *where is this* and \n\n`virage query` for \"where\"/\"what\" questions. `kms query` for \"why\"\n\nquestions. They're two separate tools today, not one integrated\n\nsystem — running `virage` doesn't feed `kms`'s decisions, and vice\n\nversa. Worth saying plainly rather than implying a seamlessness that\n\nisn't there. What they share is a practice, not a product: don't let\n\neither kind of memory live only in someone's head.\n\nIf this is useful, a star helps other developers find both:\n\n**⭐ [Star vivantel/kms](https://github.com/vivantel/kms)** ·\n\n**⭐ [Star vivantel/virage](https://github.com/vivantel/virage)**\n\n```\n/plugin marketplace add vivantel/kms\n/plugin install kms\n```\n\nThat's Claude Code. Codex reads the same skill set through its own\n\nplugin manifest. Kilo Code CLI reads it too, once `kilo.jsonc` points\n\nat the published skills manifest.\n\n```\nnpm install -g @vivantel/virage\nvirage init\n```\n\nClaude Code again first, via virage's own agent plugin. GitHub Copilot\n\nreads the same index through its own agent plugin. Codex reads it\n\nthrough its own agent plugin. Antigravity reads it through its own\n\nintegration.\n\nIf you already run kms, `virage index` on the same repo takes about a\n\nminute and costs nothing to try. If you run neither yet, start with\n\nwhichever question you actually have: something you can't find, or\n\nsomething you can't explain.", "url": "https://wpnews.pro/news/two-kinds-of-memory", "canonical_source": "https://dev.to/sergemso/two-kinds-of-memory-4gin", "published_at": "2026-09-07 19:16:59+00:00", "updated_at": "2026-09-07 19:32:24.819665+00:00", "lang": "en", "topics": ["developer-tools", "ai-tools"], "entities": ["vivantel", "kms", "virage", "Mem0", "Letta", "Cognee", "Claude Code", "Codex"], "alternates": {"html": "https://wpnews.pro/news/two-kinds-of-memory", "markdown": "https://wpnews.pro/news/two-kinds-of-memory.md", "text": "https://wpnews.pro/news/two-kinds-of-memory.txt", "jsonld": "https://wpnews.pro/news/two-kinds-of-memory.jsonld"}}