We built a context graph, then made ourselves justify it

When "context graph" started showing up in our product discussions, one of our engineers pushed back in a design thread with a line I've kept: graphs sound sexy, ask why graphs, or you'll adopt the marketing and skip the merits. The argument that followed was one of the more useful things we've done, and it's worth publishing for a reason we didn't expect when we wrote it down.

We had that argument when context graphs were the phrase everyone was sprinting toward. By the time this published, the sprint had moved on: MCP for a while, then memory, then agentic everything, and by the time you read this, something else. That turnover is the actual lesson. The phrase in the design thread turned out to be incidental; what mattered was being forced to name which properties we would use this quarter, and that question survives every rename. Run it against whatever is on the slide this month.

So: not our schema, the reasoning.

What we actually have

Strip the vocabulary and our data model is an ontology - a deliberately small one - of the concepts our domain runs on: stakeholders, opportunities, accounts, signals, and the relations between them. A stakeholder influences an opportunity. A signal concerns an account. When our resolution pipeline (the 16x problem) attaches an email to a deal and a person, it's asserting edges in exactly this structure.

Is that "a graph"? Honestly, it's graph-shaped knowledge that could be encoded several ways, and for plenty of operations a well-indexed relational store serves it fine. Calling it a context graph doesn't make it smarter. What matters is which properties of graph-thinking we actually cash in.

The two we cash in

Connectedness as context. The oldest, least glamorous graph property: knowing what's connected to what, and how far apart things are. When an analysis asks "who matters for this deal," the honest answer traverses relations - who's talked to whom, about what, connected to which opportunity. That is context in the pre-LLM sense of the word, and it's why the graph framing fits retrieval for language models so naturally: the neighborhood of a node is a principled answer to "what should the model see?"

Time as a first-class citizen. The argument's best distinction was between what we came to call the state clock - what's true now, given everything seen - and the event clock - how it came to be true. Most CRM-adjacent data only has the state clock: current title, current stage, current sentiment. The event clock is where deal intelligence actually lives. The concrete example that sold it: a prospect asked a hard question in a meeting - was it ever answered, by anyone, in any later channel? That's an ordering query across events, and no amount of "current state" can answer it.

Where the line sits

What the argument produced in the end wasn't an architecture, it was a test every piece of new machinery has to pass: name what this buys us this quarter, and "elegance" is not an answer. That sounds obvious written down, and it is exactly the question that enthusiasm skips. Our whole platform posture is that boring wins until it measurably loses, so anything we adopt here arrives with a profile behind it rather than a keynote. The vocabulary is worth adopting early, because it changes how the team reasons. The infrastructure underneath it should be adopted late, when something you can measure says it's time.

Real numbers

1. A handful of core concepts in the ontology - deliberately few; every added concept must earn its edges.
2. Two clocks: state (what's true) and event (how it became true) - the distinction doing the most analytical work per word.
3. One test for new machinery: what does it buy us this quarter? "Elegance" fails it.
4. One design thread that saved us a quarter of resume-driven architecture.

Where the humans sit

The ontology is governed like an API: adding a concept or a relation is a design review, not a migration someone runs quietly. That's the real discipline of the graph framing - not the storage engine, but the agreement that the vocabulary of the system is small, shared, and changed on purpose. Models consume the structure; people own its meaning.

Steal this

Before adopting a context graph, or MCP, or memory, or whatever the industry is in love with by the time you read this, write the memo that has to survive your most skeptical engineer: which two or three properties of the thing will you actually use this quarter, and what does each cost on the stack you already run? If the memo survives, you'll build with conviction. Ours survived on connectedness and the event clock, and died on everything else, which is exactly the resolution you want: the vocabulary without the vanity infrastructure. The memo is cheap and it re-runs, which is the only reason it still works three buzzwords later.

Next week the build track shows how a retro complaint becomes shipped code. Then back here for what the structure is for: 44 sellable use cases nobody had to write.

---

This post is part of the product track of How a Tiny Team Ships Like a Big One, a series on how six builders run a production AI company. Building at Aithon - if this is how you want to work, talk to us.