Typedef built a graph so data agents stop guessing

Typedef's Yoni Michael told AI Engineer that agents fail on data not for lack of SQL, but lack of grain, join safety and metric meaning, and showed a graph that catches breaks pre-flight.

Diagram of data context graph connecting warehouse, code and BI for AI agents
AI Engineer
article>

Typedef co-founder Yoni Michael spoke at an AI Engineer workshop, and his argument was straightforward. Coding agents don't fail on data because the models are weak. They fail because context is missing. He then demoed the Data Context Layer his team built to fix it. Michael's bet is that agents will become core operators of warehouses and pipelines, which means they need a reasoning layer that mirrors how the data team that built the system understands it end to end.

Typedef built a graph so data agents stop guessing - AI Engineer
Typedef built a graph so data agents stop guessing, AI Engineer

Valid SQL is not enough.

Michael said the missing context is scattered everywhere. The warehouse holds rows, transformation code holds business logic, the BI tool holds metrics and dimensions, and docs and Slack hold tribal knowledge. An agent that only reads code re-derives context every prompt, probabilistic and bounded by the window. An agent with only database access via a Snowflake or Databricks MCP connection can sample rows but cannot tell what one row is supposed to mean. He called that meaning grain, what each row represents, and showed how a grain change breaks everything downstream even when queries compile. If a customer by month table silently becomes customer by week, every sum after it is wrong.

The layer makes four facts computable and queryable: grain, whether a join is safe, what a metric means, and what relates to what. Michael said the principle is deterministic first, LLM only for ambiguity. Typedef parses all transformation SQL down to its abstract syntax tree to compute grain and lineage straight from implementation, so the graph cannot drift. It then verifies join safety by profiling tables in the warehouse to check if a join key is actually unique and what cardinality will fire. The LLM comes in last, naming assets, summarizing model utility, and resolving human readable ambiguity on top of the deterministic graph.

That graph is the Data Context Layer itself. It is computed once and refreshed atomically on every commit, so it stays representative of production. Michael said it is a graph not a pile of markdown because the access pattern matters. The agent pulls exactly the subgraph it needs in one traversal with Cypher, instead of prompt stuffing a 500-model dbt project every session. Edges carry provenance, with typed relations like is materialized by and has semantic definition, connecting physical tables, logical models, and semantic views and dashboards from sources to BI. The same idea applies outside SQL. As a daily.dev summary of the talk notes, two Rust types both called PostingList break different code. A text search finds both but flattens them, while a context graph preserves their distinct identities and blast radii, which is why graph traversal beats keyword retrieval for impact analysis.

Three pre-flight use cases run on that traversal. For impact analysis, the agent walks downstream before editing a grain and checks if a downstream node, like a monthly ARR measure, would repeat across weekly rows and inflate 4x onto a board dashboard. For join recommendations, it does not pick a path by column name. It checks profiled uniqueness and flags paths that would fan out 7x or silently drop 12% of rows. For safe code changes, it treats business predicates as first class constraints, so tidying SQL that drops a paid filter and silently redefines a metric to include trial churn is caught before commit. Michael said Typedef measures this with eval driven development on isolated clones of real data environments, running the same tasks and models with and without the layer and checking pass fail plus LLM as judge for impact analysis. The constraint is operational: the gains depend on continuous warehouse profiling and atomic graph refresh, and the evals shown are internal clones, not a public benchmark.

© 2026 StartupHub.ai. All rights reserved. You may not republish this article in full without a license. Search engines and AI research tools may crawl and summarize for reference. Bulk reproduction or model training requires a license. See our terms.
Daniel Singer

Written by

Daniel Singer

Editor, StartupHub.ai

Daniel Singer is the editor of StartupHub.ai, a technology expert and thought leader on AI and its applications across sectors, from fintech and healthcare to developer tooling and consumer software. He writes and tests the tools covered here thoroughly and regularly, and built StartupHub.ai to give founders, operators and buyers a clearer read on what they are actually being sold.