AI Coding Agents
Software Delivery
Cross-repository coding agent coordination
September 24, 2026 - 2 minute read
A cross-repository coding agent can shorten a coordinated change only when the dependency order is explicit. A shared API update may touch a schema repository, generated clients, several services, and deployment configuration. Editing those repositories in parallel without a compatibility plan creates fast-moving breakage.
Treat the work as one outcome with several independently reviewable changes. Factory Missions support large efforts through upfront planning, milestones, worker delegation, and validation. The same principles apply when teams coordinate the work manually.
Plan cross-repository coding agent work
Inventory every repository that produces or consumes the changed interface. Record the source of truth, generated artifacts, release owner, required checks, and deployment order. Distinguish hard dependencies from repositories that can update later.
Choose a compatibility strategy before assigning work. An additive API change can often ship to the provider before consumers. A breaking change usually needs an overlap period in which old and new contracts both work. Database changes commonly use expand-and-contract sequencing so application versions can coexist during rollout.
Turn that map into milestones. A useful order is contract and compatibility, producer changes, consumer changes, then removal of the old path. Give each repository a narrow acceptance criterion, and add an integration check that proves the repositories still work together.
Assign one coordinator to own the dependency map. Repository owners still decide whether their changes are acceptable, while the coordinator tracks version relationships and prevents a locally complete pull request from being mistaken for a complete rollout.
Isolate execution and share state
Each worker needs its own branch and working directory. Factory documents Git worktree support for parallel sessions so edits do not collide in one checkout. Isolation prevents accidental overwrites, but it does not resolve semantic conflicts between two valid changes.
Keep shared decisions outside any single agent's conversation. Record interface versions, rollout order, open blockers, and validation results in the mission plan or another durable artifact. Workers should receive only the context relevant to their repository plus the shared contract they must preserve.
Factory's Missions architecture uses focused workers, independent validators, and externalized state for this reason. The architecture description explains how scoped context and milestone validation keep a large effort aligned without asking one agent to retain every implementation detail.
Validate cross-repository coding agent work
Repository-local tests can all pass while the combined system fails. Run contract tests against the exact producer and consumer revisions planned for release. Verify generated clients are current, version constraints accept the new artifacts, and deployment manifests reference the intended versions.
Open separate pull requests when ownership or release timing differs. Link them through the shared plan and state which order is safe. Human owners should approve the changes in their repositories, and the coordinator should hold final completion until cross-repository evidence passes.
The Chainguard case study describes one Droid session working across six repositories during a two-week project. The useful pattern is coordinated scope and validation across repositories, rather than treating the number of simultaneous agents as the measure of progress.
