{"slug": "a-code-graph-for-agents-that-spans-repos-and-parallel-features", "title": "A code graph for agents that spans repos and parallel features", "summary": "A developer built `ivar graph`, a cross-repository code graph for coding agents that keeps a shared SQLite base index of each repo's default branch and per-feature layers holding only changed files, so agents working on parallel feature branches see their own edits without duplicating the rest of the repo. The MCP server reindexes stale layer files before every query — about 18 ms per call on a feature with 177 changed files — and fails loudly rather than answering from the base when a layer cannot be refreshed. In a two-repo Fastify/React fixture, agents with the graph were compared against the same model and prompt without it.", "body_md": "Watch a coding agent start on an unfamiliar change and most of the early turns\n\nlook the same. It greps for a name, opens three of the matches, finds an import,\n\nopens that file, greps for the caller, opens two more. Each read puts a whole\n\nfile into context, most of which has nothing to do with the question. By the\n\ntime it knows where the change goes, it has spent a large share of its budget on\n\nnavigation.\n\nA code graph shortens that loop. If the agent can ask \"who calls\n\n`renderInvoice`, and what does it touch\" and get the answer with the relevant\n\nsource attached, it skips the grep-read-grep cycle. That part is not new.\n\nTwo things about how `ivar` is used made the usual shape of a code graph a poor\n\nfit.\n\n**The change spans repositories.** A hall mounts an API, a web client and a\n\nshared package side by side. The interesting edges are between them: the web\n\nclient's HTTP request and the API route that serves it, or a\n\ntype exported by the shared package and used in both. An index built per repo\n\ndoes not have those edges.\n\n**Several features run at once.** Each feature is its own branch, checked out as\n\nits own set of worktrees, often with an agent working in each. A graph scoped to\n\na folder is built for one checkout. Point it at five feature checkouts and you\n\neither index the same repo five times or answer every session from one of them,\n\nwhich means some agents see code that is not on their branch.\n\n`ivar graph` keeps a single SQLite database for the hall at `.ivar/memory.db`.\n\nIt holds a **base index** of each repo's default branch, shared by every\n\nsession. On top of it, each feature gets a **layer** that holds only the files\n\nthe feature changed, committed or not.\n\n*A feature session reads its own layer first and the base for everything else. A discovery session reads the base.*\n\nA feature usually changes tens of files, so a layer is small next to the base.\n\nQueries from a feature session resolve symbols against the layer first and fall\n\nback to the base, which is how an agent sees its own edits without the graph\n\nduplicating the rest of the repo.\n\nExtraction uses tree-sitter and runs in parallel. Base indexing is incremental:\n\n`ivar` diffs each repo against the commit it last indexed and checks file size\n\nand modification time, so a rerun parses only what moved.\n\nA layer goes stale the moment the agent edits a file. Asking the agent to call a\n\nreindex tool after each edit works until it forgets. So before every query the\n\nMCP server compares the layer with the worktree and reindexes the files that\n\nchanged.\n\nThat check has to be cheap to run on every call. On a feature with 177 changed\n\nfiles it took about 18 ms per call, and about 21 ms right after an edit.\n\nIf the layer cannot be refreshed, the call fails with an error. It does not\n\nquietly answer from the base: an answer about code that is no longer on disk is\n\nthe kind of wrong an agent acts on with confidence.\n\nThe MCP server advertises one tool by default, `graph_explore`. The agent passes\n\nsymbol names, paths, or a short intent, several at once. The answer includes:\n\n`Next:` call with a `paths` argument listing the files that did not\nfit.\nThe source is the part that removes reads. The `Next:` hint is the part that\n\nkeeps the agent from falling back to opening files one at a time: a follow-up\n\nwith `paths` returns up to 12 whole files in one call.\n\nThe other tools (callers, impact, affected tests, paths and more) are available\n\nbehind `ivar graph mcp --tools all`, and the queries have CLI equivalents, which\n\nmatters for providers such as omp that do not pass MCP servers to subagents. A\n\nsubagent can run `ivar graph explore renderInvoice` in a shell and get the same\n\nanswer.\n\nWe ran agents on the same fixture with and without the graph, using the same\n\nmodel and the same task prompt in both arms. The fixture is two repositories: a Fastify API and a\n\nReact web app that calls it.\n\nThe agent explores the fixture to answer a question about how the code works,\n\nand its answer is scored against a hand-built answer key. Three runs per arm.\n\n|  | With `ivar graph` | Without a graph | \n|---|---|---|\n| Median tokens | 460k | 738k | \n| File reads | 0 | 12 to 28 | \n| Answer-key coverage | 93 to 94 % | 91 to 94 % | \n\nThe graph arm answered as completely while reading no files; the source it\n\nneeded arrived inside the query results. Tokens fell by about 38 %.\n\nThe agent implements a change in the fixture that has to pass an acceptance\n\nsuite. Five runs per arm, and every run in both arms passed.\n\n|  | With `ivar graph` | Without a graph | \n|---|---|---|\n| Median tokens | 1.53 M | 1.61 M | \n| Median file reads | 6 | 26 | \n\nHere the token saving is small, about 5 %. Most of an implementation run is likely\n\nspent editing, running tests and reading their output, and the graph does not\n\nhelp with that. File reads still fell from 26 to 6, and the reads that remain\n\nare the ones the provider requires before it lets an agent edit a file.\n\nThe fixture is small, so we also measured the graph on a working hall of about\n\n29,000 files, which indexed to 144,000 symbols and 1.9 million edges.\n\n| Measure | Result | \n|---|---|\n| Index size | 370 MB | \n| Cold index | 77 s | \n| Reindex, no changes | 0.17 s | \n| MCP server startup | about 5 ms | \n| `graph_explore` | 12 to 80 ms | \n| Callers query | 0.4 ms | \n| Impact query | 0.2 ms | \n\nThese are small samples: three and five runs per arm, on one fixture, with one\n\nmodel. The discovery answer key was built by hand, so coverage is a judgment against\n\nit, not an absolute measure. Token counts vary run to\n\nrun, which is why the tables report medians and ranges rather than a single\n\nnumber. The implementation result in particular should be read as \"fewer reads\n\nfor about the same cost\", not as a large saving.\n\nBuild the index from the hall root:\n\n```\nivar graph index\n```\n\nThe first run also registers the graph MCP server in `ivar.json` (pass\n\n`--no-mcp` to skip it).\n\nThen run `ivar sync` to write the provider configs, and start a feature session.\n\n`ivar sync` also keeps the base index current from then on, and `ivar doctor`\n\nreports repos whose index has fallen behind.\n\nThe [Code graph guide](https://ivar.run/docs/guide/graph) covers layers and limits, and the\n\n[reference](https://ivar.run/docs/reference/graph) lists every subcommand and MCP tool.", "url": "https://wpnews.pro/news/a-code-graph-for-agents-that-spans-repos-and-parallel-features", "canonical_source": "https://dev.to/mnzs/a-code-graph-for-agents-that-spans-repos-and-parallel-features-dme", "published_at": "2026-09-29 16:14:30+00:00", "updated_at": "2026-09-29 16:17:01.918552+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-tools", "mlops"], "entities": ["ivar", "MCP", "SQLite", "tree-sitter", "Fastify", "React", "omp"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/a-code-graph-for-agents-that-spans-repos-and-parallel-features", "markdown": "https://wpnews.pro/news/a-code-graph-for-agents-that-spans-repos-and-parallel-features.md", "text": "https://wpnews.pro/news/a-code-graph-for-agents-that-spans-repos-and-parallel-features.txt", "jsonld": "https://wpnews.pro/news/a-code-graph-for-agents-that-spans-repos-and-parallel-features.jsonld"}}