Spend an hour reading the support forums for any of the big coding agents right now and you will notice the same thread, over and over, in slightly different words. Someone has their codebase split across a handful of repositories. They point an agent at it. The agent can only see one repo. They want it to see the rest.
This is not a niche complaint. It is one of the loudest things engineering teams are asking for in 2026, and the vendors have heard it. In May, Cursor shipped multi-repo environments for its cloud agents, so that a single environment can hold every repository an agent needs. On the GitHub side, Copilot’s cloud agent still runs inside the single repo where the task was opened, and the community has built its own cross-repo workarounds with MCP servers and scoped tokens while a native solution is expected. Agent HQ is pulling Copilot, Claude and Codex into the same GitHub workflows. Everyone is racing in the same direction.
I want to be generous about this, because it is genuine demand validation and I have been saying for a while that multi-repo work is where agents earn their keep. But I also want to name what the race is actually about, because I think most of the industry has quietly mislabelled the finish line.
The race is about access
Read the threads closely and the problem is always the same shape. Can the agent clone the other repo. Does the token have the right scope. Will the environment hold all seven repositories. Can a build secret reach the running agent. This is real, fiddly, important work, and it is also plumbing. It is the difference between an agent that can reach your code and one that cannot.
Plumbing gets solved. It always does. The gap between a single-repo agent and a multi-repo one is a few releases of integration work, and the largest, best-funded tooling companies in the world are spending those releases right now. If your mental model is “multi-repo is hard because access is hard,” that model has a short shelf life. Within a couple of quarters, access across repositories will be a checkbox.
So it is worth asking what is left once the checkbox is ticked.
The quiet conflation
Here is the sentence I want to sit with. When Cursor announced multi-repo environments, the framing was that with several repos in scope, agents can “reason about how a change in one part of the codebase affects others.”
That is a reasonable thing to say, and at the level of code symbols it is often true. But notice the move inside it. It slides from “the agent can see the repos” to “the agent understands how they depend on one another,” and those are not the same claim. The first is about scope. The second is about structure. Scope is necessary for structure. It is nowhere near sufficient for it.
This is the conflation running underneath the whole multi-repo race. Access is being sold, understandably, as understanding. Putting the repositories in front of the agent is treated as the hard part, and the assumption is that comprehension follows for free once the files are reachable. It does not, and the reason it does not is in how these agents actually work out what depends on what.
How an agent actually resolves a cross-repo relationship
Once an agent has all your repos in scope, it still has to answer the question that matters: if I change this, what else breaks. There are three families of technique it can use, and it is worth being precise about each, because none of them is built for the thing I care about.
The first is agentic search, which is where Claude Code and several others have landed. No index, just grep and read, the model navigating the tree the way a person would. There are good arguments for this: grep returns a broad cluster of matches from which the model can infer the codebase’s organisation and naming conventions. The key word is infer. The structure is reconstructed from text and from names, and names lie. A service called payments-api and a Terraform module called payments may be tightly coupled or completely unrelated, and grep cannot tell you which.
The second is retrieval over embeddings, the classic RAG approach, which is what codebase indexing in editors leans on. This is semantic similarity over chunks of code. It is excellent at “show me code that looks like this” and it is still, fundamentally, operating on the text. Similarity is not dependency. Two files can be deeply coupled and read nothing alike, and two files can read almost identically and never touch each other in production.
The third, and the most rigorous, is a real symbol graph. Sourcegraph’s SCIP is the best example, and I have a lot of respect for it. It powers cross-repository code navigation: click a function in one repo and jump to its definition in another, compiler-accurate, no pattern matching. But look at what SCIP actually indexes. It was built to index programming languages to power go-to-definition and find-references, with a separate language-specific indexer for each language, scip-typescript, scip-python, scip-java, scip-clang. The unit is the programming-language symbol. Cross-repo, yes. But cross-repo symbols.
Where the edges actually live
Here is the problem with all three. The dependency that wrecks your afternoon on a multi-repo change is usually not a function call.
It is the Terraform module in one repo that sources a module in another. It is the Helm chart that deploys an image tag built somewhere else entirely. It is the service whose CI pipeline publishes an artifact that three other pipelines consume. It is the base image in a Dockerfile that lives in a platform repo two teams over. These are the edges that turn a one-line change into an incident, and they share two awkward properties.
They are not programming-language symbols, so the symbol graph, however precise, never sees them. SCIP resolving a TypeScript import across repos is genuinely useful and completely blind to the fact that the same repo’s Helm values point at an image your change just rebuilt.
And they are not reliably inferable from text or names, so grep and embeddings can only guess at them. The guess is sometimes right, which is the dangerous part, because it is right often enough to be trusted and wrong often enough to hurt.
These edges are, however, declared. Precisely, deterministically, in the manifests: the Terraform source blocks, the Helm value references, the image tags, the CI artifact names, the package manifests across every ecosystem in the org. The information is not missing. It is sitting in the files, in a form that has to be parsed rather than inferred. I have written before about finding every consumer of a thing across an org and about why you do not need a virtual monorepo to do it. The short version: parse the manifests, per ecosystem, and the graph is just there.
Why this gets worse as agents get better
You could argue this gap has always existed and teams have muddled through. True. What changes the stakes is autonomy. Cursor has said that roughly a third of its own merged pull requests are now opened by agents, and that number has been climbing. Multiply that by an agent that can now touch seven repos in a single session.
An agent operating across a multi-repo system on an inferred map is simply a faster way to ship a cross-repo break. It will make the change confidently, because the relationship it could not see did not show up in its grep results. And then the change lands in front of a human reviewer who is verifying against the exact same blind spot, because the reviewer is also reading the diff and reasoning about blast radius from memory and naming.
This is the part I keep coming back to. The agent making the change and the engineer verifying it need the same thing, and it is not more access. It is a shared, structural account of how the system is actually wired. They need to be looking at the same map, and right now neither of them has one.
The layer nobody upstream is parsing
So this is the bet. Access across repositories is being commoditised in front of us, fast, by companies far larger than mine, and that is fine, because access was never the interesting part. The interesting part is the cross-repo dependency structure, and the reason the incumbents are not parsing it is not that they cannot. It is that their retrieval is built on inference and on language symbols, and parsing infrastructure manifests deterministically across ten or more ecosystems sits at an angle to how their systems are designed.
That is the layer I am building Riftmap to be. It scans a GitLab or GitHub org, parses the manifests across all the ecosystems that actually carry the dependency edges, and produces one queryable graph that answers “if I change this repo, what else breaks.” Not inferred. Parsed. The same map for the agent and for the person reviewing what the agent did.
Give an agent every repo in your org and you have given it access. You have not given it the map. Those are different gifts, and the second one is the one that stops the change from breaking three services you forgot were downstream.