# What is a context graph? A definition for go-to-market teams > What a context graph is made of, why it's new, why AI agents and go-to-market teams need one, and why RevOps should own it, in Day AI's words. Updated October 28, 2026 Video: https://www.youtube.com/watch?v=0phAfVzaAw4. Christopher O'Donnell at Vector 2026 on what a company brain is made of and the three questions RevOps leaders should ask about theirs, starting at 4:49. **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](/guides/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](https://foundationcapital.com/ideas/context-graphs-ais-trillion-dollar-opportunity) 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](https://atlan.com/know/what-is-a-context-graph/) "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](/guides/context-graph-vs-rag-vs-crm) 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](/guides/crm-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](https://foundationcapital.com/ideas/the-case-for-context-graphs), 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](/guides/build-vs-buy-customer-context) covers the cost side, and the Vector 2026 talk [Three questions RevOps leaders should ask about their company brain](/videos/revops-company-brain-questions) 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](https://day.ai/mcp) walks through setup for Claude, Claude Code and Cursor. The [Day AI SDK](https://github.com/day-ai/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](https://lifeaftercrm.com). ## Frequently asked questions ### What is a context graph? A context graph is one store of every person, company, deal and conversation a 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 AI agents can ask what happened and why. For a go-to-market team it is the customer half of the company brain. Day AI provides the context graph and agent control plane to quickly and securely upgrade your company brain. ### Is a context graph the same as a knowledge graph? Close, but not the same. Both are nodes and edges: people, companies, deals and conversations, and the relationships between them. A knowledge graph stores facts as they are now. A context graph also keeps when each fact was true, the email or call it came from, who may read it, and the decisions and reasons behind it, which is what agents need to do work. The guide to context graphs vs. RAG vs. CRM covers the differences in more detail. ### What is customer memory for AI agents? Customer memory is what an AI agent knows about your customers when it starts a task: who they are, what was said in every email and call, what was promised, and what changed since. For a go-to-market team, a context graph is where that memory lives, shared across the team, with a source on every fact and each person's sharing rules deciding what each agent may read. This is why Day AI describes itself as the customer memory and agent platform for go-to-market teams. ### Why do AI agents need a context graph? Because an agent knows only what it can look up. Everything a team knows won't fit in a prompt, so an agent needs to fetch the right slice for the task, with the time and source of each fact so it can tell current from stale and show its work, and with permissions attached so it sees only what its person may see. A context graph also holds reasoning memory, the decisions and the reasons behind them, which an agent otherwise can't recover. Day AI provides that graph, with agents that work on it within each person's permissions. ### Why do sales teams need a context graph? Because the reasons deals move live in emails and calls, not in fields. Agents now do much of a sales team's reading and acting, and they need those primary sources, with who said what and who may see it. A context graph keeps the conversations whole and attached to the right people, companies and deals, so a rep or an agent can answer the question behind a deal and not just read its stage. In Day AI, every meeting, email and call lands in that graph, and governed agents work from it. ### Who should own the context graph? RevOps. RevOps already owns the definitions agents have to follow, like stages, lead sources and ARR, and the hard part of a context graph is the same work RevOps does today: deciding who may see what, rolling tools out to people who never open a terminal, and keeping process current as the business changes. Engineering can help build it, but the definitions and the rules belong to the team that owns how the company makes money. Day AI is built for that owner, with each person's sharing rules and agents that each work for a person. ### Do I still need a CRM if I have a context graph? Usually yes, at first. The CRM stays useful for values everyone has to agree on, like stage, amount, owner and close date, and a context graph reads from it or writes back to it. Over time, some teams find one system that does both is simpler. Day AI can run as your CRM, or on top of Salesforce or HubSpot with two-way sync through their MCP servers once you allow their write tools. ### Can Day AI be our context graph if we already use Salesforce or HubSpot? Yes. Day AI builds the graph from your team's email, meetings, calls and Slack, and connects to Salesforce or HubSpot through their MCP servers. Allow their 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. ### How do I build a context graph? Start with the 10 to 20 questions it has to answer, then ingest email, meetings, calendar, Slack and your CRM, resolve every person and company to one ID, keep a source on every fact, keep it current with event-driven syncs, and give agents access over MCP. The step-by-step guide to building a context graph covers each part and where homemade builds break. Teams that would rather not build the parts a second user needs, like per-person email permissions, use Day AI for the graph and build their skills on top. ### What is Day AI? Day AI is the customer memory and agent platform for go-to-market teams. Even the best CRM only holds a fraction of what actually happened with your customers. Day AI is what comes after CRM. It builds a self-updating customer record from every meeting, email, and call, and runs governed agents that create finished work on top of it, with every fact and every action traced to source conversations. It does everything teams use a CRM for, without the data entry, and does what a CRM never could. Agents prospect, prep every meeting, draft follow-ups, keep the pipeline clean, and much more, giving every rep added selling capacity that used to require hiring additional people. It runs as a layer on top of Salesforce or HubSpot or in place of them. Canonical: https://day.ai/guides/what-is-a-context-graph