We Were in the Room When the Context Graph Conversation Got Serious

Last week, Neo4j hosted the inaugural Context Graph Meetup in San Francisco. Here's why it mattered, and what the evening revealed about the future of enterprise AI agents.

There's a particular energy to a room where people are working on the same problem from different angles and don't yet know it. That's what the Neo4j conference felt like on the evening of the inaugural Context Graph Meetup in San Francisco.

Over 300 researchers, engineers, and enterprise architects had shown up, some because they'd been building graph-based agent memory for years, some because they'd just hit the production wall that the context graph thesis describes so precisely, some because they'd read the Foundation Capital essay and wanted to know if the hype had any infrastructure behind it. The conversation started over drinks at 5pm and didn't really stop until well after the scheduled wrap-up.

Rippletide's own Yann Bilien was on the stage. But beyond the pride of being part of this inaugural lineup, what struck us most was the convergence happening in real time across the four speakers. Everyone was pointing at the same gap, from the same direction, with increasingly concrete tools for filling it.

Here's what was said, and why it matters.

The Problem in the Room

Before getting to the ideas, it's worth naming what brought 300 people to a meetup about something as niche-sounding as "context graphs."

The short version: AI agents keep failing in production in ways that are hard to predict and impossible to explain. Not because the models are bad, the models are remarkable. But because agents are being asked to make decisions in environments where the reasoning context for those decisions has never been formally represented anywhere.

Organizations run on institutional knowledge. Precedents. Exceptions. Evolving constraints. The logic behind a discount approval, the reasoning behind a procedure deviation, the accumulated judgment behind a thousand policy calls that never made it into documentation. Human employees absorb this through experience. AI agents have no equivalent mechanism. They have data. They don't have why the data means what it means in this organization, in this context, right now.

Context graphs are the emerging answer to that gap. And the evening was the first time we'd seen the full ecosystem, memory architects, knowledge management practitioners, enterprise governance builders, and ontology researchers, in the same room, pulling in the same direction.

The Memory Problem Nobody Is Really Solving

Will Lyon, who leads developer relations at Neo4j and works directly with organizations deploying agents in production, opened the evening with the cleanest framework of the night. His argument: agent memory is a solved problem in the wrong direction. Every framework handles the easy part. Almost none handle the part that actually matters.

The easy part is short-term memory, conversation history, session state. You get this out of the box with any agent framework worth using. The slightly harder part is long-term memory, persistent knowledge about entities, relationships, and preferences that accumulates across sessions. Graph databases have become the default substrate here, because organizational knowledge is inherently relational, and companies like Zep, Cognee, and Mem0 have made real progress on this layer.

What almost no one is building is reasoning memory: the record of why a decision was made. The inference chain. The precedent consulted. The constraint that was weighed. Without this third layer, an agent can remember that it approved a discount last week but not why, which means it can't generalize correctly, can't be audited, and can't be trusted anywhere compliance matters.

Lyon announced the release of neo4j-agent-memory, a Neo4j Labs open-source Python library implementing all three types, integrating with LangChain, LlamaIndex, Pydantic AI, OpenAI Agents, and CrewAI. The demo he brought, Lenny's Memory, a graph of 300+ podcast episodes with guest entities, companies, topics, and relationships all connected, made the case viscerally. When an agent traverses a knowledge graph rather than retrieving semantically similar chunks, the quality of reasoning changes category. Not incrementally. Categorically.

His challenge to the room landed with the directness it deserved: most teams are treating memory as a feature to be added later. The teams that treat it as a first-class architectural concern from day one are the ones with agents actually in production.

The Uncomfortable Truth About Building Context Graphs

Jessica Talisman, founder of Contextually LLC, took the stage next and delivered the talk that made the room a little uncomfortable, in the best way.

Her argument: the capabilities the context graph movement is describing are not new. They are what the knowledge management field has called process knowledge and procedural knowledge for decades. And most context graph implementations will fail for the same reason most knowledge management projects fail, people invest in the container and skip the methodology.

The distinction she drew matters. Process knowledge is tacit, lived, embodied in the people who actually do the work. It's the experienced operator who knows which sensor reading to ignore and why. It's the sales executive who knows which customer tier gets exceptions and which doesn't. Procedural knowledge is what process knowledge becomes once it's been formalized, encoded in a structured representation with enough semantic precision that a machine can actually reason over it. The transformation from one to the other doesn't happen automatically. It requires deliberate elicitation: observation, expert interviews, ontological design, vocabulary control, human validation.

Talisman pointed to the Procedural Knowledge Ontology (PKO), developed by researchers at Cefriel with Siemens, BOSCH, and Beko, as a model for what this rigor looks like in practice. PKO distinguishes between procedures as abstract specifications and executions as concrete instances. It tracks who performed a step, when, under what conditions, with what deviations and questions. It models the provenance of knowledge changes, who validated an update, against what version, at what moment in organizational time. This is the semantic structure that makes a context graph actually queryable rather than just a loosely connected collection of traces.

Her sharpest line of the evening: asking what database you should use before asking how you're going to capture your organization's decision knowledge is completely backwards. The graph is a container. The methodology is the work.

It landed.

Context as the Control Plane

Dave Bennett, who leads technical strategy at IndyKite, followed with the reframe that stuck with us most coming out of the evening. Context graphs, he argued, are not just a memory architecture. In a world where agents act autonomously, retrieving data, making decisions, triggering downstream processes, they become the governance layer. And governance, at agent speed, cannot be downstream. It has to be runtime.

The classical enterprise governance model was built for human-driven workflows. Permissions set upstream at the point of data classification. Audit downstream in logs reviewed after the fact. This worked because human decisions happened at known, bounded moments. You could govern the edges. The space in between was manageable.

Agentic AI breaks this model entirely. Agents access data dynamically, combine signals across domains in ways that can't be anticipated, make decisions as conditions evolve, potentially thousands of times per second. By the time a log entry records what happened, the action has already propagated. Post-hoc audit is not governance. It's documentation of what went wrong.

IndyKite, which formalized its partnership with Neo4j in December 2025, has been building toward exactly this: a context graph that evaluates whether a request is valid given the current state of the world at the moment of decision. Not just whether the data exists, but whether the access is appropriate given who is asking, what precedents exist, what constraints are in force, and what trust signals attach to the source. The context graph as control plane, the layer that determines whether an action should proceed, not just whether it can.

For anyone thinking about AI deployment in regulated industries, the implication is straightforward: compliance is not a property of outputs. It's a property of the decision-making architecture.

The Ontology Problem, and How to Make It Tractable

All of this raises the question every honest practitioner asks eventually: if context graphs require formal ontologies, and formal ontologies require knowledge engineering, how does this ever scale?

It's the right question. And it's the one Yann spent his time on stage answering.

His starting point was familiar to anyone who's been close to a real production failure. Agents don't fail because the model is bad. They fail at the edges, the judgment calls, the exceptions, the moments where the right answer depends on institutional context that no one encoded anywhere. These aren't stochastic failures. They're structural ones. Adding guardrails or output validators doesn't fix them. It patches the symptom while the root cause remains: the absence of a formal, computable representation of the decision context the agent is operating within.

Rippletide's answer is the Decision Context Graph, a hypergraph-based architecture built for deterministic reasoning. Given the same context, the same decision should always be reachable by the same reasoning path. This is what makes auditing meaningful: you can replay any decision, trace the reasoning that produced it, and verify whether it was correct given the context that existed at the time. Not probabilistic explainability. Actual traceability.

The central challenge Yann addressed is making ontology construction tractable. Traditional approaches require knowledge engineers to manually define the ontological backbone, expensive, slow, and brittle as organizational knowledge evolves. Rippletide's research focuses on automatic ontology generation: using language models and graph algorithms to infer the conceptual structure of a domain from signals already present in organizational data, documents, process logs, past decisions, exception records, and bootstrap a formal ontological structure without requiring manual encoding at every step.

The model doesn't create the ontology from nothing. It discovers structure that's already latent in how the organization thinks and decides, and encodes it in a form that can be reasoned over. The ontology then refines continuously through execution, as agents make decisions and those decisions are validated or corrected, the graph becomes more precise over time.

And the line Yann drew between this and RAG was sharp and worth repeating. RAG injects relevant documents into a prompt and relies on the model to synthesize coherence. A Decision Context Graph gives the agent something categorically different: a computable representation of why a decision is valid, grounded in a formal model of the domain. The agent isn't receiving information. It's receiving structured reasoning. The difference shows in consistency, in auditability, and in catching failure modes before they execute rather than after.

What the Panel Made Clear

The discussion that followed brought all four speakers together, and the most honest moment came from a question the audience pushed to the front: is building a context graph a technology project or an organizational one?

Talisman held firm: fundamentally organizational. You cannot engineer around the knowledge management problem. Bennett's counterpoint: at scale, you need technical mechanisms that make governance continuous, or organizational processes will always be outpaced by autonomous execution. Will and Yann both landed somewhere in between, the tooling should reduce the burden of building and maintaining context graphs, but it can't eliminate the need for human judgment in the loop.

The open problem they all agreed on was the one nobody has fully solved yet: keeping the graph current. Organizational knowledge changes constantly. Policies update. Exceptions get approved. New precedents are set. A context graph that reflects last quarter's decision logic is worse than no graph at all if an agent uses it to justify an action that violates current policy. Continuous update, through automatic ontology refinement, through live context capture, through execution feedback, isn't a nice feature. It's the entire product.

Why This Evening Felt Like a Before-and-After Moment

We've been to a lot of AI meetups. Most of them are about capabilities, what the latest model can do, how fast it runs, what new API just dropped. This one felt different.

The people in that room were past the capability question. They were working on the harder, slower, more important problem of making AI agents trustworthy, predictable, auditable, governable, and genuinely useful in environments where the stakes are real and the margin for arbitrary behavior is zero.

Context graphs aren't a buzzword that will cool off in six months. They're the infrastructure answer to a production problem that every serious enterprise AI team has already hit. The community building infrastructure is now visible, it's growing, and the work is becoming concrete.

You missed the conference? The replay is here!

We're glad to be part of it, and grateful to Neo4j for creating the space.