I have been using coding agents extensively as they have become more useful. It has resulted in developing several projects in my lab.

The expensive part for a coding agent is not usually the edit. It is the first few minutes: grepping, opening files, and rebuilding a mental model of a codebase the agent has already seen before. Especially if you are working on an existing project.

I set up Graft for the coding agents in lab.kudithipudi.org so they can share a prebuilt view of each repository instead of re-deriving it in every session.

npm install -g @nanonets/graft
cd /var/www && graft init --yes

Graft builds a local context graph for a repository:

• Markdown notes describing systems, with exact file:line references
• A graph of call relationships
• A small set of commands agents can query before they start reading source

In some of my recent coding sessions, Graft reported roughly 80% tokens saved per repository compared with reading the files it covered. Whether that number is exact is less important to me than the behavior change: agents start with an architectural view instead of treating every session as a cold start.

The setup has three parts.

A generated graph
Graft writes markdown and wiring data into graft/. I keep it out of git because it is deterministic and easy to rebuild graft build . There is no API key, embedding pipeline, or hosted service involved.

1. Agent wiring
   graft init adds an AGENTS.md block, a skill, and MCP configuration to the repo. Claude Code and OpenCode (agents I am playing with now) can use those conventions, so I do not need separate context setups for every agent. Most of the popular agents use the same pattern.
2. A parent-level index
   I ran graft init once at /var/www where I have all my projects hosted. That gives sessions started there a federated view across the projects below it, with results labeled by repository.

The practical benefit is that the graph stays current. Graft installs Claude Code hooks during initialization: a session-start hook tells the agent to use the graph first, and edit/stop hooks sync it after changes. Queries also refresh before answering, including against uncommitted edits.

That matters because a stale index is worse than no index.

I looked at these alternatives, but did not test them deeply:

• Aider’s repo map is useful prompt-time context, but it is not a persistent graph that multiple agents can query.
• Serena provides strong LSP-based symbol navigation, but I wanted a persistent prose layer that I could browse too.
• Cursor and Windsurf provide retrieval within their own environments.
• Repomix and gitingest flatten repositories into context files. They move the token cost around rather than reducing the amount of source an agent needs to inspect.