Vector RAG vs Path-Scoped Context for AI Coding
Retrieval-augmented generation earned its place on unstructured knowledge.
Applied to code, it answers a question nobody asked and misses the one that mattered.
Short answer
Vector RAG retrieves by similarity to a query, which is right for an unstructured corpus and wrong for a codebase where position already carries meaning. A coding agent is never nowhere: it is about to act on a specific path. Similarity is a guess about relevance; a path is a fact about it.
What this covers
- A coding agent is never nowhere: it is about to act on a specific path, and that path is a stronger signal than similarity to a sentence somebody typed.
- Pathrule indexes by path rather than by embedding proximity, so the knowledge governing a directory reaches an agent working in that directory without a query being formed at all.
- RAG cannot deliver before the first tool call because retrieval is triggered by a query; path-scoped delivery happens at hook time, before the agent acts.
- RAG also has no notion of enforcement: it returns similar text, whereas a rule carries scope, priority and an enforcement level, so a strict rule can stop a matching change.
- Pathrule still uses semantic recall, as one input among several rather than as the whole retrieval strategy: the path decides the slice, and ranking orders it.
- Claims are dated August 2026.
Comparison
| Capability | Pathrule | Generic vector RAG |
|---|---|---|
| Semantic recall across what you wrote | Yes | Yes |
| Team sync without a commit | Yes | Yes |
| Open core, self-hostable | Yes | Yes |
| Scoped to the path you are editing | Yes | No |
| Arrives before the first tool call | Yes | No |
| Rules that gate the work, with scope and priority | Yes | No |
| Stale knowledge flagged, refreshed on your approval | Yes | No |
| Tasks that arrive with their context prepared | Yes | No |
| Runtime incidents mapped back to code and tasks | Yes | No |
RAG earned its reputation somewhere else
Retrieval-augmented generation solved a real problem: a model that needs facts from a body of text too large to fit in a prompt. Support archives, policy documents, research collections. In those settings a query is the natural entry point, because the user genuinely has a question and the corpus genuinely has no structure that anticipates it.
Both of those assumptions break on a codebase, and they break in a way that is easy to miss because the machinery still runs and still returns plausible-looking chunks.
A coding agent is never nowhere
The first broken assumption is that relevance has to be inferred. A coding agent is always about to act on a specific file in a specific directory. That position is not a hint; it is the strongest available signal about which of your team's decisions apply.
Similarity to a sentence somebody typed is a weaker signal than the path. Ask a vector store for context about a payment change and it will happily return the three most similar paragraphs, which may be from a service you deprecated last year, because deprecated text still embeds close to current text.
Indexing by path removes the guess. The knowledge attached to the checkout directory reaches an agent working in the checkout directory. Nothing has to be similar to anything.
The query that never happens
The second broken assumption is that a query will be formed at all. RAG is triggered by one. If the agent does not think to ask, retrieval does not run, and an agent does not think to ask about a constraint it has never heard of.
This is the practical failure mode and it is quiet. Nothing errors. The agent simply writes the coupon onto the order total, because nothing in its context said not to, because nothing prompted the search that would have said not to.
Path-scoped delivery happens at hook time, before the first tool call. There is no query to miss.
Retrieval has no idea what a rule is
The third difference is enforcement. A vector store returns similar text. It has no concept of a constraint that must hold, no scope, no priority, and no ability to stop anything.
A rule in Pathrule carries all three. Its scope says where it applies, its priority orders it against others, and its enforcement level decides whether it informs the agent or gates the work. A strict rule can stop a matching change before it lands, which is a category of behaviour retrieval simply does not have.
This is not an argument against embeddings
Pathrule uses semantic recall. The difference is where it sits: as one input among several rather than as the whole strategy. The path decides which slice of knowledge is in play, and ranking orders what is inside that slice. Similarity is useful for ordering a candidate set; it is a poor way to choose the candidate set in the first place.
The practical result is a much smaller payload. Instead of stuffing the twenty most similar chunks into every turn and hoping the model reads the right one, the agent receives the knowledge that governs the path it is standing in. Smaller context is not merely cheaper; it is more accurate, because there is less for the model to be distracted by.
The [context layer explainer](/ai-coding-context-layer) covers the model, and [how retrieval works](/docs/retrieval/how-retrieval-works) covers how the slice is chosen and ordered. Claims here are dated August 2026.