What is a context graph? A definition for go-to-market teams
Updated
The short answer. A context graph is one store of every person, company, deal and conversation your team has, linked to each other, with a source, the time it was true and a list of who may read it on every fact, so people and agents can ask what happened and why. For a go-to-market team it is the customer half of the company brain, and Day AI provides the context graph and agent control plane to quickly and securely upgrade your company brain.
This page explains what a context graph is made of, why it's new, why agents need one, and why we think RevOps should own it. Day AI, what comes after the CRM, is built on it. To build one yourself, read how to build a context graph.
What a context graph is
Like any graph, a context graph is nodes connected by edges. The nodes are the things your team deals with: people, companies and deals, and the conversations and events between them, like an email thread, a call or a meeting. The edges say how they relate: Priya works at Northwind, Priya was on the March 3 call, the March 3 call is about the Northwind renewal.
A knowledge graph stores facts as they are now: Priya works at Northwind. A context graph keeps four more things on every fact:
- When. When it became true, and when it stopped. "Who was our economic buyer at Northwind in March?" still has an answer after Priya leaves.
- Where it came from. The email, call or record behind it, so a person or an agent can check it and know how far to trust it. A buyer's own words on a call count for more than a guess typed into a field.
- Who may read it. Each fact carries who is allowed to see it, so one graph can serve a whole team and their agents.
- Why. The decisions and the reasons for them: why a discount was approved, why a deal was lost, who signed off on the exception. Foundation Capital calls these decision traces.
Put together, a context graph can answer a question like: who was our economic buyer at Northwind when we sent the renewal quote, which call says so, and can the rep asking see that call?
The three kinds of memory an agent needs
One useful way to split an agent's memory is into three layers. In go-to-market terms:
- Long-term memory: what stays true for a while. Who works where, what each customer bought, their contract terms, and the definitions your team works to, like stages and how ARR is counted.
- Short-term memory: the task in front of the agent. The current chat, the meeting it's preparing for, the email it's drafting.
- Reasoning memory: past decisions and why they were made. The exception the CFO approved, the reason last quarter's deal was lost, the objection that came up on the last three calls.
Short-term memory lives in the agent's session and is gone when the task ends. A context graph is where the other two live, with the customer facts and decisions attached to the people, companies and deals they're about, so each new task starts from what the team already knows.
Why it's new
For most of the CRM era, conversations couldn't be used as data. Nobody could read every email and transcript, so teams kept a person's summary of them in fields and let the rest go. Language models can read all of it, which makes it worth keeping conversations whole and deriving structure from them when you need it.
Agents changed who needs the context. A rep who forgets why a deal stalled can ask the colleague who was on the call. An agent can't. It knows only what it can look up, and the why behind most decisions was never written anywhere it could look. Foundation Capital named the term in December 2025 for that gap.
Why agents need one
- A context window isn't a memory. Everything your team knows won't fit in a prompt, and a crowded prompt makes answers worse. An agent needs to fetch the right slice: this account, these people, since this date.
- Time and sources let an agent show its work. Without them it can't tell a current fact from a stale one, or point to the call it got an answer from.
- Permissions have to live with the data. An agent working for a rep should see only what that rep may see. That can't be a filter someone remembers to add later.
- Reasoning memory stops repeat mistakes. Without past decisions, an agent asks again for an exception already approved, or pitches the feature a customer already said they don't need.
Our view of the term
People use "context graph" in a few ways. Foundation Capital means accumulated decision traces: "a living record of decision traces stitched across entities and time so precedent becomes searchable." Engineers building agent memory mean a graph of entities and relationships an agent walks to assemble context. Atlan describes "a structured representation of data assets, the relationships between them, and the history of decisions made about those assets over time."
A CRM stores the fields people type into a schema defined in advance, and RAG finds passages of text that look like the question. A context graph keeps what actually happened and knows who and what each piece is about; the comparison of context graphs, RAG and CRMs walks through one question answered all three ways.
Why go-to-market teams need one
Most of what decides a deal is said, not typed: the pricing pushback, the new stakeholder copied on a thread, the competitor mentioned in passing. You can derive fields from transcripts, but you can't derive transcripts from fields; why CRM data is low resolution makes the longer case. And go-to-market questions change every quarter, so capture everything first and structure it later.
Here is what that looks like. A rep inherits an account from someone who left. The record says Proposal, next step "send pricing". The graph shows the buyer asked on a call three weeks ago whether the contract could start after their fiscal year ends in February, and that the pricing email never went out. The rep sends terms that start in February the same day.
Point the graph at a number you already report: pipeline created, win rate, ramp time, or what reps earn. The rep in that example moves ramp time and win rate. If a context graph project can't name the number it moves, it isn't ready to start.
Why RevOps should own it
The company brain that matters most is the one RevOps owns, because how a business makes money is the most important thing it knows. RevOps already owns the definitions agents have to follow: what each stage means, which lead source gets credit, how ARR is counted. An agent that gets those wrong produces confident, wrong work.
The hard part of a context graph isn't the first user. It's the second one, and every person after:
- whose email each person and each agent may see
- getting skills to reps who will never open a terminal
- keeping skills current as stages, pricing and territories change
- knowing whether the output is any good
That's RevOps work. Foundation Capital made the same point on their podcast with Aaron Levie, naming RevOps among the "glue functions": "Today their function is carrying context that software doesn't capture." A context graph is where that context gets captured.
If you've started bringing engineering tools and practices into go-to-market, a folder of skills, a Claude Code session that knows your pipeline, you were right to. Split the rest by category. Buy what is infrastructure: the context graph and the agent control plane, where permissions, syncs and identity live. Build what is yours: your skills, your agents' job descriptions, your workflows and your definitions. The build vs. buy guide covers the cost side, and the Vector 2026 talk Three questions RevOps leaders should ask about their company brain covers what to ask your team.
How Day AI provides it
Day AI provides the context graph and agent control plane to quickly and securely upgrade your company brain. Teams run it as their CRM, an AI-native one, with pipeline, contacts and companies kept current from their team's conversations, or on top of Salesforce or HubSpot.
Day AI is a context graph for go-to-market teams: every meeting, email, call and Slack message, linked to the people, companies and deals they're about, with each person's sharing rules deciding who sees their email, and governed agents that work on it.
- What goes in. Email and calendar come from Google Workspace. A native notetaker writes each meeting into the graph after it ends, Gong connects with full call history and transcripts, and Granola connects with transcripts and notes. Slack messages come in from the channels you add the Day AI app to. Support tickets, product usage and other data arrive through Zapier and the API. Anyone your team emails or meets becomes a contact, and their company comes with them.
- Who sees what. Each person sets sharing rules: share everything or nothing by default, with exceptions by domain, address or Gmail label. What someone keeps private stays private from teammates and agents. An agent inherits the permissions of the person it works for, so it never sees more than that person does.
- Where every fact came from. Answers cite the call or the message they came from. Every value shows the sources it came from, and its history shows who changed it and when.
- Structure later. Add a custom property, describe it in plain words, and have it filled from your team's past conversations.
- Agents with a job. Agents have a name, a job and skills, and work for a person. Skills run on a schedule, when something happens, like a meeting or an email coming in, or on request.
- Your tools and your CRM. Day AI supports connecting MCP servers. Connect the Salesforce or HubSpot MCP and allow its write tools, and you get two-way sync: agents read from your CRM and write back to it, for example updating deal stages, notes and fields after every call. The graph itself is exposed over MCP with OAuth at
https://day.ai/api/mcp, and day.ai/mcp walks through setup for Claude, Claude Code and Cursor. The Day AI SDK is an MIT-licensed TypeScript client for the same tools.
To see where your current build stands, run the company brain evaluation in your folder with npx skills add day-ai/company-brain-evaluation. For the longer argument about what replaces the CRM's place at the center of the revenue team, see Life After CRM.