8 min
Manveer Chawla
Updated on :
AI agents that can't carry structured state across sessions degrade on repeated work. They lose what worked, what failed, which sources were dead ends, and how users corrected them.
Perplexity's Brain is one response: a context graph that reported +25% answer correctness and +16% recall on previously-seen tasks (internal metrics). Other teams have arrived at the same problem with radically different architectures.
This is not a knowledge-graph revival. The schemas diverge too sharply, and the workload is too different. If you're building AI products, the question isn't whether to invest in structured context. It's whether to adopt an off-the-shelf context model or build on infrastructure that lets you define your own.
Key Takeaways
Multiple teams are building context layers for AI agents, but their schemas diverge sharply. Same need, radically different architectures.
Context graphs are a distinct database workload: append-heavy, bitemporal, provenance-rich, permission-aware, and latency-sensitive on the inference path.
Good context graph infrastructure is opinionated about how context is stored, traversed, versioned, and retrieved, and silent about what your graph means.
Object-storage economics make it possible to retain every relationship, version, invalidated fact, and evidence chain instead of pruning what agents need most.
If your context model is where your domain intelligence compounds, don't outsource it. Build on infrastructure that provides the primitives, not the schema. Why every context graph schema looks different
Perplexity Brain organizes around sessions, tasks, files, corrections, and outcomes. Its graph makes one agent (Computer) better at repeated work by tracking what worked, what failed, which sources were dead ends, and how corrections propagate. The ontology is episodic and execution-adjacent.
Capital One's engineering team published an architecture for agent memory using a context graph: entities as nodes, claims as directed edges with confidence scores and lifecycle states. Every claim links back to the conversation that produced it, and contradicting evidence deprecates older claims with a timestamp. The ontology is evidence-centric.
Glean maps content, people, activity, and permissions. It's optimized for enterprise findability: who authored what, who viewed it, who shared it, and who's allowed to see it. The ontology is retrieval-centric.
Dust describes its context layer in terms of semantic search, data sources, tools, and agent orchestration, not graph-native traversal. The ontology is agent-operational: instructions, tools, skills, workspaces, governance.
| Product | Core schema elements | Ontology type |
|---|---|---|
| Perplexity Brain | Sessions, tasks, files, corrections, outcomes | Episodic |
| Capital One | Entities, claims, confidence scores, lifecycle states | Evidence-centric |
| Glean | Content, people, activity, permissions | Retrieval-centric |
| Dust | Semantic search, data sources, tools, agent orchestration | Agent-operational |
Same need, radically different schemas, and these are just four examples.
The ontology trap: why building on someone else's schema breaks
Schema divergence is healthy at the application layer. It becomes dangerous when you mistake one application's schema for infrastructure.
When you reach for an existing "company brain" or memory layer as infrastructure, you don't just adopt a storage engine. You adopt a worldview.
That worldview decides what counts as a node, which relationships are first-class, what time means, how evidence attaches to facts, how permissions propagate, and what gets preserved versus summarized away.
In a demo, this feels like acceleration. In production, it becomes a ceiling.
Salesforce's object model (Account, Contact, Lead, Opportunity) standardizes sales motion, but it also shapes how organizations think about customers and pipeline. Jira's issue types and workflow schemes define what "work" means so completely that teams building unique CD pipelines end up fighting the state machine.
Once a vendor schema becomes specific enough to be useful, a 1:1 export to a neutral format becomes practically impossible.
A security-incident graph forced into a people/document/activity model leaks or distorts. A robotics state machine forced into a decisions/commitments model doesn't fit. A clinical-trial audit trail forced into an agent-episodic schema loses its regulatory structure. A support team's SLA-and-escalation lineage doesn't map onto any of them.
These applications should have opinions, and they do. Perplexity should have a Perplexity-shaped ontology. Glean should have a Glean-shaped one.
Strong product opinions make great applications and terrible substrates. If your ontology is where your domain intelligence compounds (and it is), your ontology is part of your product. You don't outsource it.
Context graphs are a distinct database workload
Context graphs aren't knowledge graphs with more hype. They're a new serving workload.
A context graph is append-heavy: every session, correction, tool call, and permission change adds or invalidates nodes and edges.
It needs temporal state. Production systems increasingly need full bitemporal semantics, tracking both when a fact was true in the world and when the system recorded it. Without temporal invalidation, agents inherit contradictory or stale facts, which drives hallucination and reasoning failures.
It's provenance-rich: facts and relationships should carry evidence of why they exist, linked to their source session, document, conversation, or author.
It's permission-aware: access control evaluated during traversal, not post-filtered. Glean's architecture emphasizes permissions as part of indexing and search. For context graphs, that principle argues for access control during retrieval and traversal, not only after.
Relationship traversal can leak context (a public ticket referring to a private postmortem), so forbidden nodes should never be expanded.
And it's latency-sensitive enough to sit in the inference path. An agent's tool-call loop needs working context in the low hundreds of milliseconds. Sub-200ms p95 is a common target for production agent memory systems.
No existing database category cleanly and economically combines all of this. OLTP graph databases handle transactions over relatively stable graphs but weren't designed for append-heavy temporal workloads with per-edge provenance.
Vector databases handle similarity and can store metadata, but their core abstraction doesn't encode directional relationships, temporal validity, provenance chains, or permission-aware traversal.
A vector index tells you what is semantically similar. A context graph tells you what is structurally connected, when it was true, why it matters, and whether you're permitted to know it.
What good context graph infrastructure looks like
The most durable infrastructure products share a pattern: fierce technical opinions, weak domain opinions.
S3 has hard convictions about durability (eleven nines), object semantics, consistency, and request models. It has zero opinions about whether your bytes are product photos, fraud features, genomic sequences, or agent traces.
Postgres makes strong bets on ACID, MVCC, extensibility, and query planning. It doesn't decide your tables. Kafka owns append-only ordered logs and consumer offsets. It doesn't care what's in the messages.
Separating compute from storage layers is a proven architectural pattern used by modern relational databases like AWS Aurora, GCP AlloyDB, and Neon DB. Building on this concept, turbopuffer rethought vector search around object-storage economics, using only object storage for state with NVMe and memory as a cache layer. The cost curve collapsed so dramatically that Cursor reportedly cut costs 95% after migration while improving code-retrieval accuracy by up to 23.5%.
Context-graph infrastructure should work the same way. An engine should hold hard opinions about storage layout, adjacency organization, hot/cold separation, temporal edge compaction, traversal planning, multi-hop read batching, provenance indexing, permission-aware traversal, and hybrid symbolic-plus-semantic retrieval.
It should hold no opinion about whether a node is a session, customer, repo, meeting, device, care plan, ticket, claim, policy, or tool call.
It is the only graph database that natively separates compute from storage, delivering an engine purpose-built for the context-graph workload. Object-storage-native durability, NVMe/RAM-cached hot neighborhoods, append-only writes, bitemporal state, provenance on every edge, permission-aware traversal. The mechanics of a context graph, without renting someone else's ontology.
Why graph database pricing forces you to forget
Managed graph databases typically price per gigabyte of provisioned RAM, not stored data. Leading offerings run $65-146/GB/month at that level. Object storage runs ~$0.023/GB/month. These are not equivalent comparisons: managed graph offerings bundle compute, availability, support, and operations. But the structural implication is real.
When your working graph must live in provisioned RAM at those rates, you prune and curate, losing the very provenance and temporal state that agents need.
When durable graph state lives on object storage, you can afford to remember: every relationship, every version, every invalidated fact, every evidence chain stays intact.
This is the same dynamic turbopuffer exploited for vector search: cheaper storage unlocks more usage. Cursor reportedly cut costs 95% and scaled its vector footprint once the economics made retention viable.
The context-graph workload has the same shape: append-heavy, continuously growing, economically wants to retain everything.
The hard engineering challenge is making this work for graph traversal, a nastier access pattern than vector search. A naive graph engine on object storage issues one remote fetch per hop. At ~100-200ms per round-trip, a 3-hop traversal becomes seconds of latency.
The credible answer involves co-locating adjacency with nodes, batching the traversal frontier, keeping hot neighborhoods in NVMe/RAM, bounding fanout, and separating cold durable truth from hot serving state.
Recent systems research database implementations, such as Dgraph (a highly popular graph database utilizing LSM and predicate partitioning) and LSMGraph, combine LSM-tree write friendliness with CSR-like read locality for exactly this class of problem. It requires an engine purpose-built for the workload.
Own your context graph schema
The next thousand company brains will be built for support intelligence, sales coordination, code reasoning, security response, clinical workflows, compliance lineage, agent memory, and domains nobody has built yet. Each with its own nodes, edges, temporal semantics, and permission model.
The market for application-layer brains is real and growing. Every company building AI products will need one. The mistake is assuming every company needs the same one, or that you should inherit your context model from a vendor whose domain assumptions will diverge from yours within the first quarter of production use.
The durable infrastructure position, the one HydraDB is built around, is the one that lets all of these exist. Opinionated about the mechanics, silent about the meaning. Cheap enough that you don't have to choose what to forget. Fast enough that context graphs can sit in the inference path. Structurally incapable of locking anyone into a schema that isn't theirs.
Your ontology is your product. Don't outsource it. Use infrastructure that has hard opinions about how context is stored, traversed, versioned, secured, and retrieved, and no opinion at all about what your graph means.
Explore the architecture, or book a call to walk through your workload. Frequently asked questions
What is a context graph?
A context graph is a structured representation of an AI agent's working state: sessions, corrections, tool calls, decisions, sources, and the relationships between them.
Unlike flat memory stores or embedding indexes, a context graph preserves provenance (where a fact came from), temporal validity (when it was true), structured relationships between entities, and permission-aware access control. It sits in the inference path and gives agents structured context for every run.
How is a context graph different from a knowledge graph?
A knowledge graph maps what is known: entities, attributes, taxonomies, and stable relationships. It's curated and relatively static. A context graph maps what is in motion: what happened, what changed, what worked, what failed.
Think of them as a super-set or a dynamic upgrade to traditional knowledge graphs. Context graphs are session-centric, append-heavy, continuously mutating, and updated after every agent run. While they build on foundational graph capabilities, their workload profile is fundamentally different from traditional, static knowledge graph workloads.
Why do AI agents need context graphs?
Agents without persistent structured state degrade on repeated work. They can't carry forward what worked, what failed, which sources were dead ends, or how users corrected them.
Embeddings tell you what's semantically nearby, but they don't tell you what depends on what, what superseded what, what broke last time, or what's permitted. Context graphs answer relationship and provenance questions that flat retrieval can't.
What makes context graphs a distinct database workload?
Context graphs are append-heavy, bitemporal (tracking when facts were true and when they were recorded), provenance-rich, permission-aware during traversal, and latency-sensitive enough to sit in the inference path. No existing database category cleanly combines all of these.
OLTP graph databases weren't designed for append-heavy temporal workloads. Vector databases don't encode directional relationships, temporal validity, provenance chains, or permission-aware traversal.
What is the ontology trap in AI infrastructure?
The ontology trap occurs when you adopt an off-the-shelf context layer and unknowingly inherit its schema assumptions. That schema decides what counts as a node, which relationships are first-class, how time works, and how permissions propagate. In a demo this feels like acceleration. In production it becomes a ceiling, because your domain's needs will diverge from the vendor's assumptions.
How does object storage reduce context graph costs?
Managed graph databases typically price per gigabyte of provisioned RAM ($65-146/GB/month). Object storage runs ~$0.023/GB/month. When your graph must live in RAM at those rates, you prune and curate, losing the provenance and temporal state that agents need. Object-storage-native architecture lets you retain every relationship, version, invalidated fact, and evidence chain. What should I look for in context graph infrastructure?
An engine with strong technical opinions about storage layout, traversal planning, provenance indexing, temporal edge compaction, permission-aware retrieval, and hot/cold separation, but no opinion about what your nodes and edges mean. The infrastructure should handle the mechanics of a context graph without forcing you into a schema that isn't yours.