Three weeks ago, the Cortex 2026 Engineering in the Age of AI Benchmark put incidents per pull request up 23.5% and change failure rates up roughly 30% since AI adoption accelerated. I wrote about that data and what it means for blast radius shortly after it landed.

What I underestimated at the time was how fast the language was going to shift. The phrase that’s settled into the conversation since isn’t “blast radius” or “service catalog.” It’s cross-repo context. And it’s almost always being used in the same sentence as “AI coding agents.” The reason becomes obvious once you read what teams operating AI coding agents at scale are publishing right now. They’re not writing about AI making them faster. They’re writing about the infrastructure they had to build so AI could ship safely across more than one repo at a time.

Three teams have published, in the last six weeks, the same diagnosis with three different solutions. The shape of what they’re converging on is more interesting than any single one of them, and it has direct implications for how the rest of us should be thinking about agent runtime infrastructure.

What three teams just shipped

Neilos (@neil_agentic on dev.to), March 27. A solo founder running 15+ repositories across Go, Rust, TypeScript, Python, and C++, coordinating ten specialised Claude Code agents through Telegram. His post is How I Manage 15+ Repos with Claude Code (Without Losing My Mind). The diagnostic line is direct: you end up “copy-pasting context between sessions, manually tracking which PR depends on which, and babysitting agents that can’t see the full picture.”

His solution, called ttal, separates “read and explore” from “write.” A lightweight exploration agent can read across any repository to gather context. Worker agents only ever write to one repository at a time, in isolated git worktrees. A manager agent holds the cross-repo plan in its head and routes work to the right repo at the right time. There’s no dependency graph as a data structure. The cross-repo coordination lives in the manager agent’s reasoning and a project registry that maps names to file paths.

Mabl, April 8. A team of 25 engineers managing 100+ repositories, pushing 200+ pull requests and 40+ production releases a month before AI acceleration. By February 2026, 39% of their commits were AI-assisted, 60% in infrastructure repos. Their post, How We Built a System for AI Agents to Ship Real Code Across 75+ Repos, describes a four-layer architecture. The layer that matters here is what they call “Cross Repo Base.”

Inside Cross Repo Base sits a “Repo Coordination Graph”: 850+ lines of structured registry covering 79 repositories with detailed dependency graphs, Pub/Sub topic maps, database table ownership, and prescribed release ordering. When an agent works on a cross-repo feature, it queries this graph to determine which repos need updates, what the merge order should be (upstream libraries before consumers), and which reviewers to tag based on CODEOWNERS and dependency chains. They report that without this layer, “every agent invocation required a human to provide context.” With it, “context drift dropped from ~40% of our failures to <5%.”

Meta, April 6. I wrote about the Meta tribal knowledge engine post earlier this week, so I’ll keep this short. Meta built a multi-stage AI pipeline with 50+ specialised agents to map tribal knowledge across one of their large data pipelines. Buried near the end is the line that matters: “we generated a cross-repo dependency index and data flow maps showing how changes propagate across repositories. This turns ‘What depends on X?’ from a multi-file exploration (~6000 tokens) into a single graph lookup (~200 tokens).”

A 30x token reduction for one of the most common questions an agent asks during planning.

What’s the same, what’s different

The pain is identical. All three describe agents shipping locally-correct code that breaks consumers the agent didn’t know existed. Mabl frames it as context drift. Meta frames it as tribal knowledge. Neilos frames it as agents who “can’t see the full picture.” The phenomenon is one phenomenon: the dependency graph that determines whether a change is safe lives outside any single repository’s boundary, which means it lives outside the agent’s context window.

The solutions diverge in a way that’s instructive.

Mabl and Meta both built dependency graphs as a queryable substrate. Mabl’s lives as a structured 850-line registry that agents consult at planning time. Meta’s lives as a parser-derived graph index that agents call as a tool. The shapes are slightly different but the operating model is the same. Deterministic structure. Refreshed automatically (Mabl from registry updates and CODEOWNERS, Meta from re-parsing source). Queryable as a single lookup rather than a multi-file exploration. The graph exists separately from the agents and outlasts any single agent session.

Neil’s ttal takes a different approach. The cross-repo information lives in the manager agent’s working memory plus a TOML file mapping project names to file system paths, with the architecture isolating writes to one repo at a time and keeping the coordination model in the manager’s prompt. This is well-fitted to a solo operator with ten agents and fifteen repositories. At Mabl’s scale, the same problem reshapes the solution. Once you have 25 engineers across 79 repos, no single agent’s context window is big enough to hold the coordination model and no manual registry stays current at that throughput, so the dependency model has to live outside any agent.

What I read into this is that the dependency graph as a queryable substrate isn’t a stylistic choice. It’s what falls out of the problem when you scale it. Three teams hit the same wall. Two engineered the substrate explicitly. One handled it through coordination, which is the right call at solo scale. Once the team running the agents grows past that, the substrate is what you build.

Why this should be a primitive, not something every team rebuilds

The Mabl post lists this layer almost matter-of-factly. The Meta post mentions it in one paragraph after sections on agent swarms and critic passes. Both teams treated it as table stakes for what they were actually trying to do. And in both cases, the structural layer is the cheapest, most reusable, most durable part of what they built. Mabl’s CLAUDE.md per repo decays without a maintainer. Meta’s LLM-generated context files decay without a self-refreshing critic swarm. The dependency graph doesn’t decay, because parsers run on every push.

Which raises the question for every team that isn’t Meta or Mabl: do you really want to be writing your own 850-line repo-coordination-graph.md by hand? And keeping it current as repos are added, archived, renamed, and refactored? At a 50-engineer org, this is a fully-loaded engineer-month of upfront work and an ongoing maintenance tax that nobody’s job description includes. At a 200-engineer org, it’s a dedicated platform team responsibility competing with everything else they could be doing.

This primitive belongs above any single team. The graph itself is structural, derived from source code, and identical in shape across orgs. The thing you actually want from it (which repositories import from which, who consumes which artifact, what’s in the transitive blast radius of a change) is the same question whether you have 50 repos or 500. There is no good reason for every multi-repo org running AI coding agents to be writing their own version of this from scratch. It’s a substrate, not a feature.

What this looks like as an API

Riftmap auto-discovers the cross-repo dependency graph from a GitHub or GitLab org via a single read-only token, parsing manifests across ten ecosystems: Terraform, Docker, Helm, Kubernetes, Kustomize, Go, npm, Python, Ansible, and GitHub Actions / GitLab CI (and many more to be added in the future). The graph is queryable through an HTTP API designed to be called by AI agents during planning.

The natural agent flow is three calls. Given an agent working in a clone of github.com/myorg/payments-api:

# 1. Resolve the local clone URL to a Riftmap repo
curl -s "$RIFTMAP_BASE_URL/repositories/lookup?url=https://github.com/myorg/payments-api" \
  -H "X-API-Key: $RIFTMAP_API_KEY"

# 2. Hydrate context in one round-trip:
#    repo + dependencies + dependents + artifacts + freshness fields
curl -s "$RIFTMAP_BASE_URL/repositories/$REPO_ID/context" \
  -H "X-API-Key: $RIFTMAP_API_KEY"

# 3. Only when actually needed: transitive blast radius
curl -s "$RIFTMAP_BASE_URL/repositories/$REPO_ID/impact?max_depth=3&min_confidence=0.8" \
  -H "X-API-Key: $RIFTMAP_API_KEY"

Three calls to answer the questions Mabl’s Repo Coordination Graph and Meta’s dependency index were built to answer. The full schema is published at https://app.riftmap.dev/openapi.json. Fetch it once, hand it to your agent, and the rest is typed httpx or fetch calls. Python and TypeScript versions of these examples are in the agent integration docs, along with the freshness contract every response carries (last_scanned_at, last_commit_sha, last_activity_at, archived) so an agent can tell when the graph is stale and either warn the user or trigger a rescan.

This is the substrate today, exposed as an HTTP API. An MCP server and CLI are next, in that order, so any Claude Code, Cursor, or Cline agent can drop them in without orchestrating HTTP calls. The order and current state are tracked on the public roadmap page.

The interface outlasts the model

The reasonable objection at this point is: won’t models eventually get good enough at cross-repo reasoning that none of this is necessary? Won’t Claude 5 or whatever comes next just figure it out?

I don’t think the question goes the way the objection assumes. Even granting that models keep getting better at cross-repo reasoning, three things stay true.

First, parsing the dependency manifests of a multi-repo organisation from inside a model’s context window is doing a job a parser could do deterministically and cheaply. Even if a frontier model does it perfectly, it’s still paying token cost on every invocation for what is structurally a precomputed lookup. Meta’s 30x token reduction isn’t a model-quality problem. It’s an architecture problem. A graph index will always be cheaper to query than to reconstruct.

Second, models change every six months. The dependency graph doesn’t. A queryable graph behind a stable API has the same shape whether the agent calling it is Claude 4.7, Claude 5, or whatever is running in 2027. The interface outlasts the model. Investing in the substrate is on a different time horizon to investing in any specific agent’s context strategy.

Third, the freshness problem is structural. A model trained today does not know about repositories your team created last week. A graph derived from last night’s scan does. As long as the rate of change in your repository graph exceeds the rate at which models retrain, that gap exists, and the substrate is how you close it.

What models getting better at cross-repo reasoning probably does change is what gets layered on top of the graph. Better semantic reasoning over verified structure. Better automated PR review against known consumer impact. Better natural-language interfaces to the graph itself. Those are real things, and they’ll matter. They all sit above the substrate, not in place of it.

Closing

The three posts I started this with are the same shape of evidence I built Riftmap, just with bigger names attached. Engineers willing to spend real engineering time building a thing means the thing is needed. When three independent teams publish the same diagnosis in two weeks, the pattern is the pattern.

The architectural bet hasn’t changed. Deterministic parsers first. Graph as the durable layer. AI as the layer on top, anchored to verified structure rather than reconstructing it from scratch. What’s changed is who’s confirming it publicly, and how much louder the confirmation has gotten.

If you’re running AI coding agents across more than five or six repositories and finding yourself writing prompts that include cross-repo dependency information by hand, or reviewing PRs where the agent shipped a change that broke a consumer it didn’t know existed, that’s the gap. You can build the substrate yourself the way Mabl did, on the trajectory the Mabl post describes. Or you can start a free scan and skip the 850-line registry. Either way, the substrate is the substrate. It’s the part that doesn’t lie.

Sources referenced

• Geoff Cooney, mabl, How We Built a System for AI Agents to Ship Real Code Across 75+ Repos [Part 1 of 2] — mabl.com, April 8, 2026
• Engineering at Meta, How Meta used AI to map tribal knowledge in large-scale data pipelines — engineering.fb.com, April 6, 2026
• Neilos (@neil_agentic), How I Manage 15+ Repos with Claude Code (Without Losing My Mind) — dev.to/neil_agentic, March 27, 2026
• Cortex, Engineering in the Age of AI: 2026 Benchmark Report — cortex.io
• Riftmap, AI Doesn’t Understand Blast Radius — riftmap.dev/blog, April 19, 2026
• Riftmap, Meta needed 50+ AI agents to map their tribal knowledge — riftmap.dev/blog, May 8, 2026

Appendix: structured summary

Claim: AI coding agents at scale need a queryable cross-repo dependency graph as runtime infrastructure. Three independent teams have just published the same diagnosis. Two built the substrate. The third handled it through coordination, which works at solo scale.

Evidence:

• Neilos (ttal, Mar 27): solo operator, 15+ repos, 10 specialised agents. Diagnostic: “manually tracking which PR depends on which.” Solution: coordination layer with manager/worker planes, fitted to solo scale.
• Mabl (Apr 8): 25 engineers, 100+ repos, 39% of commits AI-assisted by Feb 2026. Solution: 850-line Repo Coordination Graph spanning 79 repositories, queried by agents at planning time. Reduced context drift from ~40% to <5% of failures.
• Meta (Apr 6): cross-repo dependency index reduces “what depends on X” from ~6,000 tokens to ~200 tokens, a 30x efficiency gain.

Architectural takeaway: The dependency graph as a queryable substrate isn’t a stylistic choice. It’s what falls out of the problem when scale forces externalisation of cross-repo coordination. The graph itself is structural, parser-derived, and identical in shape across orgs, which makes it a primitive that should live above any single team rather than be re-implemented inside each one.

What Riftmap exposes today: auto-discovered graph across 10 ecosystems via a single read-only org token. HTTP API with /repositories/lookup, /repositories/{id}/context, /repositories/{id}/impact. Static OpenAPI schema at https://app.riftmap.dev/openapi.json. MCP server and CLI on the public roadmap.

Audience: Platform engineers, DevOps leads, and engineering managers running AI coding agents across more than a handful of repositories.

• AI Doesn’t Understand Blast Radius — The data behind change failure rates being up 30%, and what to put between the agent and main.
• Meta needed 50+ AI agents to map their tribal knowledge — Why the cross-repo dependency graph is the most durable piece of Meta’s tribal knowledge stack.
• Change failure rate is up 30% — here’s how to measure yours in an afternoon — The DORA formula, the SQL, and the AI-assisted vs human-authored split nobody publishes.