Background agents touching multiple repositories?

[rabo-unumed]

Select Topic Area

Question

Body

most of our issues require touching multiple repositories (services architecture and some utility libraries). Background agents seem to be very repo-specific, working within a single git worktree. How can I employ one or more background agents in concert and in parallel to resolve such issues?
Will I have to stage it manually and do a sub-issue for each repository and then task two agents with solving the issue on each repo in parallel? The issue is that it often cannot be solved and tested in full isolation. I could see a supervisor agent being employed to coordinate, but it would have to be in local mode and I don't think agents can currently launch background agents themselves?
Are background agents simply not a good fit here?

[samsmithnz]

Hi! I'm @samsmithnz, I lead a team of Architects at GitHub, and saw this question, and thought I'd try to help answer.

You're right that background agents work best within a single repo context. For multi-repo scenarios, breaking the work into repo-specific sub-tasks is currently the most effective approach. Multi-repo agent capabilities are definitely on the roadmap, and your use case is exactly why. For now, task decomposition is your friend.

Recommendation: Break the issue into smaller, repo-specific tasks (as you suspected), then assigning agents to each sub-task sequentially and then testing integration points between repos as a final step is your best bet.

It does sound like you have some repo dependencies. While independent repos are ideal, the reality often means shared contracts and coordinated changes across boundaries. That's normal. The key is having clear interfaces and versioning strategies so changes can be staged incrementally- even if they need to be deployed together.

Hopefully this helps.

[devopsjester]

Hi Rasmus,

Today, as @samsmithnz said, the most reliable way to handle a “multi-repo solution” with background agents is to break the work down by repository (one repo = one scoped task/agent) and then coordinate the PRs in dependency order. True multi-repo orchestration (one agent coordinating changes/PRs across several repos) isn’t really available yet, so trying to force it usually increases friction.

I would like to add 2 more options, though they come at a maintenance cost price.

If you want something closer to a “single place” to drive the work, one option is to create a dedicated integration/meta-repo and add the relevant repos as git submodules, then point the agent at that meta-repo. That can work, but it comes with ongoing maintenance cost (keeping submodule SHAs updated, CI/integration workflows, review complexity), and many teams decide that overhead is too high unless they already want a formal integration repo.

Also, it’s worth clarifying what you mean by “background agent”:

• If you mean a hosted Coding Agent that opens PRs: expect repo-scoped behavior, so “one agent per repo + coordination” is the best current pattern.
• If you mean a local background workflow (e.g., Copilot in the CLI): you can often just clone the repos under the same top-level folder and run the CLI from that folder so it can see/edit everything locally—though you’ll still typically end up with separate commits/PRs per repo.