Recently, @JayaGup10 and @ashugarg wrote about context graphs—the layer that captures decision traces rather than just data. The core argument is simple but profound:
The next trillion-dollar platforms won’t be built by adding AI to existing systems of record, but by capturing the reasoning that connects data to action.
For context, see @JayaGup10’s original thread here:
https://x.com/JayaGup10/status/2003525933534179480
That idea resonated deeply with us at Vendelux, because we’re confronting this problem every day while deploying AI agents inside real B2B sales and marketing organizations.
The question we hear most often is practical:
How do you actually build a context graph?
At Vendelux, we’re doing this in a very specific environment: enterprise and high-growth B2B GTM teams to power IRL Marketing, where decisions span CRM data, events, people, outreach, and revenue—and where the “why” is almost never captured cleanly in any system.
The short answer: you don’t build a context graph by “adding memory to an agent.” The word graph itself is misleading. What you’re really modeling is a living decision system—dynamic, probabilistic, and constantly changing.
We’re still early, but the direction is clear: the context graph is infrastructure that lets deployed agents learn how a given organization actually makes decisions.
The fragmentation tax in revenue organizations
Every revenue organization pays a fragmentation tax.
Sales has one view of the customer.
Marketing has another.
Events live in spreadsheets.
Outreach lives in sequencing tools.
Strategy lives in decks and meetings.
CRMs capture outcomes—stages, pipeline, closed-won—but not the reasoning behind them. As a result, answering “what should we do next?” usually means humans manually reconstructing context across tools that were never designed to align. Even the best IRL Engineers would struggle with this current situation.
In practice, this shows up as questions like:
- Which events are actually worth attending for our pipeline?
- Which people should we meet with, and why them?
- What outreach works for this segment right now?
- Did these meetings influence revenue—or just activity metrics?
A context graph is infrastructure to stop paying that tax—by capturing the traces that connect signals → judgment → action → outcome.
What Vendelux agents can do
To make this concrete, here’s what our agents are already doing, things under way or planned.
We’ve built an AI-powered Meetings assistant that lets users plan and execute event-driven GTM campaigns through natural language.
A typical interaction might start with:
“What’s the best event for me based on my pipeline?”
Behind that single question, the system is reasoning across CRM data, historical event performance, attendee and company data, and customer-specific constraints.
From there, agents can help users:
- identify the most relevant events for open deals
- determine which people are worth meeting at those events
- create and launch meeting campaigns
- generate personalized outreach copy
- and measure downstream impact on pipeline and revenue
Under the hood, this is implemented as a deep agent system—with an orchestration layer (built using frameworks like LangChain) that routes intent to specialized agents focused on CRM insights, prospect intelligence, campaign creation, and outreach.
But the important part isn’t the framework. It’s what this architecture enables.
Each user interaction becomes a problem-directed trajectory through the customer’s GTM environment. The agents don’t just retrieve facts; they explore alternatives, apply constraints, and make tradeoffs.
Those trajectories are the raw material of the context graph.
The Two Clocks Problem (credit: @akoratana)
A useful way to understand why this is hard comes from the Two Clocks framework, articulated by @akoratana.
Original post here:
https://x.com/akoratana/status/2005303231660867619
Every organizational system runs on two clocks:
- The state clock: what’s true right now
- The event clock: what happened, in what order, and why
We’ve built trillion-dollar infrastructure for the state clock.
CRMs store deal stages.
Dashboards store metrics.
Campaign tools store configurations.
But the event clock—the reasoning that connects observations to actions—barely exists as data.
In GTM systems, this gap is everywhere:
- an account is “in negotiation,” but the rationale isn’t captured
- an event is selected, but alternatives and tradeoffs aren’t recorded
- outreach is sent, but the intent behind the message is lost
Historically, this was fine because humans were the reasoning layer. Context lived in conversations and institutional memory.
Now we want AI systems to exercise judgment—and we’ve given them only frozen snapshots of state.
Schema is an output, not an input
There is no universal ontology for GTM.
“Best event,” “high-intent contact,” or “influence” mean different things depending on the customer, the motion, and the moment.
So we don’t start by defining a schema.
Schema is the output.
Our agents act as informed walkers through a customer’s revenue environment. As they solve real problems—event selection, contact prioritization, outreach, and measurement—they discover what actually matters for that organization.
This learning doesn’t happen automatically. That’s why we embed Forward Deployed Engineers (FDEs) with customers. During the process of implementing AI with each customer, our FDEs simultaneously operate like anthropologists extracting and documenting tribal knowledge that is unique to each company. FDEs train agents to customer-specific constraints, definitions of success, and decision rules. Those tuned agents then generate trajectories that encode how that customer’s GTM system actually works.
Over time, those trajectories form the context graph—not as a static knowledge base, but as a learned model of decision dynamics.
Measurement is the proving ground
Context graphs stop being theoretical when you try to measure impact.
Customers don’t just want to know:
- how many meetings were booked
They want to know:
- which meetings influenced pipeline
- which accelerated deals
- which expanded accounts
Answering that requires linking:
events → people → outreach → meetings → CRM movement → revenue outcomes
And retaining the reasoning layer that explains why those links exist.
If a context graph can’t support counterfactuals—
What happens if we prioritize different events? Different personas? Different timing?—
it’s not understanding the system. It’s just storing history.
Trust and guardrails
None of this works without absolute trust.
We operate under strict customer agreements, security expectations, and compliance requirements—especially for F500 brands.
That means:
- customer data is protected by design
- access controls and separation are non-negotiable
- learning respects contractual and legal boundaries
The context graph has to be compatible with security and compliance from day one. Trust isn’t an add-on—it’s the substrate.
What context graphs mean for GTM
For our use case, a context graph is not “a graph database of GTM entities.”
It’s a customer-specific world model of how revenue decisions actually get made:
- what signals matter
- how people behave
- which motions work under which constraints
- how events translate into pipeline and revenue
We build it the only way it can be built: through real work.
Agents operating across CRM → events (including our own proprietary human connect graph) → prospects → outreach → measurement generate the traces.
FDEs embedded with customers shape those agents so the traces reflect real decision logic, not generic best practices.
We’re early—but the direction is clear.
The endgame isn’t AI that books meetings.
It’s GTM intelligence that compounds, because it learns how decisions actually work and uses that understanding to simulate better futures.
That’s what context graphs unlock.
Not better prompts.
Not memory.
Infrastructure for compounding judgment.
