Context is a systems problem.

A repository is more than a list of files. Definitions connect to callers; tests encode expectations; configuration shapes runtime behavior; and conventions cross directory boundaries. Source text remains authoritative, but relationships can be difficult to reconstruct repeatedly from isolated snippets.

So the practical question is not only how much context fits. It is which context is relevant, whether it is current, which relationships it exposes, and how the agent can check its interpretation against actual project behavior.

Retrieval should preserve the structure that matters.

A developer tool can maintain a queryable map alongside the repository and expose targeted slices through a tool interface. Depending on language and parser coverage, those slices might include definitions, references, related tests, or selected project facts. The map should be inspectable and refreshable—not a second source of truth that silently drifts from the code.

The approach has costs. Indexing consumes time and storage. Parsers have coverage limits. Cached context may become stale, and a graph edge does not prove that a relationship is relevant to the change at hand. The tool must make uncertainty visible rather than turn an index into authority.

Measure the engineering outcome—not only context size.

Context reduction is useful only if the task still succeeds. Compare matched tasks with and without structured retrieval, then report completion quality, regressions, tokens, latency, and failure categories together. Context size is a systems metric; task quality is the outcome.

Atrium explores this design space. Its useful result will not be a single impressive percentage, but evidence about when repository structure helps, what overhead it introduces, and which failures still require human judgment.