Claude is incredibly good at reasoning.
But reasoning is only as useful as the context available to it.
Your architecture might be in GitHub. You...
For further actions, you may consider blocking this person and/or reporting abuse
The retrieval taxonomy is solid. The difficult part is proving that the router and fusion layer improve answers instead of merely adding more ways to retrieve the same stale claim. I’d build a gold set labeled by question shape and required evidence, then log which retrievers ran, candidate ranks, evidence coverage, contradiction rate, latency, and token cost. Compare against vector-only and keyword-only baselines, plus ablations with each retriever removed. For graph expansion, require the entry entity to come from cited evidence rather than a model guess. Exposing that retrieval trace through MCP would make
search()return not just context, but a debuggable reason why this context won.Exactly — the goal is not more retrieval, but provably better retrieval, with MCP exposing the evidence and trace behind every result.
In my pipeline I ran into a version of this six months back: Postgres and PostgreSQL were separate clusters, and traversals from one side just didn't reach the data on the other. Found it only when a query came back half-empty and I dug into the graph manually. The tricky part was the threshold; set cosine at 85% on normalized names but that collapsed things that should've stayed separate. How are you handling service name normalization, or hasn't it been an issue yet?
The Postgres/PostgreSQL split is the same failure shape as a bug I hit on the code side, just one level up — there it was two definitions of the same symbol name in different directories, here it's two spellings of the same entity in different clusters. Both get treated as "found a match" with no signal that there might be a second, disconnected node representing the same real thing.
A single cosine threshold probably can't win here either way — 85% collapsing things that should stay separate is the same trade-off my path-based downranking hit: any single global heuristic tends to be right in one direction and wrong in the other. What worked better for symbol resolution was combining signals rather than picking one threshold — proximity/context plus a corroborating signal (for you maybe: same connection string, same port, co-occurrence in the same PR/commit) rather than name similarity alone deciding it.
Agreed — I haven’t implemented entity resolution yet, but I’ll treat it as a multi-signal problem rather than a single threshold.
Haven’t hit this issue yet, but it’s a good edge case to account for
Really interesting architecture. The part I keep wondering about with an AI-native knowledge layer is what happens when the knowledge itself changes.
A decision can be correct today and become obsolete six months later. A newer ADR might contradict an older decision, a repository change might invalidate a relationship, or a previously important memory might no longer be authoritative.
So I'm curious how you'd approach knowledge freshness and authority in this kind of system.
Is the harder problem actually retrieving the right context, or knowing which context should still be trusted when multiple sources disagree?
I think retrieval finds the candidates, but freshness and authority decide what to trust—using timestamps, source priority, and supersedes/contradicts relationships to handle conflicting knowledge.
Yeah, that distinction makes a lot of sense. Retrieval and trust feel like two separate layers — finding the relevant context is one problem, deciding whether that context is still authoritative is another. I think that second layer becomes especially important as project knowledge accumulates over months.
Exactly — retrieval finds the information, while the trust layer decides what’s still valid and authoritative.
This maps closely to what I've been measuring on a real MCP codebase-intelligence server (Python, 50K LOC). A couple of things that showed up empirically and might be useful for the "which retrieval method for which question" framing:
Query-agnostic graph ranking (PageRank) vs query-aware retrieval (BM25) isn't close on exact-file retrieval — RAG won 50% vs 36% Hit@Gold on a dense call/import graph, n=50. PageRank alone tends to just surface structural hubs, not what's actually relevant to the question. Might be worth factoring into your "Graph RAG" section — the graph seems more useful as a complement to query-aware search than a retrieval method on its own.
On the "one retrieval call vs several" angle: I ran a paired comparison (N=30) between a multi-tool agent flow and a single composed context call. The aggregated call won decisively on latency and round-trips, but only when it includes source+symbols by default — an aggregator that's too eager to compress (or too selective) tanks recall fast. Something to watch if the MCP layer here ends up doing composition server-side.
One practical failure mode worth flagging for anyone building the entity graph: symbol/definition lookups can silently resolve to the wrong file if there's a same-named shadow definition elsewhere in the repo (e.g. in experiments/ or tests/). Cheap to guard against, easy to miss until it poisons a whole retrieved context block.
Curious whether you're planning to measure retrieval quality once this is running, or if it's staying architecture-first for now.
Definitely planning to measure it—this is exactly why I want the architecture to be evaluation-driven.