Yoni Michael

Yoni Michael is the co-founder of Typedef, where he works on infrastructure that helps AI systems interpret enterprise data and assess the consequences of changing it. His work connects two problems: operating language-model inference as a maintained data pipeline, and giving agents enough knowledge of data relationships to recognize when executable SQL would produce a misleading result.

From hardware telemetry to AI pipelines

Yoni previously co-founded Coolan, a data-center analytics startup acquired by Salesforce. At Salesforce, he worked on predicting hard-drive failures. Before models could identify conditions associated with failure, his team had to clean and standardize telemetry from manufacturers whose drives reported incompatible measurements. Data preparation served a concrete operational purpose: identifying unreliable hardware before it disrupted service. Salesforce’s account places his contribution within the broader infrastructure engineering effort.

Yoni later led infrastructure engineering at Tecton, working on machine-learning feature platforms across batch and streaming workloads. In a career and technical interview, he connects that experience to his emphasis on versioned, reproducible data assets and simpler execution systems for AI workloads. At Typedef, that approach means managing prompts, schemas and evaluations explicitly, and expressing pipelines as dependency graphs rather than collections of scripts.

Yoni founded Typedef with Kostas Pardalis. Their early work addressed the machinery surrounding language-model inference: batching, retries, provider limits, costs and evaluation. Treating inference as a data transform would let teams schedule, inspect and maintain it alongside conventional processing. Typedef’s open-source Fenic brings semantic operations into a familiar DataFrame interface. It is a team project, combining language-model capabilities with data-processing operations that developers can compose and inspect.

Giving agents the relationships behind the data

Yoni and Kostas’s data context layer addresses a limitation of agents that can read transformation code but lack a maintained understanding of what it means. A change to a join key can duplicate rows and inflate a revenue metric while leaving the SQL valid. Detecting that problem requires more than checking syntax: an agent needs to know what each row represents, how columns were derived and which downstream calculations depend on them.

Their approach combines several kinds of evidence:

• Grain and join relationships: Establish what a row represents and check join assumptions against real data. This helps expose fan-out, where a join multiplies rows and changes the meaning of an aggregate.
• Lineage and dependencies: Preserve column-level relationships and downstream dependencies in a queryable graph, so an agent can inspect the likely impact of a proposed change before making it.
• Business meaning: Use deterministic structural analysis first, then language-model interpretation where judgments about meaning are needed. Persisting the results lets agents retrieve relevant context instead of reconstructing the system for every question.

In The Data Context Layer for Agents, presented with Brandon Callender, Yoni develops the data-engineering side of this argument: an agent should inspect grain, lineage and relationships before acting. Brandon’s companion coding workshop explores symbol identities and dependencies in Rust. The shared concern is concrete: access to code or data does not by itself reveal what a change will affect. Yoni’s contribution centers on making those relationships available for data-system decisions, including safe joins and changes to metric definitions.