Monorepo vs Polyrepo Tradeoffs for Agentic Software Factories

The question of whether to keep code in one repository or many was settled for most engineering organizations years ago, each side having made peace with its tradeoffs. AI coding agents reopened it by changing who does the work: the basic unit of software development shifted from a developer writing a patch to an agent that reads a codebase, reasons about it, edits files, runs tests, and only then surfaces a pull request. That shift matters because agents don't navigate code the way people do. A human engineer can hold a system in their head even when it spans repositories. An agent's grasp of a codebase is bounded by what it can read inside a single context window, which turns repo boundaries from an organizational convenience into a hard technical limit on what an agent can see and safely change. Riftmap's post traces the specific sequence that pulled the debate back into the open: an AI coding vendor re-argued the monorepo case for the agent era, a benchmark firm published PR cycle-time data spanning hundreds of organizations, and platform engineering discussion threads converged on the same question, all inside a six-month window. This piece works through what changed, what the data says about cost, and where each structure still holds up when agents are doing the work.

How agents experience repo structure differently than humans do

The real driver behind every tradeoff discussed in this piece is context: an agent's working memory of a codebase is only as large as what it can load and process in one sitting, and that limit is what makes repo boundaries function as walls rather than lines on an org chart. Nx's analysis identifies three specific walls agents run into inside polyrepo setups. The first is a read wall: an agent working in a frontend repository has no visibility into the backend repository unless someone explicitly feeds it that content, so it can write code against an interface without ever seeing the implementation behind it, and the mismatch often isn't caught until deployment. The second is a write wall, since cross-project changes require coordinated pull requests across multiple repositories, version bumps, and carefully sequenced merges, work that either falls back onto a human to manage or requires an agent to juggle simultaneous checkouts, a setup that's harder to configure and harder for a reviewer to check. The third is a memory wall: crossing a repo boundary wipes an agent's working context, so it has to re-explain on Thursday, in a different repo, what it already figured out on Monday, a repeated reset that amounts to a "Memento Problem" playing out at the scale of an entire engineering organization.

This isn't a theoretical concern raised only by infrastructure vendors. Defract's analysis draws on practitioner experience and finds founders running parallel agents across multi-repo setups reporting the same failure pattern over and over: changes that look clean when reviewed inside one repo generate integration problems once merged, precisely because the agent that wrote them couldn't see across the repo boundary to begin with. The contrast with monorepo behavior is concrete. Inside a monorepo, a Claude Code agent can trace a single data type starting at the database schema, through the API layer, into the frontend component that renders it, all within one session. In a polyrepo, that same agent has to infer the contract between those layers instead of verifying it directly. None of this settles which structure is better. It explains why the two structures now produce qualitatively different failure modes for agents than they ever did for people, and why the sections that follow treat repo structure as a constraint on agent capability rather than a matter of team preference.

Monorepo Operational Cost in the PR Cycle-Time Data

None of the context advantages monorepos offer agents come free. Monorepos carry real, measurable operational overhead, and most teams don't notice that cost until the repository has grown past the point where a basic CI setup can keep up. The cost follows a maturity curve rather than a flat tax. An early-stage monorepo, with a shared repo freshly introduced, basic CI, and manual review routing, produces PR cycle times that are both slow and unpredictable. As the repository grows, CI pipelines expand and ownership boundaries multiply, and tail latency gets worse before it gets better. Only once a monorepo reaches real maturity, with incremental builds, optimized CI, and automated review routing in place, does PR cycle time recover to something teams would call fast.

That maturity curve is the honest version of the monorepo story: the infrastructure has to keep evolving alongside the size of the repository, and when it falls behind, the lag appears directly in how long a PR takes to land. Composable infrastructure platforms built for software factories let teams upgrade one layer at a time, the merge queue, code storage, or signal routing, without tearing out and replacing the whole system, which is what lets a team mature its monorepo operations in stages rather than in one disruptive rebuild. Polyrepos, by comparison, tend to produce a tighter and more predictable cycle-time range, but that predictability comes at a price: the cycle-time number never includes the coordination cost of work that spans repositories. Instead that cost appears later, as coordination failures, mismatched versions, and integration bugs, which cycle-time metrics were never built to capture (addressed more fully in the merge queue section below). The infrastructure investment a monorepo demands carries a real cost in engineering time and complexity, and that same infrastructure is the condition under which agent advantages at the context layer actually pay off, a point the next two sections build on directly.

The Merge Queue as the Binding Constraint Under Agent-Driven Pipeline Load

Agents have made writing code the cheap part of shipping software. They have not made landing that code any cheaper, and that gap moves the bottleneck from how fast a developer can write a patch to how fast the merge queue can absorb it, regardless of repo structure. If merge-group CI takes tens of minutes from start to finish, a strictly ordered queue can only get through a modest number of pull requests in a given day. A team where each developer runs several agents in parallel can triple the rate at which PRs arrive while the rate at which the queue can process them stays fixed, and basic queuing theory says wait times don't rise gradually as arrivals approach that capacity limit, they explode.

Agents also amplify flakiness in a way human commit patterns never did. An agent told simply to "get the PR merged" will re-queue the same change repeatedly when a test fails, burning a full CI run on every attempt, and that retry pattern triggers cascading failures for every other PR stuck behind it in line. A retry loop that was mildly wasteful at the frequency a human would attempt it becomes something close to a denial-of-service attack once an agent is running it at agent frequency. Plaid's experience shows what this looks like at scale: as its monorepo grew to hundreds of commits a day, running without a merge queue became untenable, so its Developer Efficiency team set a target of five minutes median merge queue latency and, by late August 2025, pushed the median down to well under two minutes. Getting there wasn't free: turning on a naive "build everything" configuration caused a sharp, unexpected spike in remote Bazel cache load, and the team had to double the size of its caching cluster to absorb it.

BMW's case shows the same constraint, but under a different kind of load. The monorepo that holds BMW's driving dynamics and autonomous driving software stack runs roughly an hour of testing per pull request. A strictly sequential merge pipeline at that testing cost would clear only a few dozen PRs a day, but BMW merges hundreds of changes daily across its merge pipelines, and PRs still wait close to an hour before processing even starts. RunPod's story is a reminder that the fix isn't always more compute. RunPod cut its merge-queue CI time in half by fixing an architectural flaw rather than throwing hardware at the problem: every test had been authenticating as the same shared user, so running tests in parallel caused them to corrupt each other's state, and the resulting flakiness had been wrongly blamed on parallelism itself.

The throughput constraint doesn't disappear in a polyrepo, it just relocates. Polyrepos keep per-repo PR volume lower, which keeps individual queues shorter, but the coordination cost of a change that spans repositories reappears as multi-repo merge orchestration instead. Each one just decides where in the pipeline that cost gets paid.

Conditions where each structure holds its ground for agentic workloads

Nothing in the preceding sections should read as a verdict for one structure over the other. The evidence instead points to a set of conditions, and the right answer depends on which conditions describe a given engineering organization.

Monorepos hold their ground where cross-project changes are frequent and where the changes being made are exactly the kind agents are best suited to handle. Nx's own data shows cross-cutting changes account for as much as a fifth of all commits in some organizations, and those are disproportionately expensive to coordinate by hand. An agent working inside a monorepo can resolve a change like that in a single PR instead of threading an orchestrated sequence of PRs across separate repositories. Large-scale refactors show the same advantage at bigger scale: Airbnb compressed a migration into 6 weeks by using agents inside a monorepo, where the same migration inside a polyrepo would have required managing backward compatibility and carefully sequencing merges across every affected repository. Block's migration makes the infrastructure case directly: roughly 450 JVM repositories were consolidated into a single monorepo that now handles thousands of builds a week with a P90 CI time of 10 minutes, achieved through dependency graph-based builds and selective CI, evidence that the throughput constraint described in the previous section is solvable given mature enough infrastructure.

Polyrepos hold their ground under a different set of conditions. If a public API has external partners that depend on a versioned, pinned contract, it genuinely benefits from living in its own repository, because an agent working on it only needs that repo's surface and never needs visibility across a boundary it has no business crossing. Regulated environments, finance, medical, defense, favor polyrepo structure for a related reason: a polyrepo setup allows access to specific codebases to be restricted cleanly, where a standard Git monorepo tends to make access an all-or-nothing proposition. The most honest counter-evidence on the polyrepo side comes from Allen Hutchison, who points out that a pull request in a split-out service clearing CI in roughly two minutes, against thirteen minutes for equivalent work inside a monorepo, is a genuine, engineering-tractable advantage: compute time is the one delay in this entire system that can be addressed directly, simply by shrinking what the test suite has to know about. Alongside Airbnb's and Block's cases as positive monorepo evidence, that two-minute number against thirteen minutes is the most honest counter-evidence a polyrepo advocate can point to. Taken together, these cases describe conditions, not a champion: the right structure depends on how often an organization needs cross-cutting changes versus how much it needs isolation, versioning discipline, or compliance-grade access control.

How AGENTS.md files and session memory shape agent behavior across repo structures

Repo structure sets the ceiling on how much context an agent can reach, but it doesn't guarantee the agent reaches it. AGENTS.md files and persistent memory patterns determine how much of that ceiling gets used, and teams that ignore this layer leave performance on the table no matter which repo structure they've chosen. A 2026 arxiv study found that simply having a root AGENTS.md file present is associated with lower token usage and faster wall-clock runtime on real pull requests, with task completion quality holding steady, which makes it one of the few repository-level interventions with a measured effect on agent behavior. GitHub's review of more than 2,500 repositories that include an AGENTS.md file found the strongest examples consistently cover six areas: the commands to build, run, and test the project; how testing actually works; a short map of the repo's structure; code style conventions; the git workflow; and explicit boundaries on what the agent should and shouldn't touch.

Inside a monorepo, AGENTS.md files can be nested at multiple levels of the directory tree, and agents combine instructions from the root down to the specific file being edited, with the closest file taking priority whenever instructions conflict. OpenAI's own repository carries 88 such files. For the memory wall described earlier, the practical fix is a persistent memory pattern: anything that needs to survive past the end of a session gets written to a file, and before closing out a long session, the agent is asked to record what it decided, what it completed, and what comes next, so the next session can start by reading that file and picking up where the last one left off. That pattern directly addresses the Memento Problem in polyrepo setups where the repo boundaries themselves can't be changed. Checks, code reviews, and production signals round out the loop: they tell an agent what went wrong well enough that it can correct course without waiting on a human to intervene, and that feedback loop works regardless of repo structure, compounding further when it's paired with a well-built AGENTS.md file.

What the merge queue and pipeline layer must do with agents as primary committers

Repo structure shapes how well an agent works, and so does AGENTS.md discipline. The merge queue and CI pipeline sit between agent output and a shipped change, and that's the operational layer where agent volume either gets absorbed cleanly or triggers cascading failures, largely because those systems were built for human commit rates. Pipelines built around human behavior don't handle the failure modes agents introduce well. Retry amplification is one: an agent told to get a PR merged will re-queue it repeatedly on failure, turning what would have been a single flaky test into a sustained, extended load event on CI rather than an isolated incident.

Plaid's doubled Bazel caching cluster and BMW's near-hour-long queue wait, both described earlier, are what this failure mode looks like once it reaches production scale. RunPod's experience is the reminder that the fix is sometimes architectural rather than something more compute can solve. If you're weighing a move toward agent-heavy development, you need visibility into where agents actually lose context across repo boundaries and which kinds of changes suffer most from it, because that data is what lets you weigh the cost of consolidating into a monorepo honestly against the cost of staying split. Agent transcript analysis tools exist to surface that pattern, and Vex's agent transcript analysis capability is built for exactly this kind of diagnostic work, so you can see where context loss actually occurs instead of guessing. The repo structure debate resurfaced because the unit of work changed. The merge queue and the pipeline built to process that work are where the consequences of that change either get managed or they don't.