GraphCon 2026 Themes & Takeaways

Two weeks ago I had the pleasure of attending the first GraphCon Seattle event. This inaugural practitioners conference, planned and produced by the Graph Geeks community, focused on how folks are solving real world problems in practical ways, using a range of technologies and approaches. Though a one day event, it was packed with thought-provoking perspectives and rich with opportunities to talk with other graph enthusiasts exploring and trying out new ideas with graph approaches to information and knowledge management.

Graph Geeks generously plans to make videos of all the talks available on their YouTube channel, so keep an eye on that space to check out the talks first-hand. In the meantime, here’s a rundown of the themes and takeaways that emerged for me across the day’s talks and across my conversations with other practitioners.

Top Themes & Takeaways

1. Value drives adoption — no one cares that you’re using a “graph”

This theme will strike you as ridiculously obvious, because “of course value drives adoption.” We’re all smart, reasonable professionals, making sound decisions based on solid information. Right? Setting aside high irony for a moment, there’s another challenge for graph enthusiasts: we’re really excited by the technology. This means that even when we know we shouldn’t, it’s hard to resist talking to someone about “the graph.” As Brad Bebee with Amazon Neptune points out, “graph” itself is not an intrinsic benefit. Building support for the solutions graphs provide means finding and clearly articulating the benefits those solutions will provide for the organization — and (ideally) stopping there.

It’s this last part that is hard for graph practitioners to follow through on. Himanshu Singh recounted that in the process of moving from proof-of-concept to day-to-day graph operations with Netflix, they removed the word “graph” from messaging to stakeholders and collaborators. They even went so far as to remove the word from the name of their project group. Singh advises against “onboarding” your users. You should instead meet them where they are. If people using your solution have to learn a query language or the care and feeding of graph models, you’ve failed. The better outcome is one where they don’t know they’re using graph technology at all. (Mercifully there are events like GraphCon where the graph nerds can properly nerd.)

Talks

2. Graphs are evolving systems

This one was kind of obvious … and kind of not. For those of us coming from the IA and taxonomy world, of course models and implementations have to evolve. An information model is no more “one and done” than is quarterly business planning (hence, you know, its quarterly-ness). But there are some aspects of graph work that can feel settled: top-level ontologies and industry standard taxonomies change slowly and provide stability against fast-changing market pressures. In his talk, “Connected Intelligence: How Graphs Transform AI,” David Hughes makes the argument that in intelligently connected systems, AI should also transform the graph. As Hughes puts it, evolving systems should “return the consequences [of an operation] back to memory.” These “remembered consequences” become part of the graph.

Yohei Nakajima refers to this as “moving toward an ever-evolving ontology.” In this scenario, ontologies are never “finished,” but are rather a way to represent and understand the state of an agent. The benefit is to mitigate or eliminate the limitations of session-based AI in a scalable and transparent way. Dave Bechberger provides some of my favorite descriptions of this problem: as Bechberger puts it, AI’s “goldfish problem” stems from “session amnesia” and a “re-derivation tax,” where discovered facts must be continually rediscovered. Markdown context documents are a workaround for session-to-session memory, but it’s with graphs that we can approach durable memory for long running processes. Bechberger again: “Vectors remember what. Graphs remember how it relates, and when it was true.”

Talks

3. It’s all about the models

One of my favorite motifs across talks was the idea that the real value graph-minded work delivers is not a set of technologies, but rather the models that graph technologies are used to represent. Brad Bebee makes the point that “you don’t need a graph database to use a graph model.” Indeed, the collection of Markdown documents many folks are using for session-to-session AI context are essentially graph models already. Bebee advises that the opportunity before us as graph practitioners is to “be ready to help [these folks] do this better.”

As an IA/UX professional who came into the field when mobile browsers were just starting to gain traction, this combination of model centrality and learning systems maps cleanly in my mind to a practice our industry has honed over many years: progressive enhancement. This is the idea that the systems we design, be they responsive websites or agentic workflows, should start with the basic, core functionality we intend to deliver, they layer on speed, performance, and aesthetic enhancements as the context of use allows. Crucially, should any of these enhancements fail, the core, basic functionality must remain operational. When combined with AI, a graph is an enhancement of the underlying model. Building these models right, and ensuring that they evolve consistently over time, is far more important than which database we choose or whether we represent data as triples or nodes, edges, and properties.

Talks

4. Polyglot systems

There’s an ongoing (and certainly faux) controversy in some corners of the graph community over which representation of graph data is “better”: Resource Description Frameworks (RDF) or Labeled Property Graphs (LPG). I was delighted to discover that the GraphCon community was having none of this “controversy” nonsense. Himanshu Singh described a project his team ran on a semantic (RDF) graph on the back end, transformed to a property (LPG) graph on the front end, and which was then accessed by end-users that didn’t know they were using a “graph” at all. David Bechberger likewise frames the roles of vector stores and graph stores as fundamentally complementary: each supports the other by filling in where the other is weak — and getting out of the way when it’s poorly suited for a given task.

As someone who learned a second language as an adult, I have a personal appreciation for the benefits of polyglotism. Having a second language at one’s disposal opens up new worlds of literature, film, and culture — to say nothing of one’s experience as a traveler. Beyond these first order benefits, however, the process of learning and operating in a new language generates new insight into one’s native language. Once I had to learn to speak and think outside of English, my understanding of what makes it work (and what makes it fail) changed entirely.

When applied to how we model data, a polyglot approach likewise offers promise for both first and second order benefits. Moving between, for example, RDF and LPG, allows us to choose the right set of capabilities for the task at hand. It also encourages us to scrutinize the underlying model that each is meant to represent and challenge the decisions and structures that result from thinking primarily in one idiom or the other.

Talks

5. Informed delegation

As an event focused on practitioners and real world solutions, GraphCon presentations did not shy away from code examples and live demos. Talks and hallway conversations likewise grappled head-on with the question of how much code one actually writes any more, as opposed to generating with the assistance of LLMs. BoundaryML CEO Vaibhav Gupta stated the case for machine generation directly: “it’s no longer possible to keep up with code subsystems … but we can constrain them.” Indeed, as I understand it, that’s the whole purpose of BAML, the “agent-first” language his company creates.

Hallway conversations with developers likewise revealed a surprisingly uniform acquiescence to the changing role of individuals in the code creation process. One developer I spoke with said he hardly writes anything by hand any more — and doesn’t miss it. Instead he prefers spending more time with the problem solving and strategy work that informs the scaffolding and constraints he puts in place for the LLM. We’re still in the early days of sorting out what these agent assisted workflows look like — and how to make them consistently reliable — but one thing I didn’t run into were devs pining away for the good old days of writing error handling code and hunting down missing semicolons.

Talks

The year of the graph?

There was an ongoing joke throughout the day about how many consecutive years over the last few decades have been proclaimed “The Year of the Graph” … and about how flatly each of those predictions have fallen. This was a laid-back enough crowd that I felt like everyone enjoyed the self-deprecating humor. At the same time, there was a palpable sense that graph approaches and technologies are finally finding a compelling, widespread use case as a complement to generative LLMs in the way that modern software is created and maintained. Is this finally “the year of the graph”? I won’t venture a guess, but if it is there’s a good chance that those doing the work won’t use the word “graph” in describing the value they deliver.

Related Resources