The Monorepo Advantage for AI Agents

Despite the investment, many organizations don't see the expected return after adopting AI agents. In this post, we examine how monorepos can make AI agents more effective, especially in larger organizations.

The Three Walls: Read, Write, Memory

Many software systems are highly complex and spread across hundreds of repositories. Different products and teams rely on code and services from other repos. When you launch an agent in this environment, it hits three walls.

Read: no cross-project context

In a polyrepo, an agent sees one project at a time, blind to how changes propagate across the system. Change a UI component library, and the agent has no idea which applications consume it or how they'll break. Similarly, when building a frontend form, the agent cannot see how the backend works and may miss important edge cases.

In a monorepo the agent sees the whole codebase. It understands dependencies, proposes consistent changes, and catches downstream impacts before they become bugs.

Write: no way to land cross-project changes atomically

When a change touches multiple repos, you're stuck coordinating separate PRs, managing backwards compatibility, and sequencing merges carefully. The agent might do the coding work, but developers still carry the cross-project, cross-team coordination burden. Every handoff to a human makes agents less autonomous.

In a monorepo, an agent can modify 20 projects in a single PR. One review, one approval, one merge.

Memory: repo boundaries isolate contexts (aka the "Memento Problem")

Every repo boundary wipes the agent's context. You update Repo A with an agent on Monday, then open Repo B on Thursday and try to re-explain what you did and why. In a monorepo, the agent works in one continuous context. It might still make mistakes, but they're coherent mistakes that are easier to spot and fix.

What the Evidence Shows

Cross-project and cross-cutting changes make up as much as 20% of commits, but they're disproportionately expensive. They're larger, more complex, and can drag on for months or years.

A trivial change to a library that affects its clients can take multiple weeks in a polyrepo and just a day with an Nx monorepo. That's the everyday case. The extreme case: Airbnb compressed an 18-month migration down to 6 weeks using agents in a monorepo. AI agents excel at exactly this kind of work, but only in the right environment.

Here's a side-by-side demo comparing the time spent on a cross-project change in a monorepo and a polyrepo:

Even in this small example, a developer using an agent in an Nx workspace completed the work 4x faster with far fewer interruptions. In real organizations, where coordination costs are higher and delays (code reviews, approvals, context switches across teams) compound, the gains are significantly higher.

Because different tasks benefit to varying degrees, improvements typically look like this:

That's a 1/3 reduction in total effort.

The Second-Order Effects Are Much Greater

The 1/3 gain understates the real impact. In polyrepo environments, cross-project work is so painful that teams avoid it. They duplicate code instead of sharing it. They defer refactors. They let inconsistencies accumulate. The friction isn't just slowing work down. It's preventing work from happening at all.

Remove that friction, and large-scale refactors, API migrations, and shared library upgrades become feasible. Agents can propose sweeping improvements that would have been unthinkable before. The productivity gains compound as organizations unlock work they'd previously written off as too expensive.

Monorepos and Agents Are Good for Each Other

Monorepos make large-scale changes broad by definition: update a shared library, and every consumer may need to change. Nx has always had migrations that automate the predictable parts of that work. Agentic migrations, introduced in Nx 23, use an agent to handle the workspace-specific parts.

This goes beyond migrations. Agents can perform cross-project refactors, API changes, and library upgrades across the repository. Because they can update and validate every affected project together, the scale of a monorepo becomes an advantage rather than a liability.

Synthetic Monorepo

Most organizations do not have a single repository, including those that embrace the monorepo model. Consolidating everything is difficult for both technical and organizational reasons. But for agents, a monorepo is not really a place. It is a set of properties: an agent can read the whole system, write to everything affected by a change, and carry context from one piece of work to the next.

Within a repository, Nx provides those properties. Until now, they stopped at the repo boundary. To provide the same behavior to organizations that cannot move all their code into one repository, we built Polygraph, an agent-agnostic meta-harness.

It removes the same three walls across the organization:

• Read: it connects all your repos, private and public, into one dependency graph without moving any code, so the agent sees the whole system.
• Write: the agent writes across every repo you can access and orchestrates the PRs and CI as a single change.
• Memory: every session is recorded, so any agent, on any machine, can resume or build on work done by anyone. The Memento Problem disappears: the agent goes from having no memory to having eidetic memory.

In other words, Polygraph extends the properties of a monorepo across an entire organization, creating what we call a synthetic monorepo.

A synthetic monorepo does not eliminate the value of an actual monorepo. Cross-repo changes still involve some friction: Polygraph orchestrates writes across repositories, but each write must still land independently, so the overall change is not atomic. One way to think about the difference is that an Nx workspace gives you a strongly consistent monorepo, while Polygraph gives you an eventually consistent one.

Learn more

• 🚀 Polygraph
• 📖 Meta Harness
• 🧠 Nx Docs