Why Graft Exists
The problem
Section titled “The problem”Every task, your coding agent starts blind. Before it changes anything, it re-explores the repo: grep a term, open a file, follow an import, back out, try again. It is rebuilding a picture of a codebase it mapped an hour ago and threw away. That rediscovery burns most of a run’s tool calls, tokens, and latency, and it is pure overhead:
- Repeated. Every task pays the exploration cost again, from zero.
- Discarded. Whatever the agent figured out dies with the session.
- Unshared. The next teammate, and their agent, start from scratch too.
What Graft does
Section titled “What Graft does”Graft builds that understanding once and writes it into your repo as a folder of linked markdown files, one node per system, API, or concept.
- Real explanations, not a list of symbols. Each node says, in plain English, what a part of the system does and how it connects to the rest, the way a senior engineer would explain it. That is the part an agent actually needs so it can skip the exploration. It is not a dump of function names.
- A real graph you can read. No embeddings, no similarity search, no index to keep warm. The graph is a set of linked files your agent opens, greps, and follows, exactly the way it reads any other file in the repo.
- Grafted into git. The graph is just files in graft/. Commit it, and anyone who clones the repo has it. No database, no server, no setup. Git does the syncing, and a stale graph shows up as a diff in review instead of rotting in some external store.
- The diff lives with the code. When a change moves things around, you see it in the graph diff in the same pull request, right next to the code that caused it.
- Your provider, your key, your model. Summaries are written by any provider you choose — OpenAI, Anthropic (native), OpenRouter, Fireworks, Groq, a LiteLLM proxy, or a local model — under your own key. The structural code graph (
graft build,graft check) is deterministic tree-sitter and never calls a model at all.
