Coding agents should retrieve dependency boundaries before nearby text

I want coding agents to retrieve dependency boundaries before they collect nearby text. Before an agent changes a function, it should establish which definitions that function relies on and which callers rely on its interface. Those relationships explain what the edit must preserve. A neighbouring file or an open editor tab tells me where someone has been looking. A dependency edge tells me why another piece of code belongs in the decision.

By a boundary, I mean a concrete relationship between a caller and the API it consumes: an imported symbol, a function signature, a return value used elsewhere. I would begin with the target symbol, follow its outgoing dependencies, and inspect incoming references when the proposed change could alter its interface. This gives retrieval a question to answer. Instead of asking for code that resembles the task description, I ask for the definitions and usages that constrain this particular edit.

The repository map is the right starting representation. Aider’s RepoMap makes the architectural choice explicit: extract symbols and signatures, rank their relationships, and fit a navigable summary into a bounded context budget. I want that summary to direct inspection, not stand in for implementation detail. A signature tells the agent where to look next. Reading the selected implementation and its callers supplies the evidence needed to decide whether the proposed change is compatible with their expectations.

Consider an agent changing a user lookup function. A nearby endpoint might show familiar naming and formatting. The imported model defines the object the function actually returns; callers show how that result is consumed. I would retrieve those before collecting additional endpoints that happen to mention users. The important distinction is not between search and graphs. It is between resemblance and dependence. Lexical or semantic search can find candidates, and import proximity can help rank which candidates deserve inspection first.

I would organise that inspection hierarchically. Repository conventions establish the expected patterns; the map identifies the relevant modules; selected code exposes the implementation; tests and usage examples show concrete expectations. Each expansion should answer an unresolved question from the previous layer. If the agent already has the definition it needs, retrieving another broadly similar file adds volume without resolving anything. If a caller introduces an unfamiliar type, that type becomes the next retrieval target. The budget follows uncertainty rather than directory proximity.

Change awareness belongs alongside this structure. The repository map shows the available interfaces, the diff shows what is being altered, and file content supplies implementation depth. I want these represented separately so an agent can distinguish the architecture it found from the change now under consideration. Retrieval should also be iterative: an initial implementation hypothesis can expose a missing API name and improve the next query. I treat that hypothesis as a search aid, not as evidence that the imagined API exists.

There is a precise limit to this approach: static dependency graphs cannot fully resolve dynamically loaded modules. In that case, I would expand beyond graph neighbours to inspect the loading code and relevant usage examples. The missing edge is a reason to broaden retrieval, not a reason to assume that a structurally distant file is irrelevant. Dependency proximity is a priority signal under incomplete knowledge, never proof that the rest of the repository cannot matter.

My stopping condition is therefore about answered questions, not accumulated text. Can the agent identify the API it is changing, the definitions it depends on, and the usages that constrain the change? Can it point to retrieved code rather than a plausible reconstruction? That is the context package I want before an edit. Nearby text earns its place by answering one of those questions. It should not get priority merely because it was easy to collect.