DEV Community: Kage

Your coding agent's memory should have to prove itself

Kage — Fri, 12 Jun 2026 18:00:09 +0000

An agent acting on wrong memory is worse than one with none.

Every memory tool for coding agents has the same quiet failure mode: knowledge written weeks ago keeps getting recalled after the code it describes was refactored away. The store only grows, nothing re-checks it, and the agent confidently acts on stale facts.

We built Kage around one rule: memory has to prove itself. Every memory cites the files it's about, and it's checked against your repo three times:

On write - a memory citing a file that doesn't exist is refused. Hallucinated knowledge never enters storage.
On recall - if the cited code changed or was deleted, the memory is withheld and flagged instead of served.
On your diff - kage pr check warns when a change you're about to merge invalidates something the team knows.

The loop runs itself: sessions that captured nothing get auto-distilled into drafts you review (a signal gate keeps junk out), every session opens with a "previously..." digest, and each recall prints a receipt - tokens and dollars saved, measured per memory.

Memory lives as plain JSON in your repo, reviewed in the same PR as the code. Personal memory syncs over a private git remote you own. No account, no API key, no database.

One command wires Claude Code, Codex, Cursor, Windsurf - anything MCP:

npx -y @kage-core/kage-graph-mcp install

See what your own repo is hiding (read-only, ~1 min): npx -y @kage-core/kage-graph-mcp scan --project .

Site: https://kage-core.com
Repo (GPL-3.0): https://github.com/kage-core/Kage

Teams: we're running live 30-minute demos on your repo - the Truth Report, a stale-catch on a real diff, and the savings receipt at the end. Book one: https://kage-core.com/demo.html

Would love hard questions - especially from anyone who's watched an agent confidently act on stale knowledge.

We ran one command on Express.js. Its repo is hiding 7 knowledge voids.

Kage — Thu, 11 Jun 2026 21:14:17 +0000

No signup, no config. We pointed one command at a fresh clone of Express.js:

npx -y @kage-core/kage-graph-mcp scan

0.3 seconds of analysis later (142 files, 3,160 symbols, full git history), it printed this:

Kage Truth Report - express
  0 duplicate clusters - 0 ghost exports - 0 bus-factor-1 hot files - 7 knowledge voids

KNOWLEDGE VOID - high churn, zero memory
  lib/response.js - 390 commits of accumulated decisions,
  149 graph edges depending on it - and zero memory packets
  or doc mentions. Agents and new hires fly blind here.

  lib/application.js - 179 commits, 77 edges. Same story.
  lib/request.js - 175 commits, 58 edges. Same story.

What is a knowledge void?

Take every file in a repo and ask two questions: how often has it changed (churn), and how much depends on it (centrality in the import/call graph)? Now ask a third: where is the accumulated knowledge about it written down?

For lib/response.js the answers are: 390 commits of decisions, 149 dependents, and... nowhere. Not the README, not the docs, not any structured memory. Every one of those 390 commits had a reason. The reasons live in the heads of whoever wrote them.

That is fine until an AI agent (or a new teammate) touches that file. They fly blind - and on high-centrality files, blind edits are how regressions are born.

What else the scan checks

Duplicate implementations - same-name, same-signature functions in different packages, flagged when they appeared recently (the AI-era copy-paste signature)
Ghost exports - exported symbols with zero call edges, verified against raw source so CommonJS property-requires don't false-positive
Bus factor 1 - hot files only one person has ever committed to, ranked by graph centrality
Doc lies - README claims checked against the code graph: paths that don't exist, npm scripts that aren't in package.json, CLI flags that appear nowhere

Every finding comes with file:line evidence. Nothing is a vibe.

How it works under the hood

The scan is built on a local code graph: TypeScript compiler AST for TS/JS, tree-sitter (pure WASM, no native deps) for Python/Go/Rust/Java/Ruby, import-aware call resolution so a call edge means the import actually resolves there - plus one pass over git history for churn and authorship. All local, nothing leaves your machine.

The same engine powers the rest of Kage: verified memory for coding agents. Memory that cites a file that doesn't exist is rejected at write. Memory whose cited code changed is withheld from recall and flagged at the exact moment your diff invalidates it:

Your changes invalidated 1 team memory:
  - Payment validation rule - cites src/payments.ts
    (content changed since this memory was verified)

And it prints receipts, because tools should show their value instead of asserting it:

This week Kage saved you ~845K tokens (~$12.67),
blocked 0 stale memories, answered 5 recalls.

Try it on your repo

npx -y @kage-core/kage-graph-mcp scan

If it finds nothing interesting, you have an unusually well-documented repo - genuinely, congratulations. If it finds a void on your most-depended-on file, that is the file your next agent session will touch blind.

Open source (GPL-3.0), works with Claude Code, Codex, Cursor, Windsurf, any MCP client: https://github.com/kage-core/Kage

I would love to know what the scan finds on YOUR repo - drop the weirdest finding in the comments.

Shared memory for developers and their coding agents — so the team stops rediscovering its own codebase

Kage — Sat, 06 Jun 2026 07:28:16 +0000

Every team keeps rediscovering its own codebase. Someone already chased down this exact bug last month. The reason that module is shaped the way it is got decided in a thread nobody can find. A new teammate — or a fresh agent session — hits the same wall and re-derives it from scratch.

The knowledge exists. It's just trapped: in people's heads, in closed PRs, in one-off chat sessions that evaporate when the window closes.

Kage is a shared memory layer for developers and their coding agents. Capture a learning once — a bug's root cause, a decision, a gotcha — and the whole team, and every agent (Claude Code, Codex, Cursor, Windsurf, anything that speaks MCP), recalls it the next time it's relevant. The team stops rediscovering the same things.

And it's grounded in your actual code and lives in your repo — so shared memory is reviewed in PRs like everything else, and stays accurate as the code changes.

See it on a throwaway repo in 30 seconds:

npx -y @kage-core/kage-graph-mcp demo

Shared, like the rest of your codebase

Memory in Kage is a team artifact, not a personal scratchpad:

✍️ Anyone (or their agent) captures a learning as they work — tied to the files it's about.
🔎 The next person to touch that code has their agent recall it automatically — no re-deriving it.
🔁 It's git-native — plain JSON in the repo, reviewed in the same PR, shared with everyone on merge. New hires and fresh agent sessions inherit the team's accumulated context on day one.

No vector DB, no API key, no separate service.

Stays accurate as the code moves

Because each note is tied to the files it describes, shared memory doesn't rot:

a note that cites a file which doesn't exist won't be stored;
when code a note depends on is deleted or refactored, that note is held back and flagged to update;
nothing drifts silently — it's grounded in, and reviewed with, the code.

(You can even measure how grounded your repo's memory is with kage benchmark --trust — a health check, not the headline.)

See what the team remembers

Kage ships a viewer — a shared dashboard of your repo's memory: what the team and its agents have learned, every note wired to the code it's tied to, and what's actually been recalled.

Try the live one (nothing to install): https://kage-core.com/viewer

Try it

npx -y @kage-core/kage-graph-mcp demo

Open source (GPL-3.0). If your team could stop rediscovering its own codebase, a ⭐ on GitHub helps a lot — and I'd love your feedback.