Data Engineering Podcast

The episode delivers substantial technical and conceptual depth on multi-agent state management, graph semantics, and the distinction between logical vs. physical data models. However, significant portions involve broad philosophical discussion, repetition of core concepts, and some meandering tangents that dilute density. Strong core ideas are present but padded with elaboration.

“context is actually when an agent is supposed to perform a piece of knowledge work, know, how to sure that the agent actually has access to the right information with the right knowledge. And then also for multiple agents means you'd actually have access to us like a shared world model, shared understanding essentially of the world.”

“the ontology in some sense, it actually imposes a kind of a reasoning process on the agent, Because if essentially you are forced to, when you insert knowledge to kind of idea to the ontology, then you have to kind of follow the reasoning process”

The core framing of agents as inherently probabilistic writers needing Git semantics is relatively fresh. The ontology-as-reasoning-enforcer concept and the branch-as-solution-space-exploration idea are thoughtful. However, the underlying components (lakehouses, graph engines, declarative systems) are established patterns, and much of the discussion recycles familiar concepts about multi-agent coordination without delivering truly novel frameworks or counterintuitive claims.

“agents are really probabilistic writers, so this kind of Gitstar paradigm becomes super important”

“the ontology in some sense, it actually imposes a kind of a reasoning process on the agent”

Ragnar Comerford is a genuine practitioner with deep domain expertise: he has built data infrastructure at scale (Edison, Q Bio), worked hands-on with LLM-based protein design, and is actively building and deploying OmniGraph in production with real customers. He speaks from direct engineering experience rather than theoretical framework-peddling. His ability to articulate both high-level design philosophy and low-level technical tradeoffs demonstrates substantive operating experience.

“spent quite a bit of time working in San Francisco at Edison's a company called Q Bio that built like a medical digital twin, and built lot of their internal data infrastructure and graphs”

“working quite a bit in machine learning and computer science, I kind of dove quite a bit into the life sciences or biotechs”

The episode lacks concrete numbers, timelines, and deployment metrics. While Ragnar references actual use cases (trading system, ML model training, code graphs), he provides almost no specifics: no customer counts, no performance benchmarks, no adoption timelines, no cost comparisons. Technical architecture is described at a moderate level of specificity (Lance, Data Fusion, branching semantics) but without concrete implementation details. The discussion remains largely illustrative rather than data-driven.

“one team of you using it also as a kind of for automating like, essentially, like an automated basically trading system. It's not a high frequency trading system, basically like a more one based on like fundamental research”

“we kind of offer essentially the control pane right around essentially managing this whole kind of state”

Tobias asks solid foundational questions and demonstrates genuine familiarity with the space (references to Neo4j, Cypher, DOLT, PuppyGraph, Iceberg). However, he rarely pushes back or challenges claims. Follow-ups are mostly clarifying rather than probing. When Ragnar makes sweeping claims (e.g., 'most knowledge work will be performed by agents'), Tobias doesn't interrogate assumptions, viability timelines, or competing approaches. The conversation is collegial but lacks productive friction or skeptical depth.

“And I'm wondering if you can just talk to the core foundational aspects of graphs and some of the graph engines that are in the market and what was lacking that led you to decide that you needed to create a another new one.”

“I'm wondering what are some of the engines or systems that you drew inspiration from as you were coming up with the initial ideas and architectural layout for Omnigraph?”