Context graph vs. knowledge graph vs. vector database
Teams wiring customer context into their agents run into these three terms fast, usually in the same vendor paragraph. They sound like three competitors and they name different kinds of things. A vector database is storage infrastructure. A knowledge graph is a data structure. A context graph applies that structure to one domain, your customers, and ships with the schema already decided. Sorting out which is which matters because the wrong pick fails quietly. Everything works, and the agent still answers generically.
Modem, the product we work on, reads feedback channels like Slack, Discord, and support tickets and maintains a customer context graph from them, so we sell one of the three. The definitions below don't depend on that.
What a vector database is
A vector database stores embeddings (numerical representations of text) and retrieves the stored chunks most similar to a query. It's the typical retrieval layer in a RAG setup. You embed your documents ahead of time; when a question arrives, it gets embedded too, and the store returns the nearest neighbors. Pinecone, Weaviate, Qdrant, and pgvector inside Postgres are the common picks, and every one of them is good at the job. The job is similarity, and only similarity. A vector database carries no domain model, just chunks and metadata, so it has no opinion about whether two chunks describe the same bug, or whether the person behind one of them pays you.
What a knowledge graph is
A knowledge graph stores entities and typed relationships. This person works at this company; this ticket references this feature. Queries traverse the edges, so a question that crosses entities, like "which companies filed tickets about rate limits," is a direct lookup instead of inference. It's a general-purpose structure. Google's version models the public world, and an enterprise version might model products, suppliers, and contracts. Graph databases like Neo4j and open-source frameworks like Zep's Graphiti are how you build one. What the graph contains is up to you, which is the power and also the bill, because someone has to define the schema, extract the entities, and keep the edges current.
What a context graph is
A context graph is a knowledge graph with a fixed, opinionated schema, built to hold what agents need for customer-facing work. The term is newer than the other two, and you'll mostly meet it from vendors selling customer-context products, ours included, so here is the shape any version has to have. Topic, customer, and company entities, joined as feedback arrives rather than at query time. Concretely, in the version we build, an SSO request that surfaced in an Intercom ticket, an email thread, and a shared Slack channel is one topic node with three source edges, each keeping the original quote. The people who raised it resolve to customer nodes. Each of those links to a company, which carries whatever plan and revenue data your billing and CRM integrations supply. Ask "which accounts are blocked on SSO" and the answer is a walk across those edges, quotes included. The joins happen at capture time, which is the property that separates a context graph from a pile of retrievable text; the full definition covers it in depth. You can build one yourself on graph infrastructure, or use a product like Modem that maintains one from the channels you connect.
The differences at a glance
| Vector database | Knowledge graph | Context graph | |
|---|---|---|---|
| What it is | Storage + similarity search | Entities and typed relationships | A knowledge graph with a fixed customer schema |
| Answers | "What looks like this?" | "What connects to this?" | "Who said this, how many, and what do they pay us?" |
| Domain model | None (chunks + metadata) | Yours to design | Ships opinionated: topic, customer, company, quote |
| Kept current by | Re-embedding on change | A pipeline you build | The vendor, or your pipeline if you build |
| Best at | Fuzzy recall over lots of text | Cross-entity questions in your domain | Customer context for agents, ready-made |
Why vectors alone leave agents generic
The tempting architecture is the simple one. Embed every ticket and thread, give the agent retrieval, done. It fails in a specific way. Ask "what do customers say about onboarding?" and similarity search returns the twenty chunks that look most like the question. Three of them describe the same bug in different words, and nothing says so, which means the counts are wrong. The reporters aren't linked to accounts, so there's no answer to "who," and no way to weight by revenue. The agent gets lookalike text where it needed joined facts, and it produces a fluent summary that's missing the context the question was about.
issue filed·
report writtenNone of this is an argument against vectors. Embedding similarity is how a graph pipeline finds merge candidates in the first place, and the pattern of combining the two has a name, GraphRAG, with Microsoft's open-source implementation and Neo4j's tooling both built on the observation that similarity search alone struggles with questions that span a corpus. Graph databases have been adding vector indexes for the same reason. The argument is for structure on top of similarity. Similarity finds text that resembles other text; establishing facts about entities takes joins.
When each wins
Vector database: your corpus is documents, not entities. Searching docs and wikis, recalling passages from meeting notes. If the questions are "find me the passage," similarity is the whole job and a graph is overhead.
Knowledge graph: your questions cross entities in a domain no product models for you, a supply chain or a body of research literature. You'll pay for schema design and a maintenance pipeline, and for a custom domain that price is correct.
Context graph: the entities are customers, topics, and revenue, and the consumer is an agent or a team that needs current answers. Nearly every B2B team has this same domain, which is why the schema and the maintenance are buyable, and that is the case against building. The graph is standard, and keeping it true is the expensive part.
More than one: common in practice. A vector index over docs plus a context graph over customer signal answer different questions, and agents wired to both over MCP pull from whichever fits the task. The memory-tools comparison covers a neighboring axis, whose memory the store holds, and agent memory explained covers why the context window is none of these.
The short answer
Choosing storage for fuzzy recall over text: vector database. Modeling a custom domain where questions cross entities: knowledge graph, budget for the pipeline. Giving agents customer context, the who-said-what-and-what-do-they-pay layer: that's a context graph, and the remaining choice is build or buy, not which structure.
