"Code memory for coding agents" is a hot lane right now. A 49k-star code-graph tool shows up, FalkorDB is pushing GraphRAG, and the reflex is the same one we apply to everything popular: lots of stars — let's wire it in. We ran one through our radar instead. Here's the part worth keeping: not the verdict, but the axis we used to reach it.
The lane has two very different shapes
Most "memory for your agent" is a vector database: chunk the repo, embed it, retrieve by similarity. That is genuinely good at one thing — finding code that looks like other code. Paste a function, get back functions shaped like it.
But the question I actually ask every day isn't "what looks similar to this." It's:
"If I change this function, what breaks?"
Similarity can't answer that, and not by accident. The callers of a function look nothing like the function. A logging wrapper, a retry decorator, a route handler three layers up — none of them are textually similar to the body you're editing. They're connected by structure, not by surface. Answering "what breaks" is a graph traversal — walk the call edges — not a nearest-neighbour lookup in embedding space.
That's the real divide in this lane: similarity retrieval vs structural (graph) retrieval. Almost everything in the hype cycle is the former. The thing you reach for during a risky refactor is the latter.
What we did with a 49k-star tool
CodeGraph (MIT, ~49k stars, 20+ languages, auto-syncing local index, MCP server for Cursor/Claude Code/Codex) is a serious piece of work on the structural side. We evaluated it properly — read the repo, mapped its capabilities against ours.
And we deliberately did not adopt it.
Not out of not-invented-here. Our own engine, EngramGraph, already covers the core: a tree-sitter code graph where callers <fn> is a graph walk, plus a deterministic, zero-LLM index (no embeddings to drift, cheap to rebuild, same answer every run). The decision to build rather than wire in an external daemon was already made; adopting CodeGraph wholesale would have added a dependency and an architecture conflict, not a capability.
So we filed it as Assess, and wrote down the three things it's genuinely useful for — without adopting it:
- A language-coverage blueprint. CodeGraph parses 20+ languages and recognises 17+ framework routing patterns. We don't import its code; we use its parser list as a reference map for where to extend ours next.
- A benchmark method. Its 7-codebase, four-axis measurement (cost / tool-calls / tokens / latency) is a reusable yardstick template for proving a code graph actually reduces agent exploration — not a set of numbers to copy. Their absolute figures are theirs; the method travels, the numbers don't.
- An interop signal. It exposes its graph over MCP to several agents. That's market evidence that "cross-agent code-graph over MCP" is wanted — worth watching, not worth coupling to.
The point isn't the verdict
A "no" with reasons is more useful six months later than a "yes" you can't reconstruct. The lesson that outlives this particular tool:
Tool selection in a hyped lane is not a star-count comparison. It's one question — does this solve the thing I actually ask every day? For code memory, that question splits cleanly along similarity-vs-structure. Once you know which side of that line your real problem lives on, half the shiny options on the radar quietly stop being relevant.
EngramGraph is how we answer "what breaks if I change this" — a code graph, not a pile of embeddings. MIT, Node ≥ 22, zero LLM required.
→ npm i engramgraph · github.com/AsiaOstrich/EngramGraph
Top comments (0)