Context Is Not a Graph
There is only the weave.
This newsletter is built on one premise: the next decade of AI infrastructure won't be won by bigger models. It will be won by better context. Whoever owns the context wins.
I hope to defend and complicate that thesis from many angles over the coming weeks — this is the first piece in that series. And the question I want to start with is the one most of the current discourse is skipping past: if context is the thing, what format does it live in?
The fashionable answer right now — most loudly from Foundation Capital, who recently invested multiple companies in this space — is the context graph. Pull every entity, every relationship, every piece of metadata your company touches into a beautiful knowledge graph. Hand it to the LLM as a structured object. Magic happens.
I want to argue, gently but firmly, that this is the wrong picture.
Not because graphs are useless. They’re great. But “context graph” as the marketing term, the company-defining bet, the venture thesis — it’s a category error. Context isn’t a graph. Context is hybrid intelligence. The graph is one ingredient, and not even the hardest one.
Let me explain why this matters, what I think the actually-hard work looks like, and which companies I think are quietly winning while the graph crowd cheers.
The graph illusion
Foundation Capital’s pitch — and they’re not alone, several brand-name funds have variants of this — runs roughly: enterprise data is messy and siloed. Pull it into a knowledge graph. Now the LLM has clean, structured context.
The problem is that a graph database, by construction, prefers deterministic relationships. “Acme Corp is a customer.” “Invoice 4471 belongs to Acme.” “Sarah is the AP contact at Acme.” Beautiful nodes and edges. Queryable in milliseconds.
But the context that actually matters when an AR (account receivables) executive decides whether to chase a 30-day-late invoice from Acme isn’t in the graph. It’s in:
The Slack thread where the CSM mentioned “Acme is going through a leadership change, give them a quarter.”
The email from Sarah six weeks ago that said “We’re switching ERPs, expect delays.”
The Gong call where their CFO half-admitted they’re raising bridge financing.
The dunning history showing Acme always pays at day 47, not day 30, and always in full.
The fact that Maria, the rep, knows Sarah personally and would never call her cold.
None of that fits cleanly in a graph. Some of it is deterministic (the dunning history, the invoice amount). Some of it is conversational and anecdotal (the Slack thread, the Gong snippet). Some of it is implicit social knowledge (Maria’s relationship with Sarah). Some of it is source of truth (the ERP balance). Some of it is probabilistic — the CFO’s hint about bridge financing might be true, half-true, or theatre.
Context, in any operationally useful sense, is the union of all of this. It is hybrid. The graph is one slice. Treating the graph as the substrate is like trying to capture a city by mapping only its streets — you get the topology and lose everything that makes the city worth living in.
This is why the Foundation Capital thesis gives me pause. They’ve made two investments in this space. Both are excellent graph-shaped companies. Neither, by itself, solves the user’s problem. The bet only pays if the portfolio gets stitched together into something much bigger than a graph — and that stitching is the work, not the graph.
What a16z got right
The frame I keep returning to is the a16z piece on the move from system of record to system of intelligence. It is the most useful single essay I’ve read on this transition.
The argument, briefly: for thirty years, enterprise software has been about recording things. CRMs record customer interactions. ERPs record transactions. HRIS systems record employees. The whole industry has been one giant database with a UI on top. The job of the human was to take the recorded data and do something with it — judgment, action, follow-up.
The shift now underway is from systems that record to systems that act on the record. The AI doesn’t just store the customer interaction; it follows up. It doesn’t just file the invoice; it dunns the deadbeat. It doesn’t just log the support ticket; it resolves it. Record becomes intelligence.
What a16z got exactly right is that this transition is not primarily a model problem. The frontier models can already do most of these tasks. What’s missing is the context layer that makes the model’s actions legitimate and competent in a specific business.
What a16z understates, in my reading, is how brutally hard that context layer is to build. And this is exactly where the “context graph” thesis quietly collapses.
Why GTM is the real moat
If “context graph” were the answer, company-building would be relatively clean: build a great graph product, sell it into enterprise, win. The graph database industry already tried this exact play in the 2010s. Neo4j is a real company. But it’s not a $100B company, and the reason isn’t technical — it’s that clean graphs don’t actually solve the user’s problem.
The user’s problem is a workflow problem. The AR executive doesn’t wake up wanting to query a knowledge graph. She wakes up wanting to know: which five invoices do I chase today, in what order, with what message, through which channel? She wants the answer, in the flow of her day, with the right tone for each customer.
To deliver that, the system needs: