Revenue agents work from information scattered across systems: CRM records, call recordings, email, calendar and Slack. Every task, from a pipeline review to call preparation to risk assessment, starts by locating and reading that information, and without a shared layer the agent repeats the reading on every task. A knowledge graph removes the repetition. It processes each conversation once, on arrival, and stores judgments about every deal and account together with the supporting evidence, so the agent reads conclusions rather than raw data.
Benchmarking on questions related to the pipeline, such as which open deals are most at risk, shows that an agent working from the knowledge graph consumes 31× fewer tokens and completes the task 2.7× faster than the same agent reading the raw calls and emails, with higher accuracy (Figure 1). The gap comes from what the agent reads, not from the agent itself: both setups run the same agent, model, tools and sources. With the graph, the agent reads judgments already made about each deal and account; without it, it rebuilds them from raw data for every answer.
Figure 1. On questions related to the pipeline, the agent with the knowledge graph consumes 31× fewer tokens and completes the task 2.7× faster than the agent reading the raw sources, with higher accuracy. Bars represent the average per answer across five questions, three runs each.
Background
The CRM holds accounts, deals, stages and owners; call recorders hold what customers said; email, calendar and Slack hold the rest. A question such as which deals are most at risk, and why, requires the information on every open deal to be located and read, and the next question requires it again.
Without a shared layer, an agent has two strategies. Reading the sources for every task is thorough but slow, and its cost grows with the number of deals a task covers; models also use long contexts unevenly [2]. Retrieving the passages that appear relevant [1] consumes less but misses more, and questions about an entire body of information, such as which blockers are most common, are where passage retrieval is weakest [3].
A knowledge graph moves the reading to the moment a conversation arrives. This article describes the graph, the engineering it requires, and a benchmark of the same agent with and without it.
The knowledge graph
A knowledge graph represents a domain as entities and relationships, both typed and both carrying properties. This one is a live picture of a tenant's sales world. Its entity types are the things a sales team talks about: accounts, opportunities, contacts and users ingested from the CRM; people, each conversation participant resolved to one identity across systems; conversations, a call, an email thread, a Slack message, a calendar event; and judgments, each one conclusion about one aspect of an account or deal. Relationship types record how entities relate: a conversation has a participant, concerns an account and is attributed to the deals it discusses; a contact works at an account; an opportunity belongs to an account; a judgment is about its subject and is supported by the conversations and CRM fields behind it, down to the quoted words. The schema fixes which relationship types may connect which entity types, and every entity carries its source and timestamps, so any conclusion traces back to its origin.
Judgments. A judgment answers one question about an account or deal: where it stands, who is involved, what stands in the way, what happens next, how risky it is, the forecast, the MEDDPICC elements and, for customers, churn risk. Tenants define their own. Every judgment's supporting edges carry the conversations and CRM fields it rests on, with the verbatim quotes, so an agent reading a conclusion can check the words behind it.
Construction. ELT connectors land each tenant's CRM (Salesforce or HubSpot), call recordings (Gong or Chorus), email, calendar and Slack in a data lake. Every hour, offline batch jobs on a Spark cluster process whatever is new for each tenant: it turns raw rows into clean conversations, works out who took part and which accounts and deals each conversation concerns, judges every account with something new, and loads the resulting entities and relationships into the graph (Figure 2).
Figure 2. From raw sources to the knowledge graph. Connectors land each source in the data lake; every hour the pipeline turns new conversations and CRM changes into judgments that cite their evidence, and the agent reads the result from the graph.
Reconciliation. The pipeline exists because the sources disagree, and a graph is only as good as its contents. Two people record the same meeting and it arrives twice, so copies collapse to a single recording before anything reads it. CRMs log one email per recipient and per representative, so copies collapse to one message and bulk sends are dropped. Names do not match across systems, so entity resolution gives each participant one person entity, marked internal or external.
Attribution. The relationship every answer depends on is the conversation-to-deal edge: which deal a conversation is about. Auto-logged links are unreliable: a deal is often created in the CRM after the calls that led to it, renewal placeholders and long-closed deals attract links they should not, and Slack messages are never logged to a deal at all. The pipeline therefore treats attribution as a judgment rather than a lookup. A foundation model reads each conversation in the context of the account, its people and its deals, and decides which deals it concerns, citing verbatim quotes, whether or not the CRM record existed at the time.
Grounding and freshness. Every quote is verified against the stored text before a judgment is saved, and a judgment without evidence is refused. When evidence changes, a conversation moves, a quoted line disappears, a cited person or CRM field is removed, the judgment is re-derived, so each judgment rests only on current evidence.
Method
Experiment setup. The agent is a deep agent: Claude Opus 5.5 orchestrates each answer at medium reasoning effort, with a code sandbox and file tools, and delegates work to subagents when it chooses. In both setups it connects to the same sources, the CRM, call recordings, email, Slack and calendar, through MCP and native tool integrations, and to retrieval-augmented search over a vector index of conversations. The Graph setup adds the knowledge graph as one more source, readable through SQL. The Raw setup has no graph and is instructed to read each deal's calls and emails for every question.
Data. The test covers every open new-business deal in Von's own pipeline, with their accounts, contacts, recorded calls, CRM-logged emails, and the email, calendar and Slack content that users had connected. Customer and contact names are withheld throughout.
Questions. Ten questions of the kind sales teams commonly ask, each asked three times per setup (Table 1). Five are multi-subject, asked across every open deal or account in the pipeline. Five are single-subject, about one deal or account, including one comparison of three named accounts. A single deal's conversations are few enough to read directly, so a knowledge graph should help least there. A question across the pipeline makes an agent without one read every deal's information, so that is where it should help most.
Table 1. The ten questions. Bracketed names stand for real deals and accounts.
Measures. Cost is tokens consumed: the tokens of tool results that reach the main agent and its subagents, excluding the harness's own tools. Speed is seconds to complete the task: each answer's end-to-end time minus the steps both setups share. Accuracy is the answer score, from 0 (nothing correct) to 1 (a full match), against an answer key built from the same data. Each question's value is the mean of its three runs, and questions weigh equally within their group.
Results on multi-subject questions
Table 2. Results on the five multi-subject questions: means per answer over three runs. Multiples are computed before rounding.
Cost. Raw consumes 31× more tokens per answer than the graph: 323K against 10K. The graph consumes less on four of the five questions; the exception is the gone-quiet question, which Raw answers from CRM fields without reading conversations (see Shortcuts). No graph answer consumes more than about 21K tokens, while Raw's largest consumes 865K (Figure 3).
Figure 3. Every multi-subject answer, by what it consumed and how long it took. Graph answers cluster in the corner of low cost and little time; Raw answers spread up and to the right.
Speed. The graph agent completes the task in 82 seconds per answer, against 225 for Raw (2.7×). End to end, including the standard steps, its answers take 150 seconds against 299. The time saved comes from the questions that send Raw through many conversations: on the risk, blockers and champion questions the graph completes the task in 41–58 seconds, against 264–348 for Raw. On the two shortcut questions, Raw is faster than the graph and scores lower (see Shortcuts).
Accuracy. The graph's answers score 0.82 on average, against 0.67 for Raw (Figure 4). The graph scores higher on four of the five questions, one of them narrowly; Raw scores higher on deals without a champion, 0.82 against 0.70. In blind pairwise comparisons the judges prefer the graph's answer in 11 of 15, with one tie and three losses.
Figure 4. Accuracy on each multi-subject question. Marks are means of three runs; lines span the worst and best run. The graph scores highest on four of the five, and its runs stay close together.
Reliability. The graph's scores vary least from run to run. Averaged over the five questions, its worst runs score 0.81, close to its mean of 0.82, while Raw's worst runs fall to 0.50. Low variance partly reflects reading the same stored judgment in every run, so an incorrect judgment repeats.
Shortcuts. Two questions, on accounts that have gone quiet and on competitors, can be answered quickly from CRM fields: activity dates and a competitor picklist. Raw mostly answers them that way, making no conversation calls in four of its six runs. On gone-quiet accounts it answers from activity dates in every run and scores 0.42, against the graph's 0.81. On competitors it answers from the picklist in one run, scoring 0.02; in the two runs in which it searches the calls it answers correctly but consumes more tokens than the graph. This is what answering from CRM fields alone costs, and it is the shortcut an agent without precomputed judgments is drawn to.
Single-subject questions
A single deal's conversations are few enough to read directly, so this is the group where a knowledge graph should help least, and it is the group in which the two setups come closest (Table 3, Figure 5).
Table 3. Cost and speed on the five single-subject questions, in the same form as Table 2.
On accuracy the two setups are statistically indistinguishable, and each scores highest on some questions. The cost and speed advantages remain but are smaller: Raw consumes 5.4× more tokens per answer, against 31× on multi-subject questions, and the graph completes the task 2.0× faster, 62 seconds against 123.
Figure 5. Cost and speed by question group. The graph's consumption stays flat as questions widen, while reading the sources grows with them. Bars are averages per answer, five questions and three runs per group.
Conclusion
Precomputing context moves the cost of reading from task time to the moment conversations arrive. On questions related to the pipeline, an agent working from the knowledge graph consumes 31× fewer tokens than an agent instructed to read the sources, completes the task 2.7× faster, and scores higher on average, with worst runs close to its average where Raw's collapse. The savings scale with the breadth of the question: the more deals a question touches, the more an agent without precomputed context must read, while the graph's consumption stays roughly constant.
References
- Lewis, P., Perez, E., Piktus, A., et al. (2020). Retrieval-augmented generation for knowledge-intensive NLP tasks. Advances in Neural Information Processing Systems 33. https://arxiv.org/abs/2005.11401
- Liu, N. F., Lin, K., Hewitt, J., et al. (2024). Lost in the middle: How language models use long contexts. Transactions of the Association for Computational Linguistics, 12. https://doi.org/10.1162/tacl_a_00638
- Edge, D., Trinh, H., Cheng, N., et al. (2024). From local to global: A Graph RAG approach to query-focused summarization. arXiv:2404.16130. https://arxiv.org/abs/2404.16130
