# Context Engineering Across Hundreds of Repos: A Practical Ladder for Platform Teams


URL: https://getunblocked.com/blog/context-engineering-across-hundreds-of-repos/
Published: 2026-11-06T17:50:00Z
Author: Brandon Waselnuk
Categories: Context Engineering, Engineering Insights

Five ways to do context engineering across hundreds of repos, from synced AGENTS.md to a context layer over MCP. Costs, limits, and a 2026 study on rules files.

---
When Emo Rodriguez, who leads DevOps at Cloudbeds, counted, he found [987 GitHub repositories wrapping roughly seventy microservices](https://getunblocked.com/customers/cloudbeds/), each split across source, GitOps and Terraform repos. Finding which repository owned a resource meant hoping the naming conventions held. Now picture asking a coding agent to rename one field in a shared schema across an estate like that. It edits the schema repo cleanly, with no idea which other repos read that field or who owns them. Advidi (400+ repositories) and [Codat (200+)](https://getunblocked.com/customers/codat/) describe the same problem. Context engineering across repos is the work of getting that knowledge to the agent before it writes the first line. Teams do it in five steps of rising effort: shared rules files, multi-root sessions, org-wide code search, a service catalog, and a central context layer that agents query over MCP.

## How do teams do context engineering across hundreds of repos?

They stop treating each repository as the unit of context and start treating the organization as the unit. **Context engineering** is the practice of deciding what an AI agent sees before and during a task: which instructions, which files, which history, and in what order. In one repo, that mostly means a good `CLAUDE.md` or `AGENTS.md`. Across hundreds, it means answering three questions the agent cannot answer from inside one checkout: what other code depends on this, who owns it, and what has the company already decided about it.

The teams that handle this well climb a ladder, one rung per failure. Skipping straight to the top tends to disappoint, because a context layer still reads the rules files and ownership data the lower rungs produce. Our explainer on [what context engineering is](https://getunblocked.com/blog/what-is-context-engineering/) covers the single-repo basics.

## What breaks when agents work across hundreds of repos?

Agents re-explore on every session. Each Claude Code session "begins with a fresh context window," as [Anthropic's memory docs](https://code.claude.com/docs/en/memory) put it, so the agent rediscovers the same service boundaries every morning. Retrieval is weak even inside one repo. [ContextBench](https://arxiv.org/abs/2602.05892), a February 2026 benchmark of 1,136 tasks across 66 repositories, found that models favor recall over precision. It also found a wide gap between the context agents explore and the context they actually use. Its methodology tracks each agent's trajectory against human-annotated gold context.

Rules files drift. For example, repo 12 says "use the shared retry client," while repo 240 still describes the client you deprecated last year. That matters because agents obey the file. An August 2026 paper on [coherence debt](https://arxiv.org/abs/2608.16630) found that when a stale convention file conflicts with the code, agents follow the file. **Coherence debt** is that paper's name for the facts an edit depends on that are in neither the agent's context nor the model's memory.

Contracts and ownership live between repos. Consider the rename again. The schema, its consumers, their owners, and the freeze decision sit in a registry, a CODEOWNERS file, a Jira epic, and a Slack thread. No single checkout holds them.

## Why can't the agent just clone everything?

Because cloning hundreds of repos is slow, expensive, and still leaves out most of what matters. A full clone downloads every commit, tree, and blob for the life of the repository. Git's documentation on [partial clone](https://git-scm.com/docs/partial-clone) notes that for extremely large repositories this can take hours and consume 100+ GiB of disk. Multiply that by a few hundred and a cloud agent spends its budget on setup before it reads a line.

Cloning also gives the agent code and nothing else. The pull request that explains why the retry count is three, the incident that made a team freeze a service, and the ticket that says a field is being retired are all outside Git.

Then there is access. A developer who can read 40 repos should not get an agent that reads 400. Any approach that copies code into one place has to carry the source system's permissions with it, or it quietly widens who can see what.

## The ladder: five approaches compared

Each rung below fixes one failure from the list above. Effort is relative: what it takes a platform team of a few people to set up and keep running.

| Approach | Effort | What it fixes | Where it stops working |
| --- | --- | --- | --- |
| Shared rules baseline (AGENTS.md / CLAUDE.md synced across repos) | Low: a template repo and a sync bot | Drifting conventions; agents ignoring org standards | Rules only; no knowledge of other repos, owners, or history |
| Multi-root sessions (--add-dir, multi-root workspaces) | Low: per session | Edits that span two or three known repos | You must already know which repos matter; cloud agents and some features don't support it |
| Org-wide code search (GitHub code search, the GitHub MCP server) | Low to medium | "Where else is this used?" across all repos | Default branch only, capped results, code only |
| Service catalog and ownership map (Backstage, CODEOWNERS) | Medium: metadata in every repo | Who owns a service; what depends on what | Only as current as the YAML; no reasons or decisions |
| Central context layer over MCP | Medium to buy, high to build | Why the code is the way it is, across code, PRs, tickets, docs, and chat, with permissions | Needs the lower rungs' data to be good; another system to trust |


## How far does a shared AGENTS.md baseline get you?

It fixes drift, and little else. Keep one baseline file of org-wide rules in a template repo, and have a bot open a pull request in every repo when it changes. Each repo keeps a short local section for its own quirks.

Claude Code and Cursor both have an org-level hook. Claude Code reads a managed policy `CLAUDE.md` that IT can push to every machine, and it reads `AGENTS.md` directly. Cursor's [Team Rules](https://cursor.com/docs/rules) let Team and Enterprise admins create rules in the dashboard and make them required for everyone. For Codex, the synced repo file is the hook: it collects `AGENTS.md` files from the Git root down to the working directory and stops at a combined [32 KiB by default](https://learn.chatgpt.com/docs/agent-configuration/agents-md).

Keep the baseline short. Agents followed the instructions in context files well, yet the files did not generally improve task success and raised inference cost by over 20%, according to a [February 2026 study of AGENTS.md](https://arxiv.org/abs/2602.11988). Use them for non-standard practices and skip repository overviews. Our [CLAUDE.md vs AGENTS.md vs Cursor rules comparison](https://getunblocked.com/blog/claude-md-vs-agents-md-vs-cursor-rules/) covers the formats.

## When do multi-root sessions and --add-dir help?

They help when you already know the two or three repos a change touches. Claude Code's `--add-dir` flag adds directories to a session, but loads their `CLAUDE.md` files only if you set `CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1`, per the same Anthropic memory docs. Codex has the same flag, which grants "additional directories write access alongside the main workspace" per its [CLI reference](https://learn.chatgpt.com/docs/developer-commands?surface=cli). Cursor supports [multi-root workspaces](https://cursor.com/docs/agent/tools/search) in the editor, though its docs note that Cloud Agents do not, and that worktrees are disabled in multi-root workspaces.

The limit is the word "know." Multi-root sessions are a good fit for small known sets, such as a client library plus its two main consumers. They do nothing for the change that touches a repo nobody on the team remembers exists, which is the change that causes incidents.

## What does org-wide code search add?

It answers "where else is this used?" without cloning anything. GitHub code search takes an [`org:` qualifier](https://docs.github.com/en/search-github/github-code-search/understanding-github-code-search-syntax) and a `symbol:` qualifier for definitions in 21 languages, and the [GitHub MCP server](https://github.com/github/github-mcp-server) exposes a `search_code` tool, so an agent can run the same query mid-task.

The limits are documented. GitHub [code search](https://docs.github.com/en/search-github/github-code-search/about-github-code-search) covers only the default branch, caps any search at 100 results, and skips files over 350 KiB and vendored or generated code. For the schema rename, that means a consumer on a long-lived release branch is invisible, and a popular field name can blow past 100 hits. The agent still has to judge which matches matter; our [AI code search tools comparison](https://getunblocked.com/blog/ai-code-search-tools-compared/) covers tools that rank better.

## Where does a service catalog fit?

A catalog answers who owns a service and what depends on it, which code search cannot. [Backstage](https://backstage.io/docs/features/software-catalog/) describes its catalog as a central record of "ownership and metadata for all the software in your ecosystem," built from YAML files stored next to the code. GitHub's [CODEOWNERS](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) is the lightweight version: a file in each repository, under 3 MB, that requests owners for review on pull requests that touch their code.

Expose the catalog to agents through its API or an MCP server, and the rename gets a list of consumer teams to tag. The catch is freshness. Backstage puts the burden on the teams that own each component, so the catalog is as current as their last YAML edit, and it records who and what, rarely why.

## What does a central context layer over MCP add?

It answers why, across every system, in one call. A **context layer** is a shared service that indexes code alongside pull requests, tickets, docs, and chat, resolves conflicts between them, and returns one cited answer to any agent that asks. Agents reach it over the [Model Context Protocol](https://modelcontextprotocol.io/specification/latest), so Claude Code, Codex, and Cursor all query the same source. See [centralizing context for coding agents](https://getunblocked.com/blog/centralize-context-for-coding-agents/) for the architecture and [one MCP for Claude Code, Codex and Devin](https://getunblocked.com/blog/one-mcp-for-claude-code-codex-devin/) for the config.

Unblocked is the context engine we build for this rung, and its main job here is ending cross-repo archaeology. Its [`context_research`](https://docs.getunblocked.com/unblocked-mcp/mcp-context-research) tool searches code, PRs, docs, issues, and messaging and returns a cited summary; `context_get_rules` pulls the rules out of each repo's `AGENTS.md`, `CLAUDE.md`, and `.cursorrules` files ([Unblocked docs](https://docs.getunblocked.com/unblocked-mcp/mcp-context-get-rules)). With [Data Shield](https://docs.getunblocked.com/team-settings/data-shield) turned on, answers only include sources the asking user can access in the original system. Cloudbeds runs it across the 987 repositories from the opening.

For example, Advidi has 400+ repositories, about 300 legacy and 100 on its new platform. OpsClaw is the team's in-house incident agent, built on OpenClaw and living in Slack. As the [Advidi story](https://getunblocked.com/customers/advidi/) describes, the CTO connected it to Unblocked and scoped its access the way he would for a human teammate:

> I'm not going to clone 300 repositories and let a bot crawl through them every time an incident happens. Now an incident occurs, it reads the logs, sees the 500 response, and it can point at exactly the right place in the codebase. It lets people tackle problems they simply couldn't before.
>
> — Jorden van Breemen, CTO, Advidi


## What should a platform team do in the first week?

1. Pick three recent cross-repo changes or incidents and write down what the agent, or the engineer, did not know at the start.
2. Write a baseline `AGENTS.md` of under 100 lines: build commands, banned patterns, the shared clients to use. Leave out repository tours.
3. Set up a bot that opens a pull request in every repo when the baseline changes, and set Claude Code's managed policy file or Cursor's Team Rules for anything that must apply everywhere.
4. Add the GitHub MCP server to your shared agent config so `search_code` is available in every session.
5. Check that CODEOWNERS exists in your 50 most-changed repos, and fill gaps.
6. Re-run one of the three changes from step 1 with the new setup and compare what the agent found.

Move up a rung when the same miss repeats: a second incident traced to a repo nobody searched, or a second PR that undid a decision recorded only in a ticket or a thread.

## FAQ

### What is context engineering across repos?

It is the practice of giving coding agents the knowledge that spans repositories: dependencies, owners, shared contracts, and past decisions. Single-repo context engineering stops at the checkout; the cross-repo version covers the whole organization.

### Should every repo have its own AGENTS.md?

Yes, but keep each one short and generated from a shared baseline. The 2026 AGENTS.md study found repository overviews did not help, and context files raised cost.

### How do agents stop repeating discovery before every task?

By querying a shared source at the start of the task instead of exploring from scratch. Our answer on [stopping repeat discovery](https://getunblocked.com/answers/stop-coding-agent-repeat-discovery-before-every-task/) walks through the setup, and [rules files vs a context engine](https://getunblocked.com/blog/rules-files-vs-context-engine/) explains where static files run out.

## Start with the change that hurt last month

Pick the cross-repo change that cost your team the most in the past month and trace what the agent was missing. If it was a convention, fix the baseline file. If it was a location, add search. If it was an owner, fill in the catalog. If it was a reason buried in a PR or a Slack thread, that is where a context layer earns its place: institutional context for coding agents, one query away.