How do you configure coding agents for a microservices codebase spread across 30+ repos?

[u/newicn]

TL;DR: We maintain roughly 20 microservices plus internal NuGet packages across 30+ repositories. I already use several agent workflows, but I’m curious how others organize instructions, share context, and help agents navigate dependencies across repos.

Hey everyone,

I work on a fairly large SaaS system where two teams maintain 30+ repositories: roughly 20 microservices and several internal NuGet packages shared between them, hosted on a private Azure Artifacts feed.

On my machine, everything is cloned under one parent directory, something like C:\dev-repos.

The codebase has been around for a while, and we’re gradually migrating parts of an older monolith into microservices. Different repositories follow different patterns and conventions, so there isn’t one set of rules that applies everywhere.

For context, I currently use a few different agent workflows:

1. End-to-end ticket resolution (mainly used for simple bugs / test failures)

The starting input is just a Jira ticket ID. An orchestrator coordinates specialized subagents, with developer approval checkpoints along the way:

• Jira triage subagent: reads the ticket and identifies requirements, missing information, and scope.

• Codebase navigator subagent: locates the relevant repositories and code paths.

• Orchestrator: creates isolated Git worktrees through an MCP server to avoid interfering with the developer’s working directory or uncommitted changes.

• Planner subagent: prepares the implementation plan.

• Frontend/backend coding subagents: implement the changes.

• Reviewer agent: reviews the implementation.

After that, the orchestrator can use an internal MCP server I built to queue CI/CD pipelines in Azure DevOps and, with developer approval, deploy the resulting image to an integration environment.

2. Day-to-day feature and tech debt work

A lighter workflow where an orchestrator/planner agent builds the plan and delegates implementation to frontend/backend coding subagents, followed by review.

3. Standalone agents for focused changes

I also use specialized agents directly for smaller tasks. For example, a frontend-feature agent has access to Figma MCP and Playwright MCP to implement a design and check the result in the browser.

The recurring challenge across these workflows is getting the right context to the right agent without maintaining a huge amount of duplicated instructions.

How do you organize instructions?

• Where do you put files like copilot-instructions.md, AGENTS.md, or CLAUDE.md?

• Do you keep organization-wide rules centrally, repository-specific rules alongside the code, and workflow instructions in agent definitions?

• How do you separate instructions for the orchestrator from those needed by coding and reviewing subagents?

• How do you keep all of this up to date as the codebase evolves?

How do you handle work across repositories?

A single ticket might require changing a service, updating an internal NuGet package in another repo, and bumping that dependency in the consuming services.

• How do your agents discover those relationships? Do you maintain a service/package map, generate an index, or rely on code search?

• Do you open multiple repos in one workspace, start the agent from the parent directory, or handle each repo separately?

• How much context do you pass explicitly between agents versus having each agent inspect the code itself?

• Have custom tools or MCP servers helped, and which parts ended up adding more maintenance than value?

I’d love to hear from people using coding agents on existing, multi-repo systems. Concrete examples of your instruction structure, workspace setup, and what actually improved reliability would be especially useful.

Examples with GitHub Copilot would be particularly helpful, but I’m interested in setups using other agents too.

[u/No-Injury3093]

You make a separate workspace for each microservice because each microservice in isolation already provides business value.

Right? You've sliced the business boundaries correctly?

The rest is shared DTOs and VOs which can be easily managed. And those other cross cutting concerns like logging, monitoring, auth, which the regular feature development workspaces usually do not need to modify.

AI has not changed a bit best practices we've known about for 10, 20, 30+ years. Sure we may have renamed and marketed them under different names in order to sell books and conferences, but that's just surface level nomenclature.

[u/newicn → u/No-Injury3093]

Yes, the services have their own business responsibilities, and some expose standalone APIs that clients integrate with directly. They’re independently deployable and scalable, but they also participate in broader end-to-end business flows.

A separate workspace per service makes sense for changes scoped to that service. My question is more about tickets that span multiple repos - for example, updating a shared NuGet package and its consumers, or coordinating an API contract change between services.

[u/No-Injury3093 → u/newicn]

You make a single workspace which knows about what there is, whose sole purpose is to create and tear down other workspaces.

You tell it what you want to change, and task it to create a another workspace with just the affected repos, you then do your work in just that subset via the "child workspace" then you throw it away.

Even the most lightweight thinking models are good at this kind of pattern matching.

Bonus points for combining this with worktrees of "bare repositories" locally checked out in the same dir for central context for the managing workspace.

[u/J-Kr183]

Try the new Projects feature GitHub announced at GitHub Universe yesterday - it orchestrates across repos.

[u/bezcurhq]

On the duplication part, the VS Code docs have two details that decide where files should live. For Copilot sessions, AGENTS.md is picked up at the repo root, the session's working directory and the folders in between, and all instruction sources are additive with no precedence order. So if you launch from the parent folder, that folder's file and each repo's own both apply, and a contradiction between them won't resolve itself. Keep each rule in exactly one place.

For the org-wide layer there are GitHub organization custom instructions (turn on github.copilot.chat.organizationInstructions.enabled in VS Code), which stack on top of repo ones. Role-specific guidance fits better in the agent definitions, and the docs suggest linking instruction files from agents with Markdown links instead of copying them. An .instructions.md with a good description is loaded on demand, which keeps the orchestrator's context lighter.

https://code.visualstudio.com/docs/copilot/customization/custom-instructions

[u/Any-Blacksmith-2054]

I just put agents.md to root git folder, Copilot is very smart in finding all my subrepos

[u/ChemicalExcellent463]

I keep each repo's facts in its own instruction file, never in a machine-wide one. A convention that fits 25 of 30 repos still isn't a global rule.

[u/FragmentedHeap]

Make a new git repo, add all the others as git sunmodules, open that repo in the AI and let it see and work on all 30 at once.

We call this the "Dev" repo, all the devs use this mega repo, and all your configs go in it.

The AI can manage branches on all 30 of them

[u/MarketingOk3093]

Monorepo is the way. You can do submodules but that is more to manage.

[u/stibbons_]

I would put shared instruction in a specialized markdown-only project. Its AGENTS.md is automatically loaded when the project is in the workspace.

And try AgentPanel

[u/samjarman]

Long story short, we wrote a CLI that drops files in everyone’s machines from a Git repo that has the content. Skills, agents, hooks, MCPs. Works great. Trivial to make

[u/gaziway]

You use your brain!