Why not just use a bigger context window?

A larger window delays the problem, it does not solve it. Even a million-token context cannot hold a 20 million line repo, and filling it with mostly irrelevant code raises cost and degrades reasoning. Retrieval scopes context to the task, so the agent works on the right 2,000 lines regardless of how large the repository grows.

How is this different from the agent grepping the repo itself?

Grep re-scans code on every task and returns raw text matches with no ranking. It re-reads files that have not changed and pays the discovery cost each run. A prebuilt index parses the repo once, ranks chunks by relevance, and serves them instantly, so discovery work is amortized across every agent and every task instead of repeated.

Does indexing our code expose it externally?

No. Under an RDK Enterprise account the index is stored as encrypted private chunks. Your agents retrieve internal code, but the chunks are not readable by the public network or other organizations. You choose separately whether to publish any non-sensitive chunks as public, which is opt-in and never automatic.

How often does the index need rebuilding?

Treat it as a build artifact and refresh on change. Wiring re-indexing into CI so chunks update when code merges keeps retrieval current without any agent re-parsing the tree at runtime. Untouched code is never re-processed, so indexing cost scales with change volume, not with total repository size.

How to run coding agents across a large codebase

You cannot fit millions of lines into a context window, so stop trying. Index the codebase as retrievable chunks, then let each agent fetch only the functions, files, and docs relevant to its task. Retrieval scopes context by relevance, not by directory size, so cost and latency stay flat as the repo grows.

Why context windows fail at monorepo scale

A codebase with tens of millions of lines will never fit in a context window, and it never needs to. A single task touches a handful of files: the function under edit, its callers, the tests, maybe a shared interface. The rest is noise.

The naive agent loop ignores this. It greps for a symbol, reads whole files, follows imports, and reads those files too. On a small repo this is fine. At scale it collapses. The agent spends most of its budget locating code rather than reasoning about it, and every task pays the discovery cost from scratch because nothing is remembered between runs.

The fix is to change what you put in context. Instead of streaming raw files, you retrieve pre-indexed chunks scoped to the task. Context size then tracks relevance, not repository size, so a query against a 20 million line tree costs the same as a query against a 200 thousand line one.

Index the repository as retrievable chunks

Treat the codebase as a knowledge base, not a filesystem the agent walks live. Parse it once into chunks: a function, a class, a config block, a doc section. Key each chunk by its symbol name and path so retrieval can be both semantic and exact.

Chunk by symbol, not by file

A 3,000 line file is a bad unit of retrieval. Split it at natural boundaries so a query for PaymentProcessor.refund returns that method and its immediate context, not the entire module. Attach the file path, language, and enclosing symbol as metadata. This lets an agent ask for exactly one function and get it in one retrieval instead of reading and discarding thousands of surrounding lines.

Re-index on change, not on every query

The index is a build artifact. Refresh chunks when files change, ideally in CI on merge, so the retrieval layer stays current without an agent ever re-parsing the tree at runtime. One indexing pass serves thousands of agent tasks. Compare this to grep, where every task re-scans code that has not changed since the last run and pays for it again.

Share one index across every agent and developer

The scale win is organizational, not per-agent. When the repository is indexed once and served from a shared store, every developer's agent draws from the same retrieval layer. Nobody re-discovers the auth module. Nobody re-reads the payments package to answer the same question a teammate asked yesterday.

This is where cost compounds in your favor. In an ungoverned setup, a hundred engineers running agents means a hundred parallel cold-start scans of overlapping code, each billed separately. With a shared index, the discovery work happens once and retrieval is cheap thereafter. The org stops paying to regenerate the same context across every seat.

RDK stores this index as encrypted private chunks under an Enterprise account. Internal code is retrievable by your agents and invisible to everyone else. You keep the retrieval speed of a shared index without publishing proprietary source to the public network.

Stack retrieval so the LLM is the last resort

Not every query needs a model call, and at scale the ones that do are the exception. Route each agent task through stacked retrieval. The private index answers 40 to 65 percent of queries outright: definitions, call sites, config values, prior fixes. Where an internal answer does not exist, a public network layer covering common libraries and patterns adds another 15 to 20 percent. The LLM handles the remaining 5 to 10 percent, the genuinely novel reasoning.

The effect on spend is direct. Token usage on retrieval-answerable work drops 80 to 90 percent because the answer is fetched, not regenerated. On a large team that difference is the gap between agents being an experiment and agents being default tooling.

It also changes what the model is good at. Freed from re-deriving facts that already exist in your codebase, the LLM spends its budget on the part that actually needs a model: reconciling a new requirement against existing structure, proposing a refactor, reasoning about an edge case nobody has hit before. Retrieval handles memory. The model handles judgment. Keeping those two jobs separate is what lets agents stay fast and affordable as the repository, and the team, keeps growing.

Frequently asked questions

Why not just use a bigger context window?: A larger window delays the problem, it does not solve it. Even a million-token context cannot hold a 20 million line repo, and filling it with mostly irrelevant code raises cost and degrades reasoning. Retrieval scopes context to the task, so the agent works on the right 2,000 lines regardless of how large the repository grows.
How is this different from the agent grepping the repo itself?: Grep re-scans code on every task and returns raw text matches with no ranking. It re-reads files that have not changed and pays the discovery cost each run. A prebuilt index parses the repo once, ranks chunks by relevance, and serves them instantly, so discovery work is amortized across every agent and every task instead of repeated.
Does indexing our code expose it externally?: No. Under an RDK Enterprise account the index is stored as encrypted private chunks. Your agents retrieve internal code, but the chunks are not readable by the public network or other organizations. You choose separately whether to publish any non-sensitive chunks as public, which is opt-in and never automatic.
How often does the index need rebuilding?: Treat it as a build artifact and refresh on change. Wiring re-indexing into CI so chunks update when code merges keeps retrieval current without any agent re-parsing the tree at runtime. Untouched code is never re-processed, so indexing cost scales with change volume, not with total repository size.

Key takeaways

At monorepo scale the bottleneck is retrieval, not context length. The agent needs the right 2,000 lines, not all 20 million.
Grep and full-file reads do not scale. Each cold-start scan re-reads the same code and burns tokens the org already paid for.
Index the repo once as chunks keyed by symbol and path, then serve every agent from that shared index instead of re-parsing on each run.
RDK holds the index as encrypted private chunks under an Enterprise account, so agents retrieve internal code without exposing it to the public network.
Stacked retrieval answers 40 to 65 percent of queries from the private index and falls back to the LLM only for genuinely novel reasoning.