RAG over your repo isn't an index of your org

RAG over your repository is a great way to find code that looks like other code. It is not a model of your organization — and most of what an agent needs in order to act well is organizational, not textual. Those are two different problems, and only one of them is solved by embedding your files.

What RAG-over-repo actually does

The pattern is familiar: split the codebase into chunks, embed them, and at query time return the top-k snippets whose vectors are closest to the question. It’s genuinely useful for one shape of task — content retrieval. “Show me code like this.” “Where do we parse webhooks?” “Find the retry logic.” If the answer is a passage of text that exists somewhere in the repo, vector search will surface it.

The questions it can’t answer

Now ask the things an agent actually needs before it changes anything:

• ›Who owns lib/db, and who should review a change to it?
• ›What depends on this module — what’s the blast radius if I touch it?
• ›Who has the expertise for the auth system right now?
• ›Which past PRs reviewed changes like this one, and how did they go?

None of these is answerable by text similarity, because the answer isn’t in any chunk. Ownership lives in commit and review history. Dependencies live in the structure of the code and how it changes together. Expertise lives across the whole org’s activity over time. A snippet doesn’t carry its own owner, its own blast radius, or its own review history — so retrieving more snippets, however semantically clever, never adds up to that answer.

An index models the organization

A GitHub org context index solves the other problem. EOS resolves commits, pull requests, reviews, and dependencies into a structured graph — ownership, coupling, review flow, expertise — that you query exactly, not fuzzily. “Who owns this?” returns a ranked list with evidence, not five passages that mention the file. You can aggregate it: counts, medians, percentages, in one SQL query — something a bag of retrieved chunks simply can’t give you.

Retrieval still has a place — over the model, not the text

This isn’t “embeddings bad.” Semantic search is a real surface in EOS — but it retrieves over the modeled organization (recorded decisions, insights, entities and their relationships, with citations), not raw code chunks. We actually retired semantic search over code text on purpose: retrieving code passages is a solved commodity that other tools do well, and it was never the differentiator. The value is the org model underneath — and retrieval is one way to reach it, alongside typed endpoints and SQL.

Fresh and org-wide, not stale and per-repo

• ›Org-wide. RAG-over-repo is scoped to the text of one repository; the index models the whole organization — people and code across every repo.
• ›Fresh. Embeddings drift out of date the moment code and ownership change, until you re-embed. The index is kept current via webhooks, so ownership and dependencies reflect what merged an hour ago.
• ›Exact. The index returns structured facts you can act on and audit, not a ranked guess you have to hope is relevant.

Use RAG for what it’s good at — finding code. For everything about how your organization builds software, you need the model, not more snippets. That’s the difference between an agent that occasionally helps and one that reliably acts. (More on why raw GitHub data isn’t enough: org context for AI agents, and on the one-index approach: one index, any view.)