Why Multi-Agent Systems Need Shared State, Graph Semantics, and Governance
Summary In this episode Ragnor Comerford talks about OmniGraph, a lakehouse-native graph storage layer designed around the needs of agentic systems. He explores how graphs are primarily a semantic model for representing the world, rather than just a specialized engine for traversal workloads, and how that perspective shaped OmniGraph’s design on top of object storage, Lance, Arrow, and DataFusion. Ragnor explained the motivation for combining graph semantics with Git-style branching and merging so that teams can manage probabilistic writers such as AI agents with stronger governance, shared context, and safer collaboration patterns. He also dug into the practical tradeoffs of building a graph engine for multi-agent coordination instead of traditional graph analytics use cases. He closed with a look at emerging use cases such as company “brain” systems, software development lifecycle graphs, research workflows, and event-driven agent orchestration, along with a broader conversation about composability, and sovereign AI infrastructure. Announcements Hello and welcome to the Data Engineering Podcast, the show about modern data management Your host is Tobias Macey and today I'm interviewing Ragnor Comerford about OmniGraph, a lakehouse-native graph storage layer with git semantics Interview Introduction How did you get involved in the area of data management? Can you describe what OmniGraph is and the story behind it? What was the original problem that you were trying to solve by creating it? There are numerous graph engines available, what are the properties of OmniGraph that differentiate it from the competition? Cypher (GQL) and Gremlin are all established languages with years of examples to work from. What are the benefits of developing a new and more constrained query interface for an agentic audience? How does that change the potential applications of OmniGraph? (e.g. general knowledge graph, fraud detection, SIEM, etc.) Can you describe the architecture of OmniGraph? You have built the system on top of several well-established open source components. What was your process for deciding what to use and how to compose it? What are some examples of systems that can be built with OmniGraph? What are other components/integration points that compose well with OmniGraph? Given the technologies that you are building on top of, what are the automatic benefits/integrations that you benefit from? Given that the underlying storage is Lance, and Lance's interoperability with Parquet/Iceberg, what are the opportunities for modeling graphs on top of existing lakehouse data? What are the most interesting, innovative, or unexpected ways that you have seen OmniGraph used? What are the most interesting, unexpected, or challenging lessons that you have learned while working on OmniGraph? When is OmniGraph the wrong choice? What do you have planned for the future of OmniGraph? Contact Info LinkedIn Parting Question From your perspective, what is the biggest gap in the tooling or technology for data management today? Closing Announcements Thank you for listening! Don't forget to check out our other shows. Podcast.__init__ covers the Python language, its community, and the innovative ways it is being used. The AI Engineering Podcast is your guide to the fast-moving world of building AI systems. Visit the site to subscribe to the show, sign up for the mailing list, and read the show notes. If you've learned something or tried out a project from the show then tell us about it! Email hosts@dataengineeringpodcast.com with your story. Links OmniGraph ModernRelay Information Theory Lance Git Neo4J GraphRAG TigerGraph LakeHouse Iceberg Dolt PuppyGraph Podcast Episode Terraform Gremlin Cypher GQL SPARQL In-context Learning BM25 Indexing Data Fusion Adjacency Matrix Predicate Pushdown Agentic Mesh book (affiliate link) witan-council witan-code Web Assembly Clickhouse DSPy MCP-UI The intro and outro music is from The Hug by The Freak Fandango Orchestra / CC BY-SA