Why graph reasoning beats vector search for engineering questions
Vector similarity finds documents that look like your question. The answer usually lives in a chain of artifacts that don’t.
Vector similarity finds documents that look like your question. The answer usually lives in a chain of artifacts that don’t.
Search returns matches. Engineering questions need the chain of decisions behind the match — and that is a different shape of system.
The constraint that shaped a design rarely lives in the diff. We trace it back to the thread, the review, and the ticket that scoped it.
decided-in, scoped-by, implemented-by, authored-by. The edge vocabulary is what turns a pile of artifacts into an answerable graph.
A learning committed by one agent should be a node any agent can reach. We treat agent memory as a first-class part of the graph.
Embeddings are great entry points and a poor finish line. We use similarity to enter the graph and structure to reconstruct context.
When retrieval is a traversal, every hop is a citation. Answers carry their sources because of how they were assembled, not as an afterthought.
Real context is scattered across tools that never agreed on a schema. Normalizing them into typed nodes is most of the work.
The same reasoning graph has to answer an engineer in a hurry and an agent mid-task. We design the retrieval surface for both.
