Why Most Context Graph Companies Are Faking It

Every AI infrastructure category goes through a hype cycle. Vector databases hit it in 2023. Graph databases in 2024. Now it’s context graphs — and Daniel Davis, co-creator of TrustGraph and someone who actually built this infrastructure before the term became a marketing label, is watching the cycle with a mix of amusement and frustration.

“When Foundation Capital published their context graph article, it got five million views overnight,” Daniel explains. “Every company suddenly became a context graph company. But when you actually dig in, most of them don’t have the tech.”

The distinction matters more than it sounds. The context graph hype isn’t just marketing noise — it’s a signal that the industry recognizes a real problem (AI systems confidently hallucinate) and sees graphs as part of the solution. But between the recognition and the solution stands a chasm: most companies claiming to be context graph vendors are simply rebranding existing databases, not solving the actual problem.

The difference between naming and building

Context graphs are an answer to a specific architectural problem: how do you structure data so that an AI agent can not just retrieve information, but evaluate whether that information is trustworthy?

This is different from what most databases do. “Neo4j is optimized for graph pattern matching,” Daniel notes. “Vector databases optimize for semantic similarity. But neither of them was designed with the assumption that context metadata — who said it, when, how confident — matters more than the raw fact.”

The real infrastructure layer for context graphs needs to handle something most databases treat as secondary: provenance. Not just storing facts, but storing facts alongside their metadata — source, timestamp, confidence level, who made the claim, under what conditions. A vector database can find similar information. A graph database can find connected relationships. But a context graph needs to do both while maintaining the full chain of custody for every piece of data.

Daniel’s take is blunt: “There’s maybe 10% of people in the room who’ve actually worked with graph systems.” The hype created an opportunity for databases to claim they’re context graphs without fundamentally changing how they work. A Neo4j instance with a different data model is still optimized for traversal, not provenance. A PostgreSQL jsonb column with a graph-like structure is still a document database.

The test: can it answer “who said this?”

The clearest tell that a company is faking context graph infrastructure comes down to one question: can the system track statements about statements?

In graph terminology, this is called reification — the ability to make claims about other claims. Instead of storing “Barcelona is in Spain,” you store “Daniel cited Wikipedia on March 6, 2026, stating Barcelona is in Spain.” The metadata becomes queryable and evaluable.

“Most databases don’t support reification because it requires a fundamentally different schema design,” Daniel explains. “It’s not a bolt-on. It’s architectural.”

When a company claims to be building context graphs but their database fundamentally works like a key-value store or a document database with a graph visualization layer, they’re not building context infrastructure — they’re building a wrapper. The wrapper might be useful, but it’s not addressing the core architectural problem that context graphs are supposed to solve.

This is why Daniel is unimpressed by most of the Foundation Capital list. Companies like Merge claim context graph credentials but, according to Daniel, haven’t solved the reification problem. They’re using the term, not the architecture.

Why the hype cycle is dangerous

The problem with context graph hype isn’t just that companies are misleading buyers — it’s that the misdirection leaves the actual infrastructure gap unfilled.

“Enterprise AI deployment has zero infrastructure for this,” Daniel says. “Every company deploying an AI agent faces the same problem: the agent will hallucinate, and the only way to reduce hallucinations is to give it access to high-quality, provenance-tracked context.”

But if companies spend money on solutions that sound like they solve the problem (a “context graph company” with a rebranded database) without actually getting the architectural layer they need, the core problem stays unsolved. The AI still halluccinates. The enterprise still has no way to evaluate whether the agent is working with trustworthy data.

“2025 was the year AI POCs failed,” Daniel notes. Proof of concepts that looked good in the lab didn’t scale in production. Part of the reason: the context infrastructure most companies bought wasn’t actually designed for what they were trying to do.

What separates real from fake

The test for real context graph infrastructure is simple: does it fundamentally change how you model information?

TrustGraph’s architecture separates the storage layer (Apache Cassandra for distributed writes and fault tolerance) from the query layer (Qdrant for semantic similarity). But more importantly, the schema design is built around the assumption that metadata matters as much as the raw data.

When you query a context graph, you’re not just asking “what is similar to this?” or “what connects to this?” You’re asking “what information is both similar to this and comes from a trustworthy source with a recent timestamp?” The architecture has to support all three dimensions simultaneously.

Real context graph infrastructure also typically has a strong opinion about open source. “Closed proprietary systems for AI context can be opaque about how they evaluate reliability,” Daniel points out. Open infrastructure lets developers, enterprises, and eventually regulators audit exactly how provenance and confidence are tracked.

The next wave

The context graph hype cycle is still in its early stages. Most companies claiming the label don’t have the infrastructure. But the hype itself is pointing at a real gap — one that will eventually be filled by companies that actually solve it architecturally, not cosmetically.

Daniel’s bet is that open-source infrastructure wins this category. “When you’re building the foundation layer for how AI systems reason about trustworthiness, transparency matters.” A proprietary black box for context evaluation doesn’t scale when the stakes are high — enterprise AI, regulated industries, critical decisions.

The companies that end up owning the context graph category will be the ones that understood early that reification, provenance, and temporal reasoning aren’t nice-to-haves — they’re the foundation. Everyone else is just moving data around and calling it a graph.

FAQ

What exactly is a context graph?

A context graph is a structured knowledge system that stores not just facts but their metadata — source, timestamp, confidence level, and who made the claim. Unlike vector databases (which optimize for similarity) or property graphs (which optimize for traversal), context graphs assume you need to track provenance and reliability to make decisions about whether to trust information.

Why do most companies claiming to be “context graph” companies not actually have the tech?

Because building true context infrastructure requires rethinking schema design around reification (statements about statements) and provenance tracking. Many vendors relabel existing databases — Neo4j, PostgreSQL, or document stores — and market them as context graphs without fundamentally changing how they work. A rebranded database is still optimized for its original use case, not for context evaluation.

What’s the difference between a property graph and a true context graph?

Property graphs like Neo4j store nodes with attributes and edges. They’re fast for traversal queries. Context graphs use RDF-like models with reification, letting you store “who said X, when, with what evidence.” Property graphs excel at finding relationships. Context graphs excel at evaluating trustworthiness of information and its sources.

How can I tell if a context graph solution is real?

Ask: can it track statements about statements? Can it answer “who said this, and when, and under what conditions?” Can it query based on source credibility and timestamp? If the product is fundamentally a traditional database with a new visualization or terminology, it’s probably not a real context graph.

Why is open source important for context graph infrastructure?

Closed proprietary systems for AI context can hide how they evaluate reliability and confidence. Open-source infrastructure lets enterprises, developers, and regulators audit how provenance is tracked. It also prevents vendor lock-in and creates a standard layer the AI ecosystem can build on collectively.

Is every hallucination problem a context graph problem?

Not every hallucination comes from bad context. But most enterprise hallucinations do — the AI is either working with stale data, mixing reliable sources with unreliable ones, or has no way to evaluate confidence. A real context graph layer helps an agent understand which sources are trustworthy and when data becomes outdated.

Why does Daniel say “most graph databases are just rows and columns anyway”?

Because at the storage layer, every database — graph, relational, document — is ultimately storing rows or columns of data. The architectural difference comes from what queries the schema is optimized for. A true context graph is optimized for provenance queries, not just relationship queries or document retrieval.

What’s the connection between context graphs and the “2025 POCs failed” insight?

Most AI POCs fail because they look good with curated test data but fall apart in production when they encounter noisy, mixed-quality, or outdated information. The teams building those POCs didn’t have infrastructure to make the agent aware of information quality. A context graph layer would have made many of those failures visible in the lab.

Can you add context graphs on top of an existing vector database?

Technically yes, but it’s limited. You can wrap a vector database with a context layer on top. But you lose the benefits of having provenance as a first-class architectural concern. A true context graph is built from the bottom up with metadata tracking in mind, not as a wrapper around a database designed for something else.