The GTM Context Graph

In 2022, in a public library in Palo Alto — we didn't have an office yet — Alok and I sat down to design FunnelStory's data model. The core idea was simple: accounts have users, and users perform activities. That was the whole thing. This was before ChatGPT, before anyone talked about LLMs as a product surface. We were just reasoning from first principles about how GTM data fits together.

I never imagined that sketch would become what we now call a GTM Context Graph. But that early model — accounts, users, activities, and the relationships between them — turned out to be the substrate for everything that came later.

Today, every enterprise serious about AI is hitting the same wall.

The first copilots made it easy to point an agent at Salesforce, Zendesk, Slack, product usage, and transcripts, and ask it to reason. That works in demos. It breaks in production. The problem is not a weak model, or messy CRM data. It is architectural. Most agent systems reconstruct business context at runtime, inside the model's context window, every time someone asks a question.

For GTM, that is the wrong place to do the work.

RAG retrieves context at runtime. A context graph maintains computed truth before runtime.

That distinction is the whole post.

Why GTM data is hard

GTM data lives in two forms.

Structured data — CRM fields, renewal dates, usage events, ticket metadata — looks queryable. In practice it is fragmented across systems and full of local conventions. It tells you an account has a renewal in 60 days, five open tickets, and declining usage.

Unstructured data — calls, support threads, emails, transcripts — is where the real truth often lives. It tells you the economic buyer has gone quiet, the admin is frustrated about a product gap, and those five tickets are really one unresolved issue.

Neither side, on its own, tells you whether an account is actually at risk.

The hard problem is not searching either one. It is synthesizing both into a single model of what is true about the customer.

That is where naive RAG fails. Take a question:

What are the top feature requests from accounts renewing in the next 90 days?

To answer it, a system has to:

• filter accounts by renewal date, which lives in structured CRM fields;

• find the feature requests, buried in tickets, calls, and emails;

• attribute each request to the right account, across systems that name accounts differently;

• classify and group the requests by topic;

• aggregate and rank them across every matching account.

A vector store can retrieve snippets that mention feature requests. It cannot filter by renewal date, attribute each request to the right account, and aggregate across everything that matches. It returns the documents its relevance search surfaced — not the answer.

The question asks for a business fact. That has to be computed, not retrieved.

A server-side join

Every developer learns this early. To join data across tables, you don't pull all the rows into your application and stitch them together in memory. You push the join down to the database, where the data already lives, and ship back a small answer.

Most agent architectures still do it the other way.

In an MCP-direct setup, the agent calls Salesforce, then Zendesk, then Slack, then a product database. It pulls rows and snippets into the model context. Then it tries to reconcile identities, rank evidence, and infer state.

That is slow, expensive, and unreliable — for the same reasons it was in application code. Databases moved away from it decades ago.

The expense is not abstract. Every question pulls the same raw context back into the model, so a thousand users asking the same thing means rebuilding it — and paying the token bill for it — a thousand times. The context graph is the server-side join for GTM. It ingests the systems, resolves entities, applies a GTM ontology, computes state, stores evidence, and exposes clean, permissioned views.

The agent doesn't rebuild the account model from scratch. It receives an already-joined representation of the facts it needs. Fewer tokens, consistent answers, governance before context reaches the model, and every fact traceable to its evidence.

A graph, not a graph database

It is easy to read "context graph" as the name of a specific piece of infrastructure. It is not. Logically, it is a graph: accounts connected to contacts, tickets, renewals, usage. That is the mental model.

Physically, in our case, it is a cloud-native relational database, tuned over years of database performance work. The graph is the model. The relational store is what makes it fast, durable, and cheap to query at scale.

What makes it a GTM context graph

A context graph is more than its storage. It is not a vector index with metadata, and it is not a warehouse with a chat interface.

For GTM, it needs five properties.

1. A vertical GTM ontology. It has a point of view on the domain: accounts, opportunities, renewals, champions, risks, expansion and churn signals, next actions. It knows the difference between a quiet champion and a missing decision-maker. From production, this ontology is largely stable across B2B companies. The customer-specific work lives in the long tail.

2. Entity resolution. The same account, person, or issue shows up differently across CRM, support, product analytics, Slack, and transcripts. Resolution collapses those fragments into durable identities. Without it, every workflow downstream is fragile.

3. Ingestion-time compute — the most important shift. Most systems ask the model to act as a data analyst at runtime. We move that work upstream. At ingestion, we compute state — health, churn risk, sentiment, champion strength, renewal risk — as typed facts attached to entities: Account: Acme Corp Renewal risk: High Primary driver: unresolved implementation blocker Evidence: support tickets, renewal call transcript, usage decline Recommended action: alert account owner before QBR The agent queries a computed fact instead of rebuilding it every time. Staleness is handled by incremental recomputation — a fact updates when its inputs change, not on every query.

4. Evidence as a first-class object. Every fact points back to the ticket, transcript, field, or usage event behind it. A CRO doesn't just want to hear a renewal is at risk. They want to know why. An agent taking an action should ground it in evidence, not untraceable reasoning.

5. Permissioned actionability. The graph doesn't just answer questions — it does work: sending alerts, creating tasks, updating the CRM, drafting briefs. When an agent does that work for someone, it has to stay within that person's permissions. It can only see the data they can see, and only make the changes they're allowed to make — whether it is reading or writing.

Why traces are not enough

As teams hit the limits of retrieval, a popular next move is to build the graph from decision traces — a record of how each decision was made: what was approved, what was overridden, and why it was allowed. The pitch is that enough of these become searchable precedent, capturing the institutional knowledge that lives nowhere else.

There is a real insight there. Some context only exists at the moment a decision is made — how an exception was handled, why a discount was approved, which precedent a rep leaned on — and none of it sits in a source system. Capturing it is valuable.

But a record of past decisions is not a model of present truth. A trace tells you what someone did, not whether they were right, and not whether the account is healthy today. Bootstrap the foundation from traces and you inherit the errors as faithfully as the insight — and you start cold, waiting months for enough decisions to accumulate before the graph is useful.

For GTM, the foundation has to be computed state over source data: what is true about the account right now, and which evidence supports it. That exists on day one, from a prebuilt ontology, with no warmup.

Traces are a layer on top — precedent and process memory that refine the graph. They are not the graph.

Agents have to query it, not just retrieve from it

Here is where it is easy to slip back into the original problem.

If the only way an agent reaches the graph is semantic retrieval, the graph inherits RAG's limits. The model reasons over a smaller, better pile of snippets. It still can't filter, join, or aggregate across the whole dataset.

The questions GTM teams ask are analytical. "Which accounts above $75K ARR have declining engagement and an open critical bug?" is a join, a filter, and an aggregation. Not a similarity search.

So we give agents a database, not a palette of narrow tools. Each session gets a sandboxed, federated semantic schema with full SQL over it. Tables express domain concepts. Authorization lives in the schema. SQL, because models are already good at it — there are decades of documentation and training data behind it. (More in We Built a Database for Agents.)

Here's the analogy I keep coming back to. Picture a data analyst with no dashboards, re-running every query from scratch. It works, but it's not practical for someone who needs answers all day. The sensible setup is the reverse: keep dashboards that hold the common answers, and slice and dice from there for the specific question in front of you.

The context graph is the dashboard layer: the common answers are already computed, and the query interface is how agents slice and dice from there. In our own renewal-intelligence workflow, that move replaced very large federated-context loads with a handful of queries against tables that already held the answer.

Take away either half — the computed truth or the expressive query — and you are back to retrieving snippets and hoping the model reconstructs the answer.

What agents become

Once the graph exists, agents stop behaving like improvisational analysts sitting on top of raw data. They become execution surfaces over a governed model of customer state.

A renewal agent can pull the accounts at risk, read the evidence, draft an account-owner brief, and open the follow-up task. A RevOps agent can answer a population-level question — "Which product gaps are most associated with churn in enterprise accounts?" — because the graph has already turned unstructured signal into facts you can aggregate.

The agent is no longer trying to discover the business context. It is operating on top of it.

The bigger thesis

The GTM Context Graph is a bet that revenue work has a reusable world model. Every company has quirks, but the motions repeat: accounts renew, champions emerge and disappear, support friction precedes churn, usage predicts risk, and expansion intent shows up before pipeline.

If that structure is stable, it can be modeled. If it can be modeled, it can be computed. If it can be computed, agents can act on it reliably.

So this is not a memory layer, a better search box, or raw database access for copilots. It is a living, permissioned, evidence-backed model of customer truth — the difference between agents that can retrieve data and agents that can do the work.

It is also where a simple idea from 2022 — accounts have users that perform activities — turned out to matter more than we expected.