Here is a failure that has a clean git history and a production incident attached to it. An agent renames a field in a backend service. The backend tests pass. The change is correct, locally. It merges. And a frontend in a different repository, one that parsed that field, breaks the moment it deploys. Nothing was wrong with the change where it was made. The problem was that the change reached beyond the repository it lived in, and no single repository's tests could see the far side of the boundary. This is cross-boundary breakage, and it is one of the most common ways an agent's correct work becomes a broken product.
The lesson is old and predates agents entirely: the interface between parts of a system is where risk concentrates. Agents just hit it more often, because they operate at the level of a single repository and the product usually is not one.
Why the boundary is the blind spot
Inside a single repository, you have a safety net that catches most mistakes. The compiler checks types, the tests check behavior, and CI checks that the whole thing still hangs together. A wrong change usually turns something red before it can escape.
Across a boundary, that net has a hole in it, because nothing compiles the whole product at once. The backend and the frontend build separately, test separately, and deploy separately. A change to a shared contract, an API shape, an event, a database column another service reads, is checked only against the repository where you make it. The repositories that depend on it are not in scope, so their expectations are never tested against the new reality. The change is safe where it is written and dangerous everywhere it is consumed, and the tooling that would normally catch the danger is looking at the wrong repository.
An agent working inside one repository inherits exactly this blind spot, and it inherits it more severely than a human, because it often cannot even see the consumer that is about to break. It optimizes for the task in front of it, the change compiles and passes, and it reports success in good faith, having no way to know it just broke something it was never shown.
The specific shapes it takes
Cross-boundary breakage clusters around contracts, the agreed shapes that let separate parts talk to each other.
Renames and removals. Removing or renaming a field, an endpoint, or an event is safe in the producing repository and breaks every consumer that referenced the old name. This is the classic case, and it is why deletions deserve special caution.
Silent shape changes. Changing a type, making an optional field required, or altering the meaning of a value passes the producer's tests while quietly violating what consumers assumed. Nothing errors at the boundary, it just behaves wrong downstream.
Ordering across deploys. Even a correct contract change breaks if it deploys before the consumers are ready for it, which connects this directly to dependency blindness: a provider that ships a new shape before its consumers have migrated causes an outage no local test predicted.
Catching it: make the far side visible and verified
The reason cross-boundary breakage is preventable is that the boundary, though invisible to a single repository's tools, is not invisible in principle. You just have to look at it on purpose.
Keep each unit of work inside one repository, and give it the other side's contract as context. A task that edits a consumer needs the provider's actual interface, its type definitions, its API description, its event schema, in front of it, even though it only edits its own code. Left to guess the shape, an agent invents a plausible one, and plausible-but-wrong is the expensive failure mode. Supplying the specific slice of the other repository that a change must be correct against, without dumping every repository at once, is the discipline that closes most of this gap.
Sequence provider before consumer, and migrate before you remove. Change the thing that is depended upon first, in a backward-compatible way, migrate the consumers onto the new shape, and only then remove the old one. This two-step dance is how careful teams have always shipped coordinated changes, and it is exactly what an agent blind to the boundary will skip.
Verify across the boundary, not just within it. Contract tests, checks that a provider still satisfies what its consumers expect, are the safety net a single repository's tests cannot provide. They are the cross-repository equivalent of the tests you would demand inside one codebase, and they are worth the effort precisely because the boundary is where the compiler stops helping.
The full treatment of coordinating changes across a product that spans several repositories is in one product, many repos, and the deeper point about interfaces being where the risk lives is in designing agent handoffs and contracts.
The honest limitation
Making the boundary visible reduces cross-boundary breakage, it does not eliminate it, and the reason is that contracts only capture the coupling someone wrote down. A consumer that depends on undocumented behavior, a shared database with no schema that captures the real invariants, an ordering assumption living only in someone's head, is a dependency no contract test will catch, because there is no contract describing it. Static analysis of interfaces misses runtime coupling, and no amount of sequencing saves you from a dependency you did not know existed.
There is also a cost to the discipline. Maintaining contracts, supplying cross-repository context, and running contract tests is real work, and on a small product with one repository it is work you do not need. The practice earns its keep as the number of boundaries grows, which is exactly when the breakage it prevents would start to hurt.
Where this leaves you
Cross-boundary breakage is how a correct, tested change becomes a broken product: the change is safe in the repository where it was made and dangerous in every repository that depends on it, and no single repository's tools can see across the gap. The fix is to make the far side of the boundary visible, give each change the contract it must honor, sequence provider before consumer, and verify across the boundary with contract tests.
This is why a product that spans many repositories, with every unit of work scoped to a single repository and cross-service features handled as ordered, linked pieces, is a stance we built into Loopsfinity from the start: the boundary is where a small change turns into a distributed incident, so it is where the care has to go. The sequencing angle is in dependency blindness, the last-mile framing in the last mile, and the full failure map in why AI coding agents fail in production.