Every chunk in a vector database exists as an isolated point. It has coordinates in high-dimensional space and a similarity score relative to any query. No edges, no connections, no awareness of other chunks.

This flat storage model is efficient for similarity search. It is fundamentally insufficient for agents that need to understand how information relates.

The Relationship Problem

In any real knowledge base, facts exist in relationship. A product spec connects to pricing. A user preference links to conversation transcripts. A company policy supersedes an older policy and applies only to a specific team.

Vector databases cannot represent these relationships. They store individual facts and retrieve by similarity, but connections — contradiction, supersession, dependency — exist nowhere in the index.

When an agent needs to traverse relationships, it must reconstruct connections from raw text. This is slow and unreliable. The agent might miss a contradiction because conflicting chunks were not retrieved together, or miss a dependency because the related document was not similar enough to the query.

What Gets Lost Without Structure

Contradiction detection is the first casualty. If Document A says "return window is 30 days" and Document B says "return window is 14 days," a vector database retrieves whichever is more similar. It cannot flag the conflict or determine which is current. A temporal model would recognize B as an update to A.

Provenance tracking disappears too. Knowing where a fact originated matters for trust. Flat storage strips source context during chunking.

Entity resolution suffers as well. The same customer referenced as "John," "jsmith@company.com," and "the Q3 client" across documents gets treated as separate references. Without entity linking, the agent cannot assemble a coherent picture.

How Graph Structures Change Retrieval

Knowledge graphs make connections first-class. Instead of retrieving by similarity and hoping the right chunks land together, the system traverses defined paths: entity → relationship → related entity.

This enables queries flat retrieval cannot handle. "What changed about pricing since last quarter?" requires identifying pricing documents, determining recency, and comparing versions. A graph traverses directly. A vector database needs multiple queries and manual comparison.

For agents modeling evolving preferences, graphs connect each preference to its conversation, timestamp, and subsequent updates — turning scattered embeddings into a coherent user model.

Frequently Asked Questions

Can embeddings capture relationships implicitly?

To a limited degree. Co-occurring concepts have closer embeddings. But this is correlation, not relationship. Embeddings cannot represent that Fact A supersedes Fact B or that Entity X belongs to Group Y. Explicit modeling is required.

How do knowledge graphs work alongside vector search?

Vector search handles the semantic component — finding conceptually related content. The graph handles structure — traversing explicit relationships. Results merge for both breadth and precision.

Conclusion

Vector databases find content that means something similar. They cannot model that content is related, contradictory, or sequential. For agents reasoning over connected information, flat storage is a structural limitation no embedding quality can overcome.