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.
What kms doesn't do
kms retrieves what's been captured as decisions, facts, and guardrails — curated, citable, checkable. query answers "why does this work this way" with a real citation because the answer was captured on purpose.
But kms also has skills that discover knowledge implicitly: bootstrap extracts intents from git history and facts from existing docs; capture flags contradictions and drift after every work session; roadmap interviews a plan and captures every implicit presupposition as a durable record. None of those require someone to have written it down beforehand — they find what's already there in history, code, and conversation.
What kms doesn't have is semantic search across the raw codebase. Most of a codebase isn't a captured 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 unless a skill captured it. Not broken. Never the job.
What virage does instead
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.
Why not one tool that claims to do both
"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.
Same auth mess, two different tools
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 why is it this way. Conflating them is how a team ends up
re-grepping the same code every time, or re-deciding the same question
every time.
Using both without confusing what each is for
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.
Try it
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.
Top comments (0)