Cross-Repository Code Intelligence

The organizational problem came first. As the engineering organization grew, similar problems got solved repeatedly in different repositories. Discovering prior work depended on knowing who to ask. Knowledge lived in repositories and in people's heads, and neither was reachable without already knowing where to look.

The constraints ruled out the obvious solution. The natural instinct is to index everything locally. That was not available.

• ·Repositories live in the organization's git server, and access differs by team. Not every engineer can read every repository.
• ·Cloning every repository onto every developer machine is expensive to maintain, and would quietly bypass the access model.
• ·The system had to read code through a bot token with read only scope, respecting the organization's existing permissions rather than inventing a parallel one.
• ·Some repositories are large. One internal repository is 1.1 GB on its own.

So the requirement became. read repository B in place, from a central service, with the same access boundary the organization already enforces, and without ever putting repo B on the developer's disk.

A third constraint shaped more of the design than either of the above. The assistant runs on a self hosted model that follows instructions less reliably than frontier models. A capability that works when the model behaves correctly is not a shipped capability. Most of the engineering below exists to make wrong behaviour either impossible or self correcting.

Stage 1: make cross-repository reads possible at all. Read tools gained an optional target repository parameter. When present, the backend created a mirror, checked out a full worktree, and read from that directory. It worked, and review found it unshippable: a full disk checkout to read a single file, an unbounded in memory cache, a network fetch on every call, and no timeouts anywhere. One hung clone could stall the agent indefinitely.

Stage 2: make it efficient and production safe. File reads and directory listings moved to reading directly from the bare mirror via git show and git ls-tree, with no checkout at all. Only the one tool that genuinely scans a directory still materializes a worktree, behind a bounded LRU that evicts from disk as well as memory. Fetches became TTL gated instead of per call. Every git operation got a timeout.

Stage 3: make it discoverable by humans and by the model. Typing @ already meant reference a local file, so referencing an external repository needed a distinct affordance. Following the typed prefix and picker pattern used by other tools engineers already know, a Repos section was added to the @ menu, populated live from the git server. Selecting one inserts a repository mention, which expands into an instruction block, and the system prompt gained cross-repository rules so the model knows the capability exists before any mention appears.

Stage 4: survive contact with a real agent. Live sessions produced a parade of failures that no amount of design review would have predicted. That stage produced most of the interesting engineering.

Read from mirrors, not checkouts. git show and git ls-tree read straight from git's object database. A single file read costs milliseconds and zero disk, against gigabytes for a full checkout. Only the tool that genuinely scans a directory pays for a worktree.

Separate the cheap resolve from the expensive materialize. Resolving a repository to a commit is always needed. Putting files on disk almost never is. Splitting those into two layers means the common path never subsidizes the rare one. Both share in flight deduplication, so five simultaneous requests for the same repository produce one clone.

One security gate, reused rather than reimplemented. The allowlist check lives in exactly one function, the same one already guarding repository binding. A second, subtly different copy is how access control drifts.

Errors are product surface, not exhaust. Raw git stderr is mapped to a taxonomy where each case tells the caller the single correct next action. Busy means wait and retry the same tool. Not found means the repository may exist but the bot lacks read access. Ref not found names the default branch to fall back to. This matters more with an agent consumer than a human one, because the model's instinct on an ambiguous error is to change strategy, and changing strategy is precisely what produced the invented servers and the clone attempts.

Correct the model in code where prompting is unreliable. Every tool call passes through one handler, which makes it the place where wrong calls can be deterministically fixed. Three guards live there: reroute a misaddressed call rather than failing it, catch consecutive identical calls with an escalating response, and cap consecutive searches that make no progress. Only consecutive repeats are caught, any other tool running in between invalidates the cache, and failed calls are never cached. Otherwise the retry after failure path would be broken by the guard meant to protect it.

Layer the defenses, and let each layer catch what the one above missed. Each rung exists because a real transcript proved the one above it insufficient.

Bound every cache, time limit every network call. An unbounded cache is a leak with a delay on it, and an untimed git call is a hung agent. Freshness windows turn per call costs into per window costs.

Fail soft at the UI edge. If discovery fails, the picker returns an empty section. The chat box never breaks because the git server had a bad moment.

Engineering knowledge is harder to retrieve than to generate. The bottleneck in a growing organization is rarely writing the code. It is discovering that the code already exists, understanding why it was built that way, and making that reachable by the next engineer who needs it.

Designing for a weak model is a different discipline than designing for a strong one. Instructions are a starting point, not a mechanism. The pattern that worked was three layers. Teach it, with self describing tools and literal examples. Tell it precisely what failed and what to do next. When it still misbehaves, correct it in code. Each layer exists because a real transcript proved the one above it insufficient.

Error messages are an interface, and agents are the least forgiving consumer of that interface. A human reading "No workspace bound" eventually figures out the real problem. A model reads it, concludes the capability is broken, and invents a workaround. Every ambiguous error I left in place came back later as a bizarre agent behaviour.

The organizational constraint was the interesting part of the problem. Search across repositories is a weekend project. Search across repositories that cannot be cloned, whose access differs by team, through a token with a deliberately narrow scope, is an architecture. The constraints were what made the design worth writing down.