The best tools to build a customer context graph in 2026

Short answer. There is no single best tool, because "context graph" covers four different jobs. If you need an agent to remember facts about one user across sessions, a memory layer (Mem0, Zep, Letta) is the better buy. If you want a general store you fill and query yourself, use Neo4j for graphs or Pinecone for vectors. If employees need to search every company app with each source's permissions intact, that is Glean. If the job is linking support tickets, chat threads, accounts, and the issues and PRs that address them into one customer-specific graph that already exists when an agent asks, Modem (our product) is built for it. Modem reads conversations from the sources you connect, groups them into topics by meaning, and links each topic to the people and companies behind it and to the engineering work that addresses it. It covers the customer domain only, knows only what you connect, and is not a general-purpose memory store.

Most teams that ask this question have the same problem. A customer reports a bug in Zendesk, mentions it again in a shared Slack channel, and a different person from the same company brings it up on a call. Somewhere else a GitHub issue and a pull request exist for it. Nothing connects those records, so the agent you point at your tools reads each one in isolation and answers generically.

We build Modem, so read its entry with that in mind. It is listed first because it is the only item here that arrives as the finished customer graph, not because it fits every job. Several of the other tools are the better choice for a job we do not do.

Four jobs that get called "context graph"

"Context graph" is not a settled term. Neo4j uses it for a memory architecture for agents, Zep uses it for a temporal graph whose facts expire, and Modem's site uses it for customers, topics, and companies linked across sources. Inside Modem's docs the pieces are called topics, sources, people, and companies. So decide which of these jobs you actually have.

Job	What it needs	Tools in this guide
Move data out of your systems	Connectors and a schedule	Airbyte, Graphlit feeds, Glean connectors
Store and query	A graph or vector database you fill	Neo4j, Pinecone
Remember facts for an agent	Extraction, recall, scoping per user or agent	Zep and Graphiti, Mem0, Letta
Link customer conversations to people, companies and engineering work	Identity resolution, grouping, links to issues and PRs	Modem, or a build from the parts above

The fourth job is the one the buyer questions behind this guide keep circling. The other three are parts you would assemble to do it yourself.

The criteria used below

1. Sources. Which of your tools it reads without you writing a connector.
2. Identity. How it decides a Zendesk contact, a Discord handle, and a Salesforce account are the same person or company.
3. Links to work. How a conversation gets tied to an issue or pull request.
4. Agent access. How an agent asks it a question, and what it can write.
5. Time. Whether facts keep history or expire.
6. Ownership. What you build and maintain afterward.

The short version

Tool	What it is	Reads your support, chat and tracker tools	Identity across systems	Entry point
Modem	Customer context store	Yes, 18 sources including Slack, Discord, Zendesk, Intercom, Gong, Linear, Jira, GitHub, GitLab	Built in, exact email and platform account	See Modem's pricing
Zep and Graphiti	Temporal graph engine plus a hosted agent-memory platform	You send data in; no native Zendesk or Discord connector found in its docs	You model it	Free tier on the hosted platform; Graphiti is open source
Mem0	Agent memory layer with optional graph memory	You send data in; no native connectors found	You build it	Free tier; Apache 2.0 open-source core
Letta	Platform for stateful agents with editable memory	No native connector found in its docs	You build it	Free tier; Apache 2.0 open source
Neo4j	Graph database	Storage only	You build it	AuraDB Free; Community Edition is open source
Pinecone	Managed vector database	Storage only	You build it	Free Starter plan
Glean	Enterprise search with an Enterprise Graph	275+ connectors	Not described in what we found	Per user, per month
Graphlit	Developer API for ingestion and semantic search	30+ feeds including Slack, Gmail, GitHub	Not described in what we found	Free tier

Entry points were checked against each vendor's pricing page in October 2026, and plans change, so use the vendor's page for current terms. "Found" and "not found" mean what we saw in vendor docs and search results, not that a capability is absent.

1. Modem

Modem reads conversations from the tools your customers use and keeps one maintained view of them. It ingests Slack, Discord, Microsoft Teams, Intercom, Zendesk, Pylon, Plain, Email, Canny, Gong, Fathom, Linear, Jira, GitHub, GitLab and more (Front and X are beta, enabled per organization). Anything else can be pushed in through the Ingest API. Stripe and Salesforce are not feedback sources. They are read-only data the agent can join to, and nothing from them becomes a topic.

What it stores and links. Every message is kept verbatim with its source, author, and thread. Modem splits a conversation into the separate concerns inside it, so a thread that raises three problems yields three, and groups concerns into topics by meaning. A topic keeps its change history and every message behind it. Topics are linked to the people and companies who raised them, and to the Linear, Jira, GitHub, or GitLab issues and pull requests that address them. Those links are typed and keep history, so a concern that moves topics leaves a record. It is a relational database, not a graph database and not a vector store. Embeddings are one retrieval signal, used to find related concerns and for meaning-based search. People are never matched by embedding.

Identity. People are matched by platform account and exact email. The same email on Zendesk and in a shared Slack workspace is one person. Companies come from the Slack workspace a person belongs to and from the work-email domain (free providers like gmail.com are skipped). Discord gives Modem no email, so Discord people stay separate until someone merges them by hand, and merges cannot be undone yet. We chose exact matching on purpose. Email addresses are often weak keys (shared inboxes, changed addresses), so some real duplicates stay as two people until a human decides.

Engineering work. Issues and pull requests are sources too. Modem links a topic to the ones that address it by what they say, and a pull request must be in a connected repo. Because the join is by meaning, treat it as strong evidence and not a guarantee. Modem does not read your source code, diffs, or file contents.

Plans and revenue. Plan and revenue data from Stripe sits on the companies behind a topic, and the agent joins it to topics when you ask ("which paying customers reported bugs this month?"). Salesforce is a read-only sync the agent can query. There is no HubSpot integration. Priority is an AI-assigned score that weighs severity, how many companies are affected, and recurrence, among other signals. It does not rank by revenue.

Why we built it this way. An agent given raw access to Slack, Zendesk, and GitHub re-reads threads every time and still misses the half that lives somewhere else. So Modem builds the groups and topics as messages arrive, and the agent reads findings instead of threads. The tradeoff is that counts are counts of concerns, not conversations or people, and Modem only knows what you connect.

Where it fits: teams that want "who hit this, which company are they, and is a fix in flight" answerable without owning a pipeline. Where it doesn't: domains outside customers and product work, per-user conversational memory for an app you ship, or per-document permission inheritance across your whole company.

2. Zep and Graphiti

Graphiti is Zep's open-source library for temporal knowledge graphs. Each fact has a validity window, so when new data contradicts an old fact the old one is invalidated instead of overwritten. Graphiti runs on Neo4j, FalkorDB, or Amazon Neptune (with OpenSearch Serverless for full-text search), and a Kuzu backend is deprecated. Zep sells a hosted platform on top of it with agent memory, graph RAG, a context lake, and a Memory MCP server. Retrieval combines vector, full-text, and graph traversal in one call. Zep also calls its graph a "context graph."

Where it fits: a team building an agent that must remember how facts change over time, with the people to own the schema and the sources. The time dimension is a real strength of its model. Where it doesn't: you send the data in. We found no native Zendesk, Discord, or Salesforce connector in its docs, and matching a Discord handle to a Salesforce account is your job. Zep bills by credits per ingested episode, so see Zep's pricing before you estimate volume.

3. Mem0

Mem0 is a memory layer with an Apache 2.0 open-source core, a managed platform, and an OpenMemory MCP server for coding agents. It is not limited to conversation text. Its docs describe an extraction pipeline that stores facts, embeddings, and entities and relationships, and on the platform the extracted entities become the nodes of Graph Memory, which sits on the Pro plan. Retrieval mixes semantic, keyword, and entity matching.

Where it fits: giving an agent or app you ship durable memory of its own users, with a hosted API or a library. Where it doesn't: the real gap is cross-system identity resolution. Mem0 links the entities it extracts from what you send. It does not decide that a Discord complaint, a Zendesk ticket, and a Salesforce account belong to the same company, so you build that yourself. See Mem0's pricing.

4. Letta

Letta (formerly MemGPT) is an open-source platform for stateful agents under Apache 2.0. Its documented memory has two parts. Memory blocks live inside the context window and are always visible to the agent, and archival memory is a semantically searchable store the agent queries through tools. We did not find a graph model in its docs, which is not the same as saying it has none.

Where it fits: agents that edit their own memory over a long life, where the agent itself is the product. Where it doesn't: it is an agent runtime, not a pipeline from your support desk to your tracker, and we found no native connectors for those tools. See Letta's pricing.

5. Neo4j

Neo4j is the general-purpose graph database. The Community Edition is open source under GPLv3, the Enterprise Edition is commercial (Neo4j calls this open core), and AuraDB is the managed cloud with a free tier. Vector indexes sit alongside the graph so similarity search and traversal live in one store, and the neo4j-graphrag Python package supports hybrid retrieval.

Where it fits: the storage layer when you are building your own graph, or when your data is not customer feedback at all (a logistics network, a research corpus, a permissions model). Where it doesn't: it stores the graph you give it. We found nothing in Neo4j's docs that extracts entities from your tickets or resolves identities for you. Neo4j's own blog describes a context graph as a memory architecture with decision traces, which is a modeling pattern you implement. See Neo4j's pricing.

6. Pinecone

Pinecone is a fully managed vector database. Retrieval over messy text, such as help articles and old tickets, is what it is for, and a vector store is the right answer to "what is our policy on X?" Pinecone now also sells Nexus, a knowledge engine above the database, and describes Nexus as not a vector database. We found no graph query language described in what we read.

Where it fits: fast semantic recall over documents and transcripts. Where it doesn't: vector similarity alone does not tell you which company a message came from, whether a fact is still true, or which PR addresses a bug. Those are relationship and time questions that a graph, or a store like Modem, answers. See Pinecone's pricing.

7. Glean

Glean is for employees searching and acting across a company's apps. Its Enterprise Graph combines a company-wide knowledge graph with a personal graph per employee, is built by machine learning in a single-tenant environment, has 275+ connectors, and inherits and enforces source-system permissions. Pricing is per user per month, with model usage billed on top, and no dollar figure was published in what we found.

Where it fits: "find and use what our company knows," where respecting who may see each document matters most. If that is your problem, Glean is the better buy than Modem. Where it doesn't: we found nothing in its docs that positions it for clustering customer feedback into topics. See Glean's pricing notes.

8. Graphlit

Graphlit describes itself as a context layer for AI agents. One API handles ingestion, extraction, storage, and retrieval, with entities, relationships, and temporal state. It ships 30+ feeds including Slack, Gmail, GitHub, S3, and RSS, hybrid search over vectors, keywords, and graph traversal, and an MCP server for Claude Desktop, Cursor, and similar clients.

Where it fits: a developer who wants a hosted ingestion-to-retrieval layer and will define what the entities mean. Where it doesn't: the feed list we read names Slack, Gmail, GitHub, S3, and RSS, so check it for Zendesk and Linear before you commit. How it resolves one person across feeds is not described in what we found. See Graphlit's pricing.

The plumbing: Airbyte and Clay

These are not memory layers, but a DIY build tends to include them.

Airbyte moves rows out of SaaS tools into a warehouse or database. Airbyte Core is free to self-manage, it lists 600+ connectors (some of its pages say 700+), and it has Zendesk Support and Salesforce connectors. Its cloud pricing is now tiered. Standard and Plus are volume-based, while Pro and Enterprise Flex are capacity-based. It lands rows, not relationships, so everything that makes the rows a graph happens afterward. See Airbyte's pricing.

Clay enriches a person or company from data providers tried in sequence, and you pay only for the lookup that returns a match. It is useful for filling gaps in company data before you link against it, and it does not connect records to feedback. See Clay's pricing.

When a CRM or a vector store is enough

Do not build a graph to answer a question your existing tool already answers. A CRM is the system of record for accounts, pipeline, and renewals, and a customer context graph sits beside it and adds the conversations and engineering history around those accounts. If your question is "what is this account worth and when does it renew," ask the CRM. If it is "what do our docs say about X," a vector store is simpler. A graph earns its cost when the question crosses systems, like "which accounts reported this, and is the fix in review."

How agents read the result

This is where the tools differ most in practice, so here is Modem's access surface in detail.

• MCP server. https://mcp.modem.dev/mcp, over OAuth with no API key to mint. It exposes 16 tools and is in beta. Three are read-only (search_modem, plus the modem_docs and modem_skills helpers). Four start and manage agent runs (modem_agent_invoke, modem_agent_get_run, modem_agent_send_message, modem_agent_cancel_run), and the remaining nine are record-editing tools for topics, people, and companies. A data:read token sees only the read tools.
• search_modem. You ask a question in plain language and get a short answer plus the matching rows, with flags that say whether the result is complete, truncated, or partial. It is read-only and spends no agent credits.
• modem_agent_invoke. Starts the full Modem agent, which can use your connected tools, so it spends credits. Agent turns started over MCP have no approval prompt. Write tools run as the signed-in user with that user's role.
• REST API. https://api.modem.dev/v1, with an organization API key. It reads topics (with optional semantic search), people, companies, groups, and channels, and can edit them. Topic detail does not return linked issues or PRs, and there is no message-search endpoint, so for those an agent uses search_modem or an agent run.
• Ingest API. Write-only, for sending conversations in from a source Modem does not have. It is separate from the REST API, which does not accept messages.
• Limits. MCP allows 20 calls per minute per organization per tool, and REST allows 120 per minute per key. An agent can only reach what Modem has stored from connected sources, not a live read of Slack or Zendesk, and text removed by data-scrubbing rules before storage is gone. Agent memories and Org Skills persist across sessions but are not exposed over MCP or REST.

Modem can also hand work onward when a teammate asks. Its agent writes a free-text brief and gives it to Claude Code, Cursor, or Devin through each vendor's own API and key (not MCP). Claude Code and Cursor are set up to open a PR, and Devin gets only the prompt. In Slack and, by default, in the dashboard, Modem shows the task and waits for a click first. Discord, Teams, and MCP-run turns have no approval step. Modem does not link the delegated task to the topic, though a merged PR can join a topic by content if its repo is connected.

An illustrative question, not a recorded result. You ask a coding agent connected over MCP, "Which paying customers hit the export timeout, and is a fix in review?" Answering it takes four joins. Reports from Zendesk and Discord need grouping into one topic, the people behind them need resolving to companies, billing needs matching to those companies, and the topic needs tying to a pull request. Each is a separate build in a DIY stack. Modem maintains the first, second, and fourth as sources arrive, and the billing join happens when the agent is asked.

Start with one join before you buy anything

You can test whether you need a graph with a spreadsheet. It takes an afternoon and shows you which link is missing.

1. Pick the key. For most B2B teams it is the work-email domain, which stands in for the company.
2. Make one table. Columns for company domain, ticket ID, chat thread link, CRM account ID, and issue or PR ID.
3. Fill it for the last 20 customer-reported bugs. Search the tracker for the error text or the feature noun, not the customer's wording.
4. Ask your agent three questions the table should now answer. Who else reported this, which account is it, and is there an open PR? Note where it guesses.
5. Keep names out of public repos. If the tracker is public, store customer names and private links in the table, not in issue comments.

If 20 rows are easy to maintain, you may not need a tool yet. If the table goes stale within a week, or the identity column keeps needing manual fixes, that is the cost the tools above are selling. Our build guide and the explainer go deeper on the data model.

If you build it yourself

These are the components that turn a weekend script into a maintained system. We list them as components, not as an effort estimate, because we have no sourced number to give.

• A store that keeps the verbatim message with its source, author, thread, and container state, since a summary alone cannot be quoted.
• Extraction at the level of a concern, with re-extraction that updates a concern instead of duplicating it.
• Topic placement over time, including a difference between a topic the system dissolved and one a person dismissed.
• A link model for evidence and membership with history, and a rule for how an issue or PR joins a topic.
• Identity resolution across platforms, because "who is affected" is a join through it.
• A meaning-based index next to exact search.
• A way for agents to ask questions, with authentication, scopes, rate limits, and a read path kept separate from anything that writes.
• Redaction before data is stored, embedded, or sent to a model.

How to choose

• An agent that remembers each user across sessions: Mem0, Zep, or Letta.
• Facts that change and must expire: Zep and Graphiti.
• A general graph you model yourself, or data outside customer work: Neo4j.
• Semantic recall over documents: Pinecone.
• Employees searching every company app with permissions inherited: Glean.
• A developer-run ingestion and retrieval API: Graphlit.
• Customer conversations linked to people, companies, and engineering work, already assembled: Modem.

These stack. A team could run Modem for the customer domain and a memory layer for its own app's per-user memory, and neither replaces the other.

FAQ

What is the difference between a context graph, a knowledge graph, and a vector database?

A vector database finds items whose embeddings are near a query. A knowledge graph stores entities and typed relationships, and some add ontologies or validity windows. "Context graph" is used for a graph arranged for an agent's use, and vendors define it differently. Several of them combine vector search with graph traversal, so these are not exclusive categories.

Is a memory layer like Mem0 or Zep enough to link tickets, CRM records, and engineering work?

It covers part of the job. Both extract entities and relationships from what you send them, and Mem0 offers graph memory with entity linking. What they leave to you is the cross-system part, meaning connectors for your tools and the identity resolution that decides a Discord handle, a Zendesk contact, and a Salesforce account are the same company.

Is Modem a graph database or a vector store?

Neither. Modem stores messages, topics, people, and companies in a relational database, with typed links between them that keep history. Embeddings are one retrieval signal for finding related concerns and for meaning-based search.

Does Modem put plan and revenue data on the graph?

Stripe plan and revenue data sits on the companies behind a topic, and the agent joins it to topics when you ask. Salesforce is a read-only sync the agent can query, with no stored link to Modem companies. There is no HubSpot integration.

Can a coding agent query Modem?

Yes, through the MCP server (in beta) or the REST API. search_modem is read-only and spends no credits. Agent turns started over MCP have no approval prompt. See best MCP servers for customer feedback for how it compares with other servers.

Does Modem read my source code?

No. Modem syncs issue and pull request text, labels, and review comments from connected repos. It does not read file contents, diffs, or the repository tree.

Which one should a software company start with?

Start with the spreadsheet above to see which join hurts. If the pain is a missing company link across support and chat, a customer-specific tool like Modem fits. If it is an agent forgetting what a user said last week, start with a memory layer.