Factory

AI Coding Agents

Software Delivery

Cross-repository coding agent coordination

September 24, 2026 - 2 minute read

Suppose an API producer renames a response field and passes its local tests, while a generated client in another repository still expects the old field. Both pull requests can look complete in isolation and fail together. Cross-repository coding agent work needs an explicit contract and release order before parallel edits begin.

Treat the work as one outcome with independently reviewable changes. Factory Missions support that coordination through upfront planning, milestones, worker delegation, and validation.

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. For the renamed field, the producer could temporarily return both names under an approved contract version. Regenerate and release the client against that version, move consumers to the new field, and remove the old name only when supported consumers no longer require it. Check whether older clients tolerate an added field rather than assuming every additive change is safe.

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.

Further reading

Ready to build the software of the future?

Start building

Arrow Right Icon