cd /news/developer-tools/two-kinds-of-memory · home topics developer-tools article
[ARTICLE · art-122643] src=dev.to ↗ pub= topic=developer-tools verified=true sentiment=· neutral

Two Kinds of Memory

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.

read4 min views2 publishedSep 7, 2026

I asked my AI agent where the retry logic lived. Four seconds later:

three files, one shared helper, a comment linking to a Slack thread

that doesn't exist anymore. Found it cleanly.

Then I asked why the retry count was capped at three instead of five.

Silence, then a guess. It could find the code. It had no idea why the

code said what it said.

Two failures wearing the same complaint — "the AI doesn't know this

project." One's a search problem. The other's a memory problem. I'd

already fixed the memory one; that's what this whole series has been

about. The search problem needed a genuinely different tool.

kms only knows what someone deliberately wrote down as a decision,

fact, or guardrail. Curated, citable, checkable — query answers "why

does this work this way" with a real citation, because the answer is

sitting in a file someone wrote on purpose.

Most of a codebase isn't a decision, though. It's just code —

functions, old comments, a README paragraph, a PR nobody formalized

because it never rose to that level. kms has nothing to say about any

of it. Not broken. Never the job.

virage is a separate vivantel tool for exactly that gap — a

git-aware pipeline that turns a codebase and its docs into a

searchable vector index.

virage init
virage index
virage query "how does authentication work?"

init writes virage.config.json via an interactive wizard. index

chunks the repo — AST-aware, so a function stays one semantic unit

instead of getting sliced at an arbitrary line count — and embeds it.

query searches by meaning, not keyword: ask about authentication and

it finds the relevant code even if that word never appears in it —

something grep structurally can't do.

Every stage is swappable: an OpenAI-compatible embedder or a fully

local ONNX model, an embedded file-based vector store for a solo repo

or Postgres/Qdrant for a team, an optional reranker on top. Same CLI

regardless of what's behind it.

"AI memory" tools promising a single system for this exist — Mem0,

Letta, Cognee, and similar. They solve a third, different problem: raw

recall of accumulated facts or conversation history, closer to

virage's mechanism than kms's, but aimed at remembering what happened,

not retrieving a curated decision a human stood behind. None separate

"a fact" from "a commitment the team made" the way kms does, and none

are built for a git repo's own structure the way virage is.

An earlier piece in this project's kms series described a real mess:

auth split across three places, nobody could say why.

virage index finds all three in seconds — every file touching auth,

ranked by relevance, whether or not "auth" shows up in a variable

name. Search problem, solved.

It can't tell you why it's split three ways. That answer, if it

exists, lives in a decision someone wrote down — the kind

bootstrap's gap-fill mode goes looking for, or query retrieves

with a citation once it's captured. virage has no opinion on that

question. Never asked one.

Neither tool is weaker — they answer different questions, where is this and

virage query for "where"/"what" questions. kms query for "why"

questions. They're two separate tools today, not one integrated

system — running virage doesn't feed kms's decisions, and vice

versa. Worth saying plainly rather than implying a seamlessness that

isn't there. What they share is a practice, not a product: don't let

either kind of memory live only in someone's head.

If this is useful, a star helps other developers find both:

Star vivantel/kms ·

Star vivantel/virage

/plugin marketplace add vivantel/kms
/plugin install kms

That's Claude Code. Codex reads the same skill set through its own

plugin manifest. Kilo Code CLI reads it too, once kilo.jsonc points

at the published skills manifest.

npm install -g @vivantel/virage
virage init

Claude Code again first, via virage's own agent plugin. GitHub Copilot

reads the same index through its own agent plugin. Codex reads it

through its own agent plugin. Antigravity reads it through its own

integration.

If you already run kms, virage index on the same repo takes about a

minute and costs nothing to try. If you run neither yet, start with

whichever question you actually have: something you can't find, or

something you can't explain.

── more in #developer-tools 4 stories · sorted by recency
── more on @vivantel 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/two-kinds-of-memory] indexed:0 read:4min 2026-09-07 ·