Conference talk by Dmitry Petrov (DataChain) on the constraints of AI agent harnesses when working with large-scale physical-world data such as video, logs, and sensor data from robots, vehicles, labs, and factories. The talk argues that agent intuitions built for coding and business automation—where recompute is cheap—break down when data is petabyte-scale and stored outside the context window. Topics covered include expensive first-pass inference over raw data (e.g., searching terabytes of dashcam video), why loop/inspect/re-derive patterns become costly, OpenAI's in-house data agent operating over 600 petabytes in a structured warehouse, and proposed replacements such as materialization by default, first-class recall, and treating the dataset rather than the context window as the unit of state. A live demonstration with Claude Code over raw data in S3 shows follow-up queries returning quickly and cheaply instead of reprocessing. The speaker is co-founder and CEO of DataChain and previously created DVC (Data Version Control). # Channel Presentation Observations — Dmitry Petrov / DataChain ## Observable Channel Identity - **Creator-speaker**: Dmitry Petrov, presenting under the DataChain project banner (title: *"When Agents Meet Physical Data: The Other Physics of Agent Harnesses - Dmitry Petrov, DataChain"*). - **Format**: Conference-style technical talk with live demo — slides/whiteboard-style conceptual framing ("neutron star" metaphor) followed by a screen-shared walkthrough of an open-source tool. - **Format style**: Tutorial-plus-advocacy: framing a problem space, then demonstrating the presenter's own tool as the solution. ## Explicit Self-Description Claims - **Claimed experience**: > "I work with data for about 10 years. I built data version control project, Git for data, and now work on data chain." - **Claimed positioning**: > "I live in a very extreme side of the data universe, messy unstructured data." - **Claimed product affiliation**: > "We implement some of those principles in Data Chain project, which is open source. So, please check it out and put some mass on your agent." — an explicit promotional close. ## Intended Audience - **Developers/researchers building physical-AI and multimodal data projects** — evidenced by discussion of video, sensor data, robot telemetry, object storage, and coding agents (Claude Code, Copilot, Codex). - **Practitioners already experiencing failure with agents on unstructured data**: > "If you try this, you probably have seen how badly it fails." - Assumes Python/data-engineering fluency (Pydantic, Dask, Spark, SQL, pip install) — audience is technical, not general. ## Claimed Scope of the Channel/Content - Focus on **unstructured/physical data engineering for AI agents**, explicitly distinguished from structured-data work: > "the problem we are solving here it's very specific for structured data, physical data. It doesn't exist in the structured data world." - Coverage includes: data schemas, execution engines, checkpointing, testing/verification, and agent memory/knowledge bases — a full "data harness" stack. ## Demonstrated Presentation Patterns - **Anchors claims to external frontier-lab sources**: cites Anthropic ("accuracy for data projects on their agents is only 21%") and OpenAI ("six layers of context") blog posts — pattern of grounding arguments in industry citations. - **Live demo as evidence**: installs via pip, runs Claude Code, analyzes 91 dashcam videos ("82 out of 91 clips have some people detected"), inspects generated Pydantic schemas and source code. - **Vivid analogies**: the "neutron star" metaphor for metadata explosion (2,000 files → millions of objects); "give him a leg" for agent tooling. - **Opinionated engineering stances**: criticizes JSON-on-S3 ("millions of JSONs. Crazy latency") and dual-stack databases ("SQL island in your code base"); advocates Pydantic schemas and incremental checkpoints ("must-have"). - **References to prior industry work**: dimensional modeling, star schemas, "one big table approach" — presented as transferable wisdom, not original. ## Open-Source / Community Positioning Evidence - DataChain presented as **open source**, supporting multiple coding agents: > "we support three more different coding agents." - Invitation to adopt: "please check it out" — suggests channel serves partly as project outreach alongside education. # Delivery Observations: Dmitry Petrov — "When Agents Meet Physical Data" ## Tone - **Conversational and informal** throughout, marked by filler words and casual asides: - "right?" appears constantly as a checking device: "It doesn't seems like a big deal, right?", "Just that easy and nice Python code… right?" - "Uh" fillers are pervasive, consistent with live, unscripted conference delivery. - **Light humor and irony**, often at the expense of common-but-bad practices: - "And the next idea, why don't we use database? Brilliant." - "So, please check it out and put some mass on your agent." ## Vocabulary & Recurring Metaphors - **Physics/astronomy framing is a sustained motif**, introduced early and reused: - "all the physics laws behind the problems" - "It looks like uh neutron star. It small size on the surface… But the mass of this object is tremendous." - Later callback: "So, that's about the size of our neutron star, right?" - Closing callback: "if you discover this neutron star or black hole, it's better to share this information" - **Body-part metaphors for agent capabilities**: - "giving him a leg", "It should be able to touch data" - "It's kind of like a hands of your agents, hands of your uh harness." - **Consistent contrast structure**: "structured data world" vs. "unstructured / physical data world" — repeated many times, e.g. "In the sequel or structured data world, execution engine is your data warehouse… In an unstructured data world, you have to reinvent one." ## Recurring Phrases & Verbal Habits - **"right?"** as a rhetorical anchor — appears dozens of times across the talk. - **"kind of like"** as a hedge/softener: "It's kind of like explosion", "It's kind of like a Dask approach if you wish", "It's kind of like a hands of your agents." - **"and such" / "so forth and so on"** to trail off lists: "with all the indexes uh and such", "the schema they produce. Uh so forth and so on." - **"over and over" repetition for emphasis**: "doing the same job over and over and over again", "so you are not wasting this time over and over again." - Repetition self-repair within sentences: "get data get data data set", "it can easily it can easily be multiplied by 10 20". ## Teaching Habits & Structure - **Problem → common wrong approaches → proposed solution** pattern: - Problem (JSON files): "they end up with a millions of JSONs. Crazy latency, not efficiency, not consistency." - Second wrong approach: "let's put a centralized database… But this way you end up with a two system with a two programming languages." - Solution: "the easiest way for researchers and developers to deal with the schema is Pydantic." - **Live demo with narrated choices**: walks through tool setup ("first you need to install the tool… Using pip install") and narrates his own decisions ("let's use the smallest one", "let's do just per frame in this case"). - **Appeals to external authority**: cites Anthropic and OpenAI results twice — early ("accuracy for data projects on their agents is only 21%") and later ("as Anthropic put it in a right way…"). - **Numbered/enumerated mental model** for the harness: "It should see the data properly… run… touch data, verify the result, run tests, and also remember" — then the talk follows this outline (seeing → execution → testing → memory). - **Self-referential credibility statement** mid-intro: "I work with data for about 10 years. I built data version control project, Git for data." ## Communication Patterns - **Contrarian framing against default assumptions**: "you don't use stronger models. Everyone use frontiers. Instead, you are building data harness." - **Memorable closing slogan** tying back to the theme: "put some mass on your agent. Thank you." - **Explains by scale intuition**: repeatedly quantifies explosion of data ("2000 files of videos could easily generate you millions of objects", "90 videos generated 100,000 of records"). ## Uncertainty Notes - Audience reaction is essentially absent from the transcript (one "[snorts]"); no reliable observations about audience engagement can be made. - Timestamps in the transcript appear non-sequential/not wall-clock, so no timing-based delivery claims are made. # Observation Document: When Agents Meet Physical Data — The Other Physics of Agent Harnesses **Speaker:** Dmitry Petrov (DataChain), self-identified as having ~10 years in data work, creator of the "Git for data" project (DVC), currently working on DataChain. ## Core Thesis - **Agents are bad at physical/unstructured data** without purpose-built **data harnesses**. Petrov claims physical data (video, sensor data, robot telemetry, multimodal combinations) "fails badly" when processed by agents lacking such harnesses. - The fix is not stronger models: > "Everyone use frontiers. Instead, you are building data harness." - A harness must let the agent: **see data properly**, **touch/verify data**, **run tests**, and **remember** important datasets and results for reuse. ## Evidence Cited (Secondhand, As Attributed by Speaker) - **Anthropic:** agent accuracy on data projects is only **21%** until specific data harnesses and context are added. - **OpenAI:** published a model involving **six layers of context** to make a data agent work. - Petrov's qualification: these results concern **structured/unstructured business data**, not physical binary data, so the problem he addresses "doesn't exist in the structured data world." ## The "Neutron Star" Metaphor - Physical data looks small (a few thousand files) but explodes internally: videos → clips → frames → objects → labels/confidence/bounding boxes. - Claim: **2,000 video files can generate millions of internal objects**. In his demo, ~90 videos produced ~100,000 records. ## Critique of Existing Approaches - **JSON metadata files on S3 next to data:** results in millions of JSONs, "crazy latency, not efficiency, not consistency." - **Centralized database:** used by "the most advanced teams," but creates two systems, two languages, two stacks — complexity researchers reject. ## Proposed Solution: Pydantic-Based Schemas + Local Database - **DataChain** (open source) uses **Pydantic models** in Python for schemas, transpiled to SQL — same language for data, schema, and code; no "SQL island." - Data model shown includes: video file (path, checksum, e-tag, size), frame ID, timestamp, class ID, confidence, nested bounding box. ## Demo (Dashcam Video Analysis) - Workflow: pip install → install skill into coding agent (Claude Code supported, plus three others) → agent asks clarifying questions (model: YOLO, smallest size; simplest velocity method; per-frame granularity; January dataset, 91 clips). - Result: **24 minutes** of processing; query "how many videos have people?" answered quickly — **82 of 91 clips** — via simple Python filter against the local database rather than parsing JSONs. ## Execution Engine Requirements - Unstructured data lacks a natural execution engine (unlike structured data where "the data warehouse" fills that role). - Teams use Ray, Spark, orchestration tools; Petrov favors a **Dask-like model** connecting compute with data — for unstructured data. - Design: plain Python functions with typed (Pydantic) inputs/outputs connecting S3 files to warehouse rows; parallelization specified declaratively (e.g., "run on 40 machines"); mapper or generator patterns. - **Incremental updates and checkpoints are "a must-have"** — failure mid-run (bugs, API issues) shouldn't force recomputation; new bucket files should process incrementally. ## Testing and Query Layer - Testing is fundamental to coding agents ("hands of the harness") but slow on raw binary data. - Quoting Anthropic's framing (as Petrov relays it): in software there are many valid solutions; in data there is usually **one correct answer**, making accuracy more critical. - Solution: build a **metadata layer / dimensional modeling, star schemas, one-big-table** — "data industry knows this for a dozen years" — over raw data so questions are answered by fast queries. - Agents should first ask themselves whether such a layer exists before answering; layers should be **generalized to answer a family of questions**, not just one. ## Memory and Knowledge Sharing - People recompute the same datasets repeatedly, "paying double, triple, quadruple price." - Harness memory must include: dataset **description** (LLM-enriched), **session context** (why it was built), storage dependencies, **preview, stats, and source code** — with source code called "probably the most important part," which he attributes as a conclusion in the OpenAI data agent post. - Knowledge base = simple **set of MD files**, shared so teammates avoid recomputation; source data + source code + warehouse results form a **data lineage / knowledge graph**. ## Overall Stack 1. Unstructured physical data in object storage (bottom). 2. Compute engine (expensive LLM calls) extracting metadata. 3. Dataset slices via a dataset DB. 4. Knowledge base for sharing. 5. Coding agents (Copilot, Codex, Claude Code) operating on top. **Concluding claim:** coding agents' intuition "pushes them in the wrong direction" here because "laws of physics change" with physical data; the data harness restores efficiency. Implementation available in the open-source **DataChain** project. # Speaker Attribution & Provenance Record ## Speakers - **Dmitetro Petrov (creator, sole speaker)** — Author/video presenter, identified via title. Speaks throughout in first person ("I work with data for about 10 years"). No guests, narrators, or other speakers appear. ## Speaker Role Details - **Role:** Creator / presenter - **Self-described background:** - ~10 years in data work - Built **data version control (DVC, "Git for data")** — described as "data version control project" - Currently works on **DataChain** (open source project) ## Promotional Segments - ⚠️ **Demo of DataChain product** — a substantial mid-video segment demonstrates the speaker's own "open source project data chain with data harness to coding agents," including installation (`pip install`), configuration, and live usage. - ⚠️ **Closing call-to-action** — "We implement some of those principles in Data Chain project, which is open source. So, please check it out." ## Referenced Third-Party Claims - **Anthropic** (frontier lab, published this year): agent accuracy on data projects is only **21%** until data harnesses and context are added; also cited on the point that software problems have many solutions while data problems have one correct answer. - **OpenAI** (frontier lab, published this year): published **six layers of context** needed for data agents to work; source code identified as "one of the conclusion" of the OpenAI data agent blog post. - Note: These claims are second-hand references to blog posts; no direct titles or links provided. ## Referenced Tools / Technologies (mentioned, not endorsed claims) - YOLO model (used in demo), Claude Code ("cloud code"), Copilot, Codex, Dask, Ray, Spark, Pydantic, dashcam open dataset (unnamed) ## Comment Availability - **Not stated** in the transcript or metadata. How could intelligent work with physical data? Video recordings, sensor data, robots telemetry, and sometimes all of those combined in a single multi-model project. If you try this, you probably have seen how badly it fails. And today we'll discuss the reasons and all the physics laws behind the problems and how to fix it. This year two frontier labs published very interesting results and surprising results that agents in general are not good at data. Uh, Anthropic published that accuracy for data projects on their agents is only 21% until you add specific data harnesses to them and provide context. OpenAI published a whole layers of context, six layers of context in order to make the data agent to work. And all of those are unstructured data which lives in a very houses with tables, execution engine, and all this like luxury. In my life, I don't have this luxury unfortunately because I live in a very extreme side of the data universe, messy unstructured data. Uh, I work with data for about 10 years. I built data version control project, Git for data, and now work on data chain. In order to make agent to work for unstructured data, for physical data, we need to build not only the brain which we already have, right? It's LLM. Uh but we need to make harness data harness to for agents to understand this physical world. It should see the data properly. It should be able to run kind of giving him a leg. Uh it should be able to touch data, verify the result, run tests, and also remember the crucial important data sets, important result. So, this information could be reused uh in the future project. And the first we start from the how you see data. Uh what does it take to understand all these complicated binary files that you have in your object storages? Uh in reality, how it usually looks, uh they are just a several files, sometimes several thousand of files, right? It doesn't seems like a big deal, right? Uh but what is usually happens, those files are very complex inside. That what makes unstructured multimodal data complicated. And from 2000 because video recordings might have clips inside. Clips might have frames. Frames objects. Objects confident, type, class, label. Uh there's connection between those pieces together. It makes kind of like explosion. It's it looks like uh neutron star. It small size on the surface, right? It's just a size of a one city. But the mass of this object is tremendous. It's more than the mass of our sun. Uh and what 2000 objects, 2000 files of videos could easily generate you millions of objects inside the videos. And how people usually do deal with these problems? They usually go through like a two major steps. First step, let's put this meta information to JSON files and put it on S3 next to the images, right? And they end up with a millions of JSONs. Crazy latency, not efficiency, not consistency. And the next idea, why don't we use database? Brilliant. And the most advanced team do exactly this. Let's put a centralized database when all the meta metadata is uh in there. Great. But this way you end up with a two system with a two programming languages and all the mess around uh two different stacks. And this stacks useless for most of the researchers because they don't want to deal with this complexity. We found that the easiest way for researchers and developers to deal with the schema is Pydantic. Uh so you use the same language for the data, for the schemas, as well as code. Uh there are no SQL island in your code base. So in a that way you kind of transition from the messy world of structured data to the structure. The only thing you need to just like transpliers to the SQL uh from from Python and I'll show you uh how it works. But that's the way when you can create schemas uh and work with the schemas efficiently. I want to emphasize that the problem we are solving here it's very specific for structured data, physical data. It doesn't exist in the structured data world, right? For example, in those uh OpenAI and uh Anthropic blog posts because they work with the structured business logic, right? We work with the physical data, binaries and such. Let's see how it works. I will be showing you our open source project data chain with data harness to coding agents. So, first you need to install the tool, right? Using pip install. So, we have already done this. Then, skill needs to be installed. So, you choose the coding tool that you use. We will be using cloud code. But, we support three more different uh coding agents. And then, you run your favorite coding coding agents. Uh of course, we are skipping permissions. Uh just to make it faster, right? And then, you define the prompt and just solve your problems. So, in this case, we will be analyzing uh motions uh in video cameras. Uh that's open data set from um uh dashcam recordings. Uh video it's a very usual use case for uh physical AI projects. Uh majority of the project do include uh video recordings uh as a one of the modalities. Sometimes, the major modalities. Uh and that's one of the I would say more interesting and more challenging problems to solve uh in this uh physical AI world. Let's use uh this modality as an example. This data harness asks uh some questions from users to understand the scope better. So, in this case, it uh we need to choose the model. So, it decided to use a YOLO model and we need to choose the size. So, let's use the smallest one. Uh we need to choose the velocity. Uh so, there's a few ways how to track like speed. Uh but, let's use the simplest one. So, the second one uh adds more uh will require more time for the compute. And, granularity, so per detection frame, per track. Uh let's do just per frame in this case. And, the data set itself. So, we ask for January data, right? 91 clip, but it also ask for uh if we need to extend scope and uh analyze more images. So, let's let's stay here. So, it took us 24 minutes to analyze those uh 90 videos. And, now we have all the information, we can ask uh questions about it. For example, how many um videos have people in it? This information lives uh in the database, right? As we discussed, and it can very quickly query this database and return the result, right? So, okay. 92 uh oh, 82 out of 91 clips have some people uh detected, right? And uh you don't need to kind of go through all the JSON files download and analyze and parse, right? Information is here in the local database. It can easily quickly answer the question. We can even see the source code. \>\> \[snorts\] \>\> Okay, just that easy and nice Python code to get get data get data data set, right? Analyze apply some simple filters when label is equal to person. Count the number, right? And then see the total total number. And it goes like it runs against database so super fast. So, how big is how many records do we have here? So, that's about the size of our neutron star, right? It's not supposed to be big because we analyze only like 90 videos and 90 videos generated 100,000 of records, right? So, that's how explosion is happening. If you analyze thousands of videos, right? It goes to like a million million scale and if you go to deeper to the objects, it can easily it can easily be multiplied by 10 20 even hundreds. Let's take a look at the source code. This code was generated by the agents. Uh power agents using the harness. Uh The magic part here is the data model. So, this data class uh that was generated based on our requirements and it's a just a by dentic uh usual by dentic data model. Uh with the file. Uh right, the video file. Uh frame ID, timestamp, uh class ID, that's how you know if it's a personal car or some object, confidence score, bounding box, there a few more items here. And the object is nested. If you look at the If you take a look at the bounding box, right? There's a several columns, but files is more interesting. One. Uh file has uh path and the checksums like a version of the file, e-tag, size of the file. So, everything that's your cloud storage providers provides for you. Uh and this information is just become a row in a database uh instead of a JSON file in S3. Uh that's why you can easily uh answer uh all the uh questions. Uh all the analytical questions, right? Like before we asked how many people are there. Uh and it's just a matter of like a simple Python code that runs against the database uh to return like results super quickly. Uh that's how you can make sense of all the messy data you have on your storage, right? In a file, uh but you analyze uh you analyze this a using using regular analytical tools and two tricks. With the schemas, you can see what is inside the object. You can see the scale of the problem. But, how to do the actual heavy lifting when we when we deal with the terabytes of this messy data? You do know that the data harness have to have execution engine in order to deal with physical data. It has to work efficiently. Sometimes it spend a lot of resources and tokens if you sell them. And if it breaks somewhere in the middle, so you should be able to recover and catch up with all the data that it's already processed. So, you don't want to waste your resources. In the sequel or structured data world, execution engine is your data warehouse, right? That's obvious and easy. In an unstructured data world, you have to reinvent one. And in some teams, they use different types of orchestration tools or distributed computer on Ray or Spark. I like model of Dask which connects computer with the data structured data. But, unstructured data needs its kind of like own approach when you connect the Python and schemas with the execution engine. To simplify it, you can connect those Python functions, Pydantic schemas, input input parameters, output parameters for the function, as well as the data warehouse with all the meta information and files on the storage all together in a in a holistic experience. Uh that's what this way it will be more simple for developers to code and it might be simple for the engine to distribute jobs to different machines or different threads based on the files they process, the schema they produce. Uh so forth and so on. It's kind of like a Dask approach if you wish but for unstructured data world. To make the execution efficient, uh you need to run this uh data processing data crunching function very efficiently, right? In a parallel way or distributed way. And we use data models and the data storage models a lot. So, it kind of connects the file which is a file in your S3 bucket uh to the result uh that's a set of detection object which goes to the data warehouse, right? So, this function connects the storage and the data warehouse in a regular Python way. Uh so, that's a very typical Python code. There are no like extra assumptions about this code, right? We don't even use like annotation for the function. It's just a function with a specified types. So, the types are important. Uh and all of those are PyDantic. And result you just generate uh generate the objects and the engine connects all the storages and uh warehouse together, right? That's how you define the parallel uh parallelization layer. You can say uh Uh, I just need to run it in 40 machines, right? That's how easy it's supposed to be for is your chance to run like a distributed computer, right? You just specify how many resources you need, so you got it. And the function itself, right? So, we just use it run it through generator or it can be like mapper with one-to-one function, one function. Uh, one file returns like one object to the database or generator, one function returns like multiple objects in database. And it is saved as a like data set, right? Uh, uh, table under the hood, uh, in your uh, database. Processing of those heavy files usually takes a lot of time. And sometimes it's very expensive because you use LLM in order to understand what is inside uh, of your binary files. And the last thing you want is to lose this compute. It's really sad when you process uh, hundreds of thousands of files and it fails in the middle because of bugs or API call issue and you want to execute everything from scratch, right? You are losing the whole half of this compute and sometimes doing this over and over again. Incremental update and data checkpoints it's a must-have in this data world. If you fail, you fix the bug, run it again and catch up all the result that you have already. If you got more files in the bucket, uh, you run the script again and it gets only the new files and uh, update data based on the new computer only without recomputing the the other stuff. Running tests is a very fundamental part of coding agents. They do this all the time for quality control, for reasoning, to better understand what is around in their universe. It's kind of like a hands of your agents, hands of your uh harness. In data, running test is super slow process. And how to do this? Because quality and accuracy of the questions it's even more important in the data question data projects compared to software projects. Uh as Anthropic put it in a right way in uh software projects, there's a lot of ways how to you can solve a particular problem. In data, there is usually only one way and only one current correct answer uh to solve the problem. How to answer questions very fast on your binary data mass. And first of all, you should stop running all this like complicated Python scripts on top of raw data. That's the most expensive, the slowest way of doing this. Instead, you need to organize layer of meta information over like data sets uh or tables around this uh raw data uh that could answer these questions very quickly. And this something that data industry knows for like a dozen of years. It's a dimensional multi-dimensional data modeling uh star schema, one big table approach, and all this like fancy theories around around this. And we need to use this more in order to make our unstructured meta data processing uh to be more efficient. And we actually incorporated these techniques inside the agents. And when you ask a question, instead of answering the question right away, agent ask itself, do I have a proper data sets, proper metadata to answer this question quickly in a single like SQL-ish query. And if not, it tries to build this layer. It tries to make sure this layer is general enough to answer not your particular question, but a set of questions related to the one that you asked. And that's where you are building these layers and layers of information that's could be reused by you and your teammates. Now, you spent a lot of time, a lot of resources to compute those useful slices of the data, and you can use those to answer some interesting questions uh efficiently without really running expensive compute. And guess what? People are doing the same job over and over and over again. You're paying double, triple, quadruple price to solving the same problem. So, if you discover this neutron star or black hole, it's better to share this information with people uh so they won't be wasting their resources and their time uh to doing this stuff. And coding agent, as well as data agent, doing this those tricks with memory a lot. Uh your coding agent like Copilot, Codex, PI knows a lot about your source code, about with all the indexes uh and such. Uh on the data harness, you need to build and provide this context uh to your agents. And that's not only the fact that hey, there is a data set, you need to provide a lot more information with this. Uh why this data set was built, kind of like a context from the session. Uh description of the data set, which usually enrich by LLMs, source code. Probably the most important part here is the source code. Uh that's one of the conclusion in OpenAI data agent blog post. Uh and this information needs to be exposed uh exposed in a way like knowledge base. Some way that can easily be used by agents, by people. Uh so you are not wasting this time over and over again. And the knowledge base is organized in a very traditional way, I would say. Uh just a set of MD files, right? So uh you see this is how it looks like in the in my directory, but when I get more data sets. So the data set that we created, that one. Uh this is the MD file. Uh so description of the data set, right? The session context. Uh so why this data set was created based on the discussion. Dependency to the storage, to the directory that we pointed uh to in the beginning. Uh preview of the data. Uh very useful information to kind of have a sense of the data, this schema. Uh some stats on the data. And the source code. Uh as we discussed, the most crucial part uh to understand uh what is data is about. And all these pieces together, right? Uh the source data, right? In the bucket, the source code uh in the knowledge base, and the result in the uh in the data warehouse, create like a data lineage, right? So, everything is connected. Agents knows everything. If you share the knowledge graph, then all your teammates already know about this uh about this data set, about the resources you spent in order to process. So, next time if someone ask question about this directory, uh the recompute won't happen. Uh agents will be using uh your your result, uh the result which based on resources that you already that you have already spent, right? That's the magic of the uh data harnesses when agent knows everything about your data. Let's put all the pieces together in a single stack. In the bottom of the stack, there is some huge mass of your unstructured physical data in object storages. No one makes sense of this data, and you need to run expensive compute LM calls to extract some meta information through the compute engine, and organize this meta information in a data sets, in a data set slices through the some uh data set GB. Knowledge base is a way how you share this information. This is a world when your favorite coding agents, such as Copilot, Codex, Cloud Code, do not operate efficiently. Their intuition pushes them in a wrong direction because laws of physics changes. And in order to make it, you don't use stronger models. Everyone use frontiers. Instead, you are building data harness. Data harness that understand the laws of this physical data. And that's the way how to make your favorite coding agent efficient with these problems. We implement some of those principles in Data Chain project, which is open source. So, please check it out and put some mass on your agent. Thank you.