Do you need a vector database to share team knowledge? No.
Somewhere in your team's planning doc there's a line like "embed our decisions and docs, put them in a vector database, let the agents search." Before you stand any of that up, look at the corpus you're actually indexing.
Engineering decisions are small and structured
A team that records decisions for years ends up with thousands of records, not millions. And they aren't prose blobs. Each one names the element it touches, says what changed, why, and what was rejected, and links to what it superseded. That's a small, structured corpus with real handles on every record.
Similarity ranking earns its keep when you have millions of unstructured chunks and no better handle than "roughly about this." Against a few thousand named, linked records it mostly adds infrastructure and a new failure mode. Two machines can rank the same question differently, the index needs feeding, and "why did it retrieve that" has no crisp answer.
What deterministic recall looks like
kgai, which we build, takes the other route on purpose. Recall is lexical matching plus graph traversal over an append-only, immutable decision log. No embeddings in the read path, by design. The same question against the same store gives the same answer on every teammate's machine, and it returns only decisions still in force. When the words don't match, the asking agent is a language model already, so it bridges synonyms by rephrasing the query. In practice that's enough.
Determinism is also what makes the record trustworthy. When an agent is about to re-propose the database your team rejected, you want the rejection found every time, not probably ranked somewhere near the top. And because there's no embedding pipeline, there's nothing to operate. No daemon, no server, no index to rebuild. The store is local, sync is opt-in over an S3 bucket you own, and the whole thing is MIT, a Claude Code plugin plus a standalone kg CLI.
Where vectors do make sense
Large unstructured corpora. Support tickets, research notes, docs, years of chat history. Millions of prose chunks with no structure to traverse is exactly the shape similarity search was built for, and tools in that category are genuinely better at fuzzy recall over prose than we are. We say the same in our comparison with Mem0. Different corpus, different physics.
So the question isn't whether vector databases are good. It's whether your team's decisions are that kind of corpus. They aren't.
If the knowledge you want shared is why the code is the way it is, you can have it recorded and recalled without an embedding in sight. Two commands and your agents start reading the same record.
Try it on your repo. Two commands, MIT, nothing leaves your machine until you configure a bucket.
See how kgai compares to other tools on the comparison page, or browse the other notes.