§1The tax you never see on the invoice
A coding agent joins your repository knowing nothing about it. So every session it does the same archaeology: greps for a function, opens the file, greps for the thing that calls it, opens that too. It is re-learning the shape of code that has not changed since yesterday, and it pays for the lesson twice, once in tokens and once in tool calls. Nobody itemises that cost, but it is on every bill.
A tool called Graft measured the tax and then removed most of it. On SWE-bench Verified, a standard set of fifty real GitHub issues graded by the official harness, an agent with Graft resolved 33 of 50 against 27 without it, while using 23% fewer tokens and 25% fewer tool calls and finishing about a third faster. That is a rare kind of result: cheaper, faster and more correct at the same time. It is worth understanding what the tool actually does, because the label people keep putting on it is wrong.
§2What Graft actually is
Graft is MIT-licensed, from a team posting as trailhq. It parses your repository with tree-sitter into a code graph and serves that graph to your coding agent over MCP. The server exposes six tools: find code as ranked results with file:line, list every signature in a file without the bodies, trace calls with a depth limit, regex search grouped by symbol, a repository map of clusters and hotspots, and a freshness check. Twenty-three languages, with full cross-file resolution for the big ones.
The part that matters is what powers it. The structural layer uses no model at all. It is tree-sitter and graph-walking, so it costs nothing, needs no API key, runs offline, and rebuilds itself when the code changes. An optional --deep pass adds model-written summaries on top, cached by content hash so you only pay once per version. Strip that away and the useful core is a free, deterministic map that the agent reads instead of reconstructing. That is the whole trick, and it is a good one.
§3Why "memory" is the wrong word
The category this tool keeps getting filed under is "codebase memory." It is not memory. It is a map. The two are not the same thing, and running them together is the mistake.
A map tells you the shape of the territory as it stands right now: what calls what, where a symbol lives, which files cluster together. Graft regenerates that from scratch, deterministically, the way node_modules regenerates. Nothing is remembered; it is recomputed, fresh, every time. Memory is the opposite kind of thing. Memory is what happened before that the current code does not show you: the bug you already fixed and must not reintroduce, the approach you tried last week that failed, the decision and the reason behind it. A map carries none of that, however up to date it is. We made this same cut from the other direction in Note №77 about recall. It holds here too: a perfect picture of the present is still not a record of the past.
§4We already run the map, so here is the honest verdict
Our fleet already queries a structural code graph over MCP, so this is a verdict from use rather than from the README. Handing an agent the shape of the code up front beats letting it rebuild that shape by trial and error, every single time, and it is not a subtle margin. An agent that can ask "who calls this" in one query does not burn ten file reads working it out. The token and tool-call numbers Graft reports match what you see the moment you stop making the model grope in the dark.
What Graft adds is not the idea. It is the packaging. A deterministic, no-database, drop-in version of the idea with benchmarks attached, so you do not have to wire your own graph server and argue with yourself about whether it helps. That is a real contribution and an unglamorous one: good defaults, shipped, measured. Most tools in this space ask you to take the benefit on faith. This one hands you the harness.
§5The design move worth copying
The sharpest thing in Graft is not any single one of its six tools. It is the split. A deterministic structural layer at the bottom that is free, offline and always fresh, and an optional model layer on top that only runs when you ask for it and caches what it produces. The cheap deterministic thing carries the weight. The expensive model is the garnish, not the meal.
That is the same shape as the best agent plumbing we keep arriving at from every direction: put the part that cannot hallucinate underneath, and make the model layer optional and cached above it. When your baseline still works with the model turned off, you have built the thing the right way round. When it collapses without the model, you have built a demo. Graft is on the right side of that line, and the line is the lesson, not the tool.
§6What a map will not do for you
Two honest limits, because the label hides both. First, the model summaries do not refresh themselves. The structural graph tracks your edits, but the prose written about your code goes stale the instant the code moves, and Graft will not rewrite it until you run the deep pass again. Fresh skeleton, ageing notes, and only you know which parts drifted.
Second, and this is the one the word "memory" quietly promises and cannot deliver: a map will not stop your agent making the same mistake twice. It will navigate your codebase beautifully and still walk straight into the wall it hit last Tuesday, because avoiding that wall is memory, a different tool on a different axis. Parsing and graphing is one job. Recalling and retaining is another. If you want both, you buy both. Buy Graft for exactly what it is, a very good map, and do not wait for it to remember anything. It was never built to.