Building the archzOS stack: why we chose a hybrid vector-graph architecture
When we started building archzOS, the obvious architecture was: ingest everything, embed it, throw it in a vector database, and call it search. This is the default architecture for any AI-powered search product built in 2024.
We rejected it. Here's why.
The limits of pure vector search
Vector search is excellent at semantic similarity. Ask it "what did we decide about the Q3 roadmap?" and it will find documents that are semantically related to that query.
The problem: organizational intelligence isn't a semantic similarity problem. It's a relational problem.
Consider: you want to find the decision about the Q3 roadmap. That decision was made in a Slack thread, then referenced in a Jira ticket, then documented in a Notion page, then mentioned in a Google Doc that was shared with leadership. The final authoritative source is the Google Doc. But the context that makes the decision legible — the debate that led to it, the alternatives considered — lives in the Slack thread.
Vector search returns the most semantically similar documents. It doesn't understand the relationship between those documents.
Why graph matters
A graph representation lets us model the relationships between pieces of knowledge:
- Document A references Document B
- Decision D was made in Thread T by Person P
- Person P is a member of Team X
- Team X owns Project Y
With these relationships, we can answer questions that pure vector search can't: "Who made this decision? What was the context? What other decisions depend on this one?"
This is what we mean by organizational intelligence — not just finding relevant documents, but understanding the web of context around any piece of information.
The hybrid architecture
Pure graph search has its own limitations: it's slow, it requires explicit relationship modeling, and it doesn't handle fuzzy queries well.
So we built a hybrid. The query path is:
1. Semantic retrieval: vector search identifies candidate documents and entities 2. Graph traversal: for each candidate, we expand the context graph to retrieve related entities 3. Reranking: a second model scores results based on both semantic relevance and graph proximity 4. Synthesis: results are returned with relationship context, not just document snippets
The result: 42ms P99 latency at production scale, with dramatically better answer quality than pure vector search for organizational queries.
What we learned
The architectural insight that shaped everything: enterprise knowledge is a graph. Documents reference other documents. People are connected to projects. Decisions have dependencies. Any search system that ignores those relationships is solving the wrong problem.
The engineering cost of this approach is real — it's harder to build, harder to scale, and harder to explain to customers than "we use vector search." But for the use case of organizational intelligence, there's no simpler solution that actually works.