AI Engineer World's Fair 2026
When Agents Meet Physical Data: The Other Physics of Agent Harnesses
Read the talk
When Agents Meet Physical Data: The Other Physics of Agent Harnesses
Video, sensor data and robot telemetry need more than generated code: they need schemas, recoverable execution, cheap verification and memory of work already done.
From a talk by Dmitry Petrov
Before you start: Basic familiarity with Python, database tables and object storage will help you follow the schema and execution examples.
What does an agent see in a bucket of videos?
How should a coding agent work with video recordings, sensor data and robot telemetry—especially when one project combines all three? A directory listing reveals filenames, but not the objects, events or relationships inside those binaries. Generating a script is only the beginning of understanding and processing them.
Even structured analytics needs specialized context. Petrov points to Anthropic’s self-service analytics work: its internal analytics-question evaluations reported accuracy no higher than 21% without skills. That figure concerns those internal questions, not data projects in general. OpenAI’s in-house data agent uses six layers of context. Both systems start with the advantages of structured data: tables, warehouses and existing execution engines. Physical-data projects must first make sense of messy files.
Dmitry Petrov built Data Version Control, which he describes as Git for data, and now works on DataChain. His architecture starts with the LLM as the brain, then supplies the missing capabilities around it: sight to understand data, legs to execute processing, hands to verify results, and memory to retain important datasets and reuse earlier work. The harness must make the data understandable, executable, testable and memorable.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A small file inventory can conceal millions of objects
A few thousand files may look manageable until processing exposes their internal hierarchy. Videos contain clips; clips contain frames; frames contain detected objects; objects carry confidence scores, types, classes and labels. Relationships between those levels are part of the data too. Counting files therefore gives a poor estimate of the analytical workload.
Petrov compares this density to a neutron star: roughly city-sized on the surface, yet more massive than the Sun. His illustrative data equivalent is 2,000 video files yielding millions of internal objects. The storage inventory looks small while the representation needed for analysis expands dramatically.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Turn metadata into rows without splitting the programming model
The first response is often to write metadata as JSON beside the images or videos in S3. As the extracted object count grows, this creates millions of small metadata files, with latency, efficiency and consistency problems. Moving the metadata into a centralized database improves the storage model, but can leave researchers managing two systems, two languages and two stacks.
| Approach | Metadata representation | Main consequence |
|---|---|---|
| JSON sidecars | Files beside the binaries | Many small reads and consistency work |
| Separate database stack | Centralized metadata records | Researchers manage a second programming environment |
| Pydantic plus Python-to-SQL translation | Typed Python schemas backed by rows | Schemas and processing stay in Python |
Pydantic supplies the common language for schemas and code. Python expressions can then be translated into SQL, keeping the database’s query capabilities without scattering separate SQL islands through the codebase.
This solves a particular boundary problem: extracting structure from physical binaries so ordinary analytical tools can operate on it. A business dataset that already lives in warehouse tables starts on the other side of that boundary.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Scope a dashcam analysis before spending compute
The demonstration uses open-source DataChain as a data harness for Claude Code. Setup proceeds in order:
- Install DataChain with
pip. - Install its skill for the selected coding agent.
- Launch the agent and describe the task.
Petrov says the integration also supports three other coding agents. He skips permission prompts to accelerate the demonstration; that is a demo choice, not a requirement of the architecture.
The task is motion analysis on an open dashcam-recording dataset. Video makes a useful example because it is common—and sometimes the dominant modality—in physical-AI projects, while still exposing the difficulty of turning a binary recording into useful observations.
Before processing, the harness asks questions that determine both cost and output shape:
- Detection model: It proposes YOLO, and Petrov selects the smallest model size.
- Velocity estimation: He selects the simplest available method; an alternative would take more compute time.
- Granularity: He chooses per-frame output rather than per-track output.
- Scope: He keeps the January subset of 91 clips and declines the offer to expand it.
These choices establish what the resulting dataset will mean before the expensive work begins.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Pay for extraction, then query the result
Petrov reports that analyzing roughly 90 videos took 24 minutes. With processing complete, he asks how many videos contain people. The demonstration returns people detected in 82 of 91 clips. These are results from the selected dashcam task; the recording does not establish a reproducible hardware configuration for the timing.
The answer comes from the local database, not another pass over the videos or a download-and-parse loop through JSON sidecars. The generated Python loads the dataset, filters for the person label, counts the relevant clips and compares that count with the total. The expensive perception step has already produced the information needed for the analytical question.
Petrov reports that roughly 90 videos generated about 100,000 records. This is the hidden density made visible. He projects that thousands of videos can reach millions of records, and that deeper analysis of objects can multiply the count by ten, twenty or even hundreds. Those projections describe how the representation can expand, rather than additional measured runs.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The data model connects detections to their source
Inspecting the generated code reveals the central artifact: a Pydantic model derived from the task requirements. A detection carries its video file, frame ID, timestamp, class ID, confidence and bounding box. The class identifies a person, car or another object; the bounding box is itself a nested structure.
The file is also structured data. It carries a path, size and available storage metadata such as checksums, version information and an ETag. Those fields should remain distinct: an S3 ETag is not universally a whole-object MD5 checksum, particularly for multipart uploads. A compact Python representation of the described fields is:
python
from pydantic import BaseModel
class FileRecord(BaseModel):
path: str
size: int
checksum: str | None = None
version_id: str | None = None
etag: str | None = None
class BoundingBox(BaseModel):
x1: float
y1: float
x2: float
y2: float
class Detection(BaseModel):
file: FileRecord
frame_id: int
timestamp: float
class_id: int
label: str
confidence: float
bbox: BoundingBox
The nested Python object becomes queryable database data rather than another JSON file in S3.
Once these fields are rows, familiar analytical operations apply: filter labels, group observations, count matching clips and relate results back to source files. The binary remains in storage; its extracted meaning becomes structured data. That separation is what makes repeated questions inexpensive relative to repeated perception.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Connect typed Python to distributed execution
Schemas reveal what is inside the files and how large the problem is. Processing terabytes still requires an execution engine. It must use resources efficiently, account for potentially expensive LLM calls and preserve completed work when a job fails. A structured-data warehouse already provides an execution engine; an unstructured-data system needs to supply that capability around its files.
Teams may assemble orchestration and distributed compute with Ray or Spark. Petrov particularly likes Dask’s model of connecting computation to structured data. His corresponding design for physical data joins Python functions, Pydantic input and output schemas, metadata in a warehouse, and files in object storage. Together, these give the engine the information needed to distribute work across machines or threads according to the files being processed and the schemas being produced.
At the processing boundary, a file from S3 becomes a collection of detection objects destined for the warehouse. The user writes an ordinary typed Python function that yields those objects. Petrov’s point about avoiding extra function annotations is that no special execution decorator is needed: the specified input and output types still matter. The engine connects storage, execution and persistence around that function.
Resource allocation belongs outside the detection logic. Petrov illustrates the intended simplicity by asking to run on 40 machines. The saved configuration visible in the demonstration instead shows parallel=4 and workers=30; it is a configuration example, not evidence of a completed 40-machine run.
| Function shape | Output per input file | Use |
|---|---|---|
| Mapper | One object | A file-level result |
| Generator | Multiple objects | Detections within a file |
The pipeline applies the function and saves its output as a named dataset—a database table underneath. In the visible code, detection generation feeds the persisted dashcam-jan dataset.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A failed run should not erase completed work
Processing heavy files can take a long time, especially when understanding their contents requires LLM calls. If a bug or API failure interrupts a run over hundreds of thousands of files, restarting everything discards both time and money. Repeating that failure compounds the waste.
Checkpointing and incremental processing preserve different kinds of work. Checkpoints let a repaired run recover completed results. Incremental processing lets a later run handle newly arrived files without recomputing existing outputs. Petrov describes both as essential. Current DataChain examples make the operational boundary explicit: recovery retains committed batches, an uncommitted batch may repeat, and the incremental example enables delta=True. A rerun therefore needs the appropriate recovery or delta configuration; merely invoking a script again is not a guarantee of zero repeated computation.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Give the agent a cheap way to check its answers
Coding agents use tests both for quality control and to reason about the environment. These are the harness’s hands: a way to touch the system and check what happened. Data work needs that feedback too, but a test that repeatedly processes raw videos can be prohibitively slow. Petrov draws on Anthropic’s distinction between software tasks with many acceptable implementations and data questions that usually have one correct answer.
The first improvement is to stop treating every question as a new Python computation over raw binaries. Build metadata datasets around the raw data so the relevant questions can be answered quickly. Dimensional and multidimensional modeling, star schemas and the one-big-table approach offer established ways to organize that layer. The choice of layout serves the same purpose: make the next analytical operation cheap enough to support iteration.
The harness changes the agent’s procedure before it answers:
- Check whether existing datasets contain the metadata needed for a single SQL-like query.
- If the metadata is missing, build the necessary layer.
- Make that layer broad enough to answer related questions, rather than only the current wording.
- Retain it for the user and teammates to reuse.
This turns a question into an opportunity to improve the data representation. Future checks can operate on the accumulated metadata instead of repeatedly paying for extraction.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Remember why a dataset exists, not just its name
Once useful slices exist, they can answer questions without rerunning expensive compute. But that saving disappears if another person or agent cannot discover them. Petrov describes teams paying twice, three times or four times for the same analysis. Coding agents such as Copilot, Codex and PI already use source-code context and indexes; a data harness needs comparable memory of the data work already performed.
A dataset name alone is insufficient. Memory should preserve why the dataset was built, the session context that motivated it and a useful description, often enriched by an LLM. It should also retain the producing source code, whose importance Petrov connects to OpenAI’s data-agent work. The knowledge base must expose this information to both agents and people. In the demonstration, it takes the straightforward form of Markdown files.
The record for the newly created dataset includes:
- Description and rationale: What the dataset contains and why the conversation led to its creation.
- Storage dependencies: The source storage location and directory.
- Preview and schema: Sample data and its structure.
- Statistics and source code: A sense of the dataset’s contents and the program that produced it.
The code is especially valuable because it explains the transformation, not merely the resulting column names.
These records connect source data in the bucket, producing code in the knowledge base and results in the warehouse into data lineage. Sharing that knowledge makes the existing dataset—and the resources already spent creating it—discoverable to teammates. Petrov’s intended behavior is that a later question about the same directory uses a suitable existing result instead of launching the extraction again. The harness’s memory therefore changes the next execution decision, not just the documentation available afterward.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Build the stack around the cost of physical data
The complete stack begins with the mass of unstructured files in object storage. A compute engine performs expensive extraction, including LLM calls where needed. A Dataset DB organizes the resulting metadata into datasets and useful slices. A knowledge base makes those results and their context available for reuse. Each layer makes the work beneath it more accessible without requiring that work to be repeated for every question.
Copilot, Codex and Claude Code can generate the processing code, but their default habits do not necessarily account for the cost and density of physical data. Petrov’s closing prescription is therefore not simply to choose a stronger model: teams are already using frontier models. The missing capability is a harness that understands these constraints and supplies the surrounding data system. DataChain implements some of those principles as an open-source project. Giving an agent that infrastructure is what Petrov means by adding mass to it: the ability to build on data work already done.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Anthropic's internal analytics architecture, including curated skills, semantic definitions, evaluation and maintenance.
Six context layers combining table usage, human annotations, code enrichment, institutional knowledge, memory and runtime inspection.
Open-source Python library for typed datasets over object storage, with installation instructions and processing examples.
Further reading
- DataChain as a data harnessDocumentation
Maps coding-agent context and memory onto persistent datasets and a shared data knowledge base.
- Amazon S3 checksums and ETagsDocumentation
Explains object integrity checks and when an ETag does or does not represent a whole-object MD5 digest.
Updates since the talk
Current guides to DataChain's processing engine, dataset database and agent integrations.
Read the complete timestamped transcript
- 0:02
How coding agent work with physical data? Video recordings, sensor data, robot telemetry, and sometimes all of those combined in a single multimodal 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, uh, behind the problems and how to fix it.
- 0:30
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, uh, accuracy, uh, for data projects on their agents is only twenty-one percent until you add specific data harnesses to them
- 0:55
and provide context. OpenAI published a whole layers of context, six layers of context in order to make the a... data agent work. And all of those are on structured data which lives in a very houses with tables, execution engine, and all this like luxury.
- 1:20
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.
- 1:32
Uh, I've worked with data for about ten years. Uh, I built, uh, data version control project, Git4data, and now work on DataChain.
- 1:45
In order to make agent 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, uh, to-- for agents to understand this physical world.
- 2:08
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, im- important result, so this information could be reused, uh, in the future project.
- 2:32
And the first we start from the how you see data. Uh, what does it take to understand all these complicated binary file that you have in your object storages?
- 2:47
Uh, in reality, how it usually looks, uh, there are just a several files, sometimes several thousand of files, right? It doesn't seems like a big deal, right? But what is usually happens, those files are very complex inside.
- 3:04
That what makes unstructured multimodal data complicated. And from two thou-- uh, because video recordings might have clips inside. Clips might have frames. Frames, objects. Objects, confident, type, class, label.
- 3:23
Uh, there's connection between those pieces together. It makes kind of like explosion. It's-- it, it looks like a neutron star.
- 3:34
It small size on the surface, right? It's just a size of, uh, one city, but the mass of this object is tremendous. It's more than the mass of our sun.
- 3:45
Uh, and one... two thousand objects, two thousand files of videos could easily generate you millions of object inside the videos.
- 3:56
And how people usually do deal with these problems? They usually go through like a two major steps. First step,
- 4:04
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.
- 4:18
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 met- metadata is, uh, in there.
- 4:33
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
- 4:44
useless for most of the researchers because they don't wanna deal with this complexity.
- 4:51
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.
- 5:03
Uh, there are no SQL island in your code base. So in, uh, that way, you kind of transition from the messy world of unstructured data to the structure. The only thing you need is just like transpilers to the SQL, uh, from, from Python, and I'll show you, uh, how it works.
- 5:23
But that's the way when you can create schemas, uh, and work with the schemas efficiently. I wanna emphasize that the problem we are solving here is very specific for unstructured data, physical data.
- 5:36
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, uh, binaries and such.
- 5:52
Let's see how it works. I will be showing you our open source project DataChain, uh, with, uh, data harness to coding agents So first you need to install the tool, right, using pip install.
- 6:08
So we have already done this. Then, uh, Skill needs to be installed. So you
- 6:17
choose the coding tool that you use. We will be using Cloud Code, uh, but we support three more different, uh, coding agents. And then you run
- 6:33
your favorite code in coding agents. Uh, of course, we are skipping permissions, uh, just to make it faster, right?
- 6:41
And then you define the prompt and just solve your problem. So in this case, we will be analyzing, uh, motions, uh, in, uh, video cameras. Uh, that's, uh, open dataset from, um,
- 6:58
uh, dashcam recordings. Uh, video, it's a very usual use case for, uh, physical AI projects. Uh, majority of the project do, uh, do include, uh, video recordings, uh, as, uh, one of the modalities, sometimes the major modalities.
- 7:16
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.
- 7:29
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.
- 7:43
So let's use the smallest one. Uh, we need to
- 7:49
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, or will require more time
- 8:06
for the compute and granularity. So per detection frame, per track. Uh, let's do just per frame in this case and the dataset itself. So we ask for January data, right?
- 8:23
Ninety-one 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.
- 8:39
So it took us twenty-four minutes to analyze those, uh, ninety videos, and now we have all the information. We can ask, uh, questions about this. For example, [keyboard clicking]
- 8:54
how many, um, videos have people in it?
- 9:15
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, ninety-two, uh, oh, eighty-two out of ninety-one clips have some people, uh, detected, right?
- 9:38
And, uh, you don't need to kind of go through all the JSON files and download and analyze and parse, right? Information is here in the local database. It can easily, uh, quickly an-answer the question.
- 9:55
Uh, we can even see the, um, source code. [keyboard clicking]
- 10:12
Okay, just an easy, nice, uh, Python code, uh, to get, uh, get data, get data- dataset, right? Analyze, uh, apply some, uh, simple filters, uh, when label is equal to person, uh, count the number, right?
- 10:34
And then see the total, total number. And it goes like, uh, it runs against database, so super fast. So how big is, uh... How many
- 10:47
records do we have here? Uh, so that's about the size of our, uh, neutron star, right? It's not supposed to be big because we analyzed only like ninety videos and ninety videos generated one hundred thousands of records, right?
- 11:06
So that's how explosion is happening. Uh, if you analyze, uh, thousands of videos, right, uh, it goes to like a million, uh, million scale. And if you go to deeper to the objects, uh, it can easily do, uh, it can easily be multiplied by ten, twenty, even hundreds. [keyboard clicking]
- 11:32
Let's take a look at the source code.
- 11:37
This code was generated by the agents, uh, power agents using the harness. Uh,
- 11:46
the magic part here is the data model. So this data class, uh, that was generated based on our requirements and, uh, it's just a Pydantic, uh, usual Pydantic data model, uh, with a file, uh, right, the video file, uh- Frame ID, timestamp, uh, class ID.
- 12:10
That's how you know if it's a person or car or some object, confidence score, bounding box. There are 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, uh, several columns, but files is more interesting one.
- 12:31
Uh, file has, uh, path and the checksums, like a version of the file, ETag, size of the file. So everything that your cloud storage providers provides for you. Uh, and this information is just, uh, become a row in a database, uh, instead of a JSON file in S3.
- 12:55
Uh, that's why you can easily, uh, answer, uh, all the questions, uh, all the analytical questions, right? Like before, we ask 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.
- 13:18
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 us- using rec- regular analytical, uh, tools and, uh, tool tricks.
- 13:39
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 wh- when we, when we deal with the terabytes of this messy data?
- 13:54
You do know that, uh, data harness have to have execution engine in order to deal with, uh, physical data. It has to work efficiently. Sometimes it spent a lot of resources a- and tokens, uh, if you use LLMs, and if it breaks somewhere in the middle, so you should be able
- 14:18
to recover and catch up with all the result that it's already processed, so you don't wanna waste your resources. In the SQL world, structured data world, execution engine is your data warehouse, right?
- 14:31
That's obvious and easy. In unstructured data world, you have to reinvent one.
- 14:38
And in some teams, they use different types of orchestration tools or distributed compute on Ray or Spark. I like model of Dask, which, uh, connects a compute with the data, structured data.
- 14:54
Uh, but unstructured data needs its kind of like own approach, uh, when you connect the Python and schemas with the execution engine.
- 15:07
To simplify it, you can connect those Python functions, Pydantic schemas, input sc-- 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.
- 15:30
And that's wh-- this way it will be more s- 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 far and so on.
- 15:47
It's kind of like a Dask approach, if you wish, but for unstructured data world.
- 15:54
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.
- 16:14
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?
- 16:30
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?
- 16:44
We don't even use like annotation for the function. It's just a function with the 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?
- 17:08
That's how you define the parallel, uh, parallelization layer. You can say, [keyboard clicking]
- 17:17
uh, I just need to run it in 40 machines, right? That's how easy it's supposed to be for resources to run like distributed compute, right? You just spec-specify how many resources you need, so you got it.
- 17:29
And the function itself, right? So we just use it, uh, run it through a generator, or it can be like mapper with one-to-one function. One function, uh, one file, it returns like one object to the database or generator one function, it returns like multiple objects in database.
- 17:45
And it is saved as a, like, dataset, right? Uh, a table under the hood, uh, in your, uh, database.
- 18:01
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.
- 18:15
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 wanna execute everything from scratch, right?
- 18:33
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.
- 18:54
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 compute only without recomputing the, the other stuff.
- 19:10
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.
- 19:23
It's kind of like a hands of your agents, hands of your, uh, uh, harness. In data, running test is super slow process. And how to do this because quality and accuracy of the questions is even more important than the data question, uh, data projects compared to software projects.
- 19:46
Uh, as Anthropic put it in the 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.
- 20:06
How to answer questions very fast on your
- 20:13
binary data mess. 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.
- 20:25
Instead, you need to organize layer of meta information, all the like datasets, uh, or tables around this, uh, raw data, uh, that could answer these questions very quickly. And this is something that data industry knows for like a dozens of years.
- 20:41
It's a dimensional, multidimensional data modeling, uh, star schemas, one big table approach, and all these like fancy theories around, around this. And we need to use this more in order to make our unstructured massive data processing, uh, to be more efficient.
- 21:01
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 datasets, proper metadata to answer this question quickly in a single like SQL-ish query?"
- 21:23
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 ask.
- 21:38
And that's where you are building these layers and layers of information that's, uh, could be reused by you and your teammates.
- 21:50
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 reruning, re-running expensive compute.
- 22:08
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 nitro 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
- 22:32
stuff. And coding agent as well as data agent doing this, uh, 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.
- 22:56
Uh, on the data harness, you need to build and provide this context, uh, to your agents.
- 23:06
And that's not only the fact that, hey, there is a dataset, you need to provide a lot more information with this. Uh, why this dataset was built kind of like a context from the session, uh, description of the dataset which usually enriched by LLMs.
- 23:23
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 explosed, 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
- 23:46
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, in my directory, but when I get more datasets.
- 24:03
So the dataset that we created, that one,
- 24:08
uh, this is the MD file. Uh, so description of the dataset, right? The session context, uh, so why this dataset was created based on the discussion. Dependency to the storage, to the directory that we pointed, uh, to in the beginning.
- 24:27
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.
- 24:42
Uh, as we discussed, the most crucial part, uh, to understand, uh, what is data is about.
- 24:52
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,
- 25:06
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.
- 25:25
So next time, if someone asks 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 you already-- that you have already spent, right?
- 25:42
That's the magic of the, uh, data harnesses when agent knows everything about your data.
- 25:52
Let's put all the pieces together in a single stack.
- 25:58
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 LLM calls to extract some meta information through the compute engine and organize this meta information in a data sets, in a data
- 26:23
set slices through the some, uh, Dataset DB. Knowledge base is a way how you share this information.
- 26:34
This is a world when your favorite coding agents, such as CodePilot, Codex, Cloud Code,
- 26:42
do not operate efficiently. Their intuition pushes them in the wrong direction because laws of physics changes.
- 26:54
And in order to make it, you don't use stronger models. Everyone use frontiers. Instead, instead, you are building data harness, data harness that understand the laws of this physical data, and that's a way how to make your favorite coding agent efficient with these problems.
- 27:18
We implement some of those principles in DataChain project, which is open source. So please check it out and put some mass on your agent. Thank you.