4 min
Manveer Chawla
Updated on :
Brain is a self-improving context-graph of all your sessions, connectors, and files.
That's Aravind Srinivas describing what Perplexity built under the hood of its Computer agent. The official blog went further, calling Brain "a living context graph" and "a traceable graph" that lets Computer "traverse this web of personal information." Perplexity called Brain a memory system, but the architecture they described has graph semantics.
We don't know Perplexity's storage engine. The serving layer may synthesize graph state into an "LLM wiki" before each agent run rather than doing live graph traversal. But the runtime format doesn't change what Perplexity exposed: the memory abstraction is graph-shaped.
Why AI agent memory needs more than embeddings
Most "memory" features store user preferences and conversation history. Brain stores sessions, connector results, source documents, corrections, failed actions, tool-call traces, and the relationships among them.
Every memory entry "links back to the session, file, or source it came from." The system synthesizes this into an "LLM wiki" loaded into the agent sandbox before the next run, so Computer starts with "full context of your projects, decisions, and sources instead of from scratch." That's a working state with provenance attached to every piece of it.
A serious agent needs to carry forward which sources were trusted last time, which approaches failed, which user corrections superseded prior behavior, which project a task belongs to, and what changed since the last run. These are relationship and provenance questions, and a flat list of embeddings can't answer them.
Embeddings tell you what's semantically nearby. They don't tell you what depends on what, what superseded what, or what broke last time and why.
This is a graph problem because the agent's next useful context is rarely within one lookup. It needs to move from a task to prior sessions, from sessions to corrections, from corrections to sources, from sources to decisions, from decisions to current constraints, and from constraints to what it should do differently this time. That retrieval shape is traversal.
Perplexity saw a 25% lift in answer correctness, 16% better recall, and 13% lower cost on tasks requiring historical context. These are internal numbers with no published methodology. Structured relational context made the agent measurably better at work it had seen before.
How Capital One built graph-based memory for AI agents
Capital One's engineering team published a case study about the same problem. They ran an internal AI assistant that engineers queried about services, migrations, and architecture decisions.
The agent could reason about OAuth2 flows, suggest migration patterns, and outline testing strategies. But it couldn't remember that three weeks ago a different engineer mentioned a blocking dependency, or that conversation 23 contained a decision to use OAuth2 over SAML, or that an architect flagged a backwards compatibility risk in conversation 38. Their summary: "The agent is not unintelligent. It is stateless."
Their first instinct was transcript RAG over conversation history. RAG works as a read path for finding candidate fragments, but it can't preserve the relationships, lifecycle, or provenance that tell the agent which fragments matter right now. It broke down on signal-to-noise (raw transcripts are mostly pleasantries, not extractable facts), relationship awareness (the connection between Service X's auth flow and Service Y's deprecation timeline is a dependency, not a semantic similarity), and contradiction handling (early conversations said Kafka, later ones said Kinesis, and the vector store surfaced both).
So they built a graph. Entities as nodes, claims as directed edges with confidence scores and lifecycle states (proposed, accepted, deprecated). Every claim links back to the specific conversation, message, and extraction model that produced it.
When new evidence contradicts an existing claim, the old one gets deprecated with a timestamp and preserved for audit. The agent retrieves structured, versioned, trust-scored claims instead of raw transcript chunks.
Capital One's conclusion was not "buy a graph database." It was "model the memory as a graph first." They built it on relational tables with recursive CTEs, and it worked at their scale. Teams tend to emulate new primitives inside existing systems until the workload gets too hot, too deep, or too permissioned to fake.
Context graphs are not enterprise knowledge graphs
Both Perplexity and Capital One arrived at the same abstraction: a temporally versioned, provenance-preserving graph of agent work. That abstraction looks like a knowledge graph on the surface, but the workload and lifecycle are different.
A knowledge graph maps what is known: entities, attributes, and stable relationships. It's entity-centric, curated, and relatively static. A context graph maps what is in motion: what happened, what changed, what worked, what failed. It's session-centric, constantly mutating, and updated after every agent run.
Enterprise knowledge graphs historically stalled on ontology maintenance. Context graphs don't eliminate that work. They change where it happens. Instead of designing a complete taxonomy up front, teams bootstrap structure from agent traces via LLM extraction, then govern the predicates, lifecycles, and extraction quality as the graph evolves.
The workload profile is write-heavy, temporally versioned, permission-scoped, and latency-sensitive at inference time. Context assembly sits on the inference path, so traversal latency matters in a way that batch analytics queries don't.
Where Postgres and vector search start to strain
A support escalation links a ticket to a Slack thread to a Jira issue to an incident postmortem to a product spec. A renewal agent needs to pull three SEV-1 incidents from PagerDuty, an open escalation in Zendesk, and a prior exception approval from last quarter.
The CRM stores the price, but never stored why it was allowed. Each of these chains requires directed edges, provenance, temporal validity, and permission-aware traversal.
Most teams start with Postgres, a vector index, and some glue, and they should. But when the agent's context becomes a living graph of relationships, provenance, time, and permissions, the stitched stack strains. You get serial round-trips across system boundaries, duplicated state, sync lag, provenance fragmentation, and permission mismatches between stores that were never designed to stay in sync.
Recursive CTEs over join tables hit B-tree index lookups at every hop, and latency degrades as depth and fanout grow. Embeddings created storage pressure, leading to vector databases. Stateful agents are creating similar pressure for graph-native context infrastructure. HydraDB is built for this workload: context graphs that are write-heavy, temporal, provenance-rich, permission-aware, and served on the inference path.
If you're building a context graph, set up time with HydraDB's founder to talk through the architecture with you. No sales deck.