Webinar transcript: Fix your data, fix your AI

This is the full transcript of the webinar Fix your data, fix your AI, recorded on 8 September 2026, with Alan Jacobson, Founder, Advisor & ex-CDAO at Alteryx, and Flexor founder Or Zabludowski. You can watch the recording here.

[00:00:00] Alan Jacobson: All right. Welcome, everybody. Really excited to have you guys all on today. We’ve got a great session for you, where we’re going to talk about the pipelines that make data work with AI. I’ve got with me an all-star expert in this space, Or Zabludowski. My name is Alan Jacobson, and I’m going to host you this morning.

[00:00:23] We’re going to start with a little bit about how AI fundamentally needs data prepared properly to get the right results. We’ll then show you a demo of what it looks like to do the right preparation and to not do the right preparation. We’ve got a Q&A button that you can hit to ask any questions you have. Feel free to ask questions as we’re going along, and we hope to be able to either answer you in the chat or answer live in the session.

[00:01:02] So with that said, the agenda today: we’re going to talk a little bit about why this approach is really important, and what data preparation in a modern AI world looks like. We’re going to do a live demo. That’s always fun, and it’s probably going to be my favorite part of the entire session. And then we’ll talk a little bit about how people are using this technology in the real world.

[00:01:20] So first, I want to step back and talk a little bit about how we, as humans, process data and prepare data before we use the thing between our ears, our AI, our brain, to answer questions.

[00:01:33] I want you to pretend you’re going to take an exam. I give you a sheet of paper and ask you to study it, and then I’m going to ask you some questions about what’s on the sheet of paper. How you might go about that might be reading it once, maybe twice, maybe you highlight an item or two. That’s about it. Not a lot of preparation. And then you go in and you take the exam, and you probably do pretty well.

[00:02:09] But what happens when the data is a little bit larger than that? What happens if, for the exam, I give you an entire book? With that book, you’re probably not only going to highlight sections, you’re going to start tabbing things, basically creating an index of what’s in it. You might write some summaries. You’re going to do a little bit of preparation. And if I measure you on the exam not only on whether you get the answer right, but on how long it takes you to get an answer, the level of preparation you’re going to do so that you can really quickly get to the right answer and make sure you get it right, that preparation is going to take you a while.

[00:02:44] These are the same techniques that you use in an AI world so that a computer can basically replicate that process. Building indexes and knowledge graphs and summaries of the information becomes really, really important.

[00:02:59] And if you go from this book to something much, much larger, now picture that you have access to the entire library. Again, the amount of preparation you need to do to be able to do well on that test goes up significantly. So if your company has a lot of documents and you want to be able to ask questions of those documents and get accurate answers, this is going to become something that’s really important.

[00:03:24] And so I’m going to shift now and bring on Or. He’s going to show you a little bit about what it looks like to do that preparation, not manually, but in an automated way, using even AI to help do that data preparation, so that when you feed it into a foundational model you get much better results.

[00:03:48] Or, welcome. Let’s have you do a little demonstration of what good data preparation looks like versus just feeding data into a foundational model.

[00:04:01] Or Zabludowski: Yeah, so thank you, Alan, and good morning, everyone. I’m going to share my screen and show you a little live demo. Sticking with Alan’s analogy about test preparation: what it takes to get ready for a test when you have to prepare an entire library starts with how you prepare for a test on a book. So the first demonstration we’re going to show you during this webinar is how we do that at the single data point level.

[00:04:32] What you see here is a little demonstration environment that we’ve prepared just for that, and this environment is loaded with a single document. It’s a document by Vanguard called How America Saves. It’s a yearly report they publish about how America saves.

[00:04:49] And this is not a simple PDF file. When you start inspecting it, you find out that How America Saves is a 112-page document. It’s like a short book, but it’s also a highly technical book, because it contains a lot of domain know-how and a lot of references.

[00:05:11] So we have this whole table of contents, and you start seeing tables, and these tables start referencing each other. Page 36 relates to figure 46, which has a few figures that have a little asterisk saying the data is relevant for 24 and not relevant for 25. It turns out that this table is a continuation of another table, so we probably need to read them both together to get the right answers.

[00:05:39] And as we keep scrolling, we see everything that is complex in a PDF. You’ll see numbers in figures, you’ll see internal references pointing at different pages, and then we start seeing charts, many charts, all kinds of charts: bar charts, tables and bar charts, referencing each other, defining new metrics.

[00:06:03] In short, this is a book that requires quite some preparation to do well. Now, if you use the world’s best frontier models and you just load this PDF, you’ll get really good answers right out of the box. But if you try to read this book 10,000 times for different chapters, just to make sure that your enterprise workflows can rely on it, let’s say it’s an SOP or an MSA that you’re trying to analyze, this becomes a big task.

[00:06:28] Now let’s go to our little agent runner. This is what happens when you go to your software engineers and tell them, “Hey, can you please AI this single document for me?” Not a library, just a single document. Let’s see what happens when you run data preparation well.

[00:06:43] Our first scenario is RAG, retrieval augmented generation, the go-to method to answer AI questions on documents. We picked Gemini and we did it with some standard chunking technique. I ran the Flexor one first, so let’s rerun that real quick.

[00:07:06] What you’re going to see here is how long it takes to get an answer and how many tokens are being used. So here, I know the document, and I know that the figures for the average and mean account balances by American households in 2024 are indeed $148,000 and $88,000 respectively. We waited 7.4 seconds and spent 18,000 tokens.

[00:07:34] Now let’s see what happens when you rely on data preparation that actually read the book before answering the questions. I switched to Flexor’s contextual chunking, which is an engine that breaks down the documents and chunks them in a way that understands the meaning. What you will see is that we’re going to get the exact same answer, but for one ninth of the tokens, in just six seconds.

[00:07:58] And if we try to push the technology to its limit and provide it with the minimal amount of context you can to answer the question, and cross fingers to get the right answer, you’ll see that we’re getting the right answer. It took us 4 seconds and only 308 tokens.

[00:08:26] If we did the same thing with standard chunking, you’ll see that we sometimes don’t even get the right answer. Reading the book in advance helps you a lot. In that case, it wasn’t able to find the answer, and it cost us 5,000 tokens.

[00:08:39] So this is just a teaser of what it means when you read a book, and at the end of the demo we’re going to talk about what it means to read an entire library, an enterprise library. But for that sake, I want to show you a little real-world example. Alan, just making sure that everyone can see my screen here.

[00:09:03] Alan Jacobson: Yes, excellent. Perfect.

[00:09:07] Or Zabludowski: Moving on to the new slides. Okay, so let’s talk about the real-world use case, just to align on what it means to do AI in the enterprise nowadays. Document question answering is no longer the real-world use case. It was fun in 2024, but now the expectations from AI are much larger than that. We want AI to complete full enterprise tasks on our behalf.

[00:09:29] So let’s talk about the mining industry. In mining, every day is a test for field engineers. Field engineers are the teams that run and make sure the entire plant is running and producing as expected. And every day is a surprise, because you have equipment failures, and you have maintenance needs and production issues and safety incidents, and these field engineers have to handle them all, from zero to hundreds.

[00:09:56] But this is not a simple task, because you need to master the engineering aspects. You need to know all of the systems and functions. And also, in big businesses, you have many different plants, and they were not designed the same way, because reality is complex and very nuanced.

[00:10:12] Now, we want these engineers to score 10 out of 10 in every test, but it’s not simple, because they need to make decisions under pressure. They need to recall things from memory. They work under constant uncertainty. And the biggest thing is that they have a lot of missing or misleading information, because in the real world you don’t stop to document all your information every single time you make a step.

[00:10:37] But this looks like the perfect scenario for AI, because the field engineer needs to integrate a lot of information. They’re in the field, and they need to understand the production metrics, and they need the logbooks to know what happened, and they need the daily plan to know what’s going to happen today, but also the manuals and the plant diagrams and the incident history and the SOPs, because they need to operate.

[00:11:06] How amazing would it be if they just had an AI brain that could connect all this knowledge and all this stream of information and just co-work together with a human to make sure that they make the right decision every single time? It’s huge memory, it’s fast retrieval, it’s accurate reasoning, and also the ability to log every decision you made.

[00:11:24] That’s the big promise of AI in real-world enterprise scenarios. You get the incident solved faster, you get a better success rate, and that’s amazing for the business. And on top of that, if that incident returns five months later, you have a full log of what decisions you made based on what information, and that helps you create an amazing feedback loop that lets you improve over time.

[00:11:53] The thing is that when we encountered this exact scenario with a company and we tried to map what it takes to build this AI brain, this is what we found out. First of all, 17 terabytes of files are behind this beautiful knowledge graph. Thirty million operational emails reporting on progress and changes, modifications, plans and such, scattered across basically everywhere the enterprise has to offer. They have contradictions, versions, and facts from different dates written by different people. Nobody knows what’s reality.

[00:12:30] And there are multiple facilities that are very easy to confuse, nuanced domain terminology that confuses the frontier models, and overall 28 years of operational information. So the question is: how do you prepare for a test on this kind of information?

[00:12:50] And the answer is that you need to prepare, because you can’t analyze this vast amount of data every single time you ask a question.

[00:13:00] And this is the new paradigm that we strongly believe is going to change how enterprise AI is built. Luckily, we’re not alone in this. Working closely with companies like Snowflake, Databricks and Microsoft Fabric, we all share the same vision of having a central context hub for agents, and context not as the vague term, but context as a concentrated hub of information where agents can search, retrieve and reason consistently over a wide variety of enterprise tasks.

[00:13:40] So this is what it looks like. Frontier models can do a lot, but we don’t want them to do a lot, right? Because they’re expensive and they’re slow, and there’s no good reason to do that.

[00:13:52] So just like with every other engineering discipline in the past, when we had a very expensive resource that is very capable and we wanted to scale the usage of it, what we did is we started offloading tasks away to more optimized, more well-engineered components in the stack. And that’s what we call a shift left. We did it for security, we did it for development, and now it’s time for AI.

[00:14:14] We need a way to reduce query latency and token spend, and to make sure that results are consistent. And with that, we have all these compliance, provenance and lineage capabilities that we need in order to prove that the agent that made the decision did it based on the right information.

[00:14:36] And this shift-left architecture basically looks like this. Instead of the model integrating all of the information by itself, we take these two sides apart. We take multiple models, because that’s the reality now in the enterprise, nobody uses a single AI use case. We take the sources, and we find a nice place to insert a context engine.

[00:14:58] The context engine doesn’t organize all the information. It does very pragmatic, very technical tasks that we all know contribute to tasks of information retrieval. It will index information, it will cache it for faster retrieval, it will build context in advance. So when you ask a question about the Vanguard document, you don’t have to read the entire document. It already knows where to look for information. It optimizes tokens, and it supports model routing to make sure that hard problems get powerful models and simple problems get faster, more efficient models.

[00:15:35] And in order to make that happen, we built a pipeline that supports exactly that.

[00:15:44] Now, I want to stop for a second and just ask you a few questions, a few questions that we believe you should keep in mind when you’re planning your AI architecture. These highlight whether you’re at the right scale for optimization, whether you have the distribution of use cases that justifies it, or whether you’re at a sweet spot, because sometimes smaller scale and specific use cases don’t need much optimization.

[00:16:12] If you’re doing any PDF processing, you should ask yourself: how many times does your team end up paying multiple times for AI tokens to extract the same PDF? Sometimes it happens very explicitly, for example when you run through a PDF processing pipeline. Sometimes it happens implicitly: it’s your employees taking all kinds of PDFs, loading them into Microsoft Copilot, running them through, and the PDF gets extracted. What if you could do this PDF extraction just one time and have the data stored in advance?

[00:16:50] The second one is: how much precious GPU and CPU time does your team waste waiting for MCPs to fetch data? I’ll give you a very tangible example. Say you’re trying to retrieve all of the company’s contracts for a compliance test. You want to do that using an agent, to make sure that all your contracts do not allow AI vendors to train models on your data. In order to do that, you need to make sure this AI system retrieves 100% of the contracts, because if you don’t review 100% of the contracts, you cannot know that you are fully compliant.

[00:17:31] Now, the moment you start running that using MCP, these MCP endpoints are going to approach all kinds of services. They’re going to pull information from SharePoint and from Google Drive and from some mailboxes, and all these API calls take a lot of time. What if you could ingest this data in advance to make sure that retrieval happens at data platform speed, subsecond queries to retrieve hundreds of millions of rows?

[00:18:00] What percentage of your agent answers are backed by real data? Do you have any AI explainability at all? And that’s a very simple case to test. Look at the results. Look at the lineage behind them. Can you trace back the original data point that was responsible for the answer?

[00:18:21] You don’t need that for some simple use cases, that’s fine. But if you need it for mission-critical use cases, for legal, for compliance, for decision making, ask yourself: do I have the ability to reach the original data points?

[00:18:39] And when the original data points change, like Google Drive docs, like CRM notes that can be edited, do we have any audit of the different versions of the data that were used by the models? If the answer is no, you should be concerned about that, and think about how you timestamp and sign all these data points before they get to the models.

[00:19:01] There are also round trips, and we didn’t even talk about accuracy. So these are very technical and very easy questions to ask about your data.

[00:19:15] Now, when you do proper exam preparation, you change the economics of this equation. First of all, when you process once, you don’t have double spend anymore. Instead of 15% of your employees processing the HR policy at least once this year, you pre-process it once and give them an easy answer, instead of paying for that PDF extraction maybe 15,000 times. And that can be a long policy.

[00:19:44] When you generate content-based metadata in order to create indexes, you gain two benefits. The first one is that it’s faster and cheaper: you think in advance about what information you want to extract from the data, and you get the benefits. But you also get the ability to govern the data.

[00:20:04] One of the biggest challenges with unstructured data for agents is that you give access to SharePoint, you give access to Salesforce, a lot of emails and notes and files, but nobody read them in the past. So you just let the agents discover what’s inside, and that can create some serious governance and information leakage issues. So when you force your pre-processing engine to read through these documents, you can identify sensitive information that should not be accessible to AI models.

[00:20:38] And the last piece, and that’s where the library use case kicks in, is creating deep linking. Imagine that you go to the library. Now, it’s not an organized library, it’s the enterprise library. It’s basically people throwing books around for 25 years. And you start reading about chemistry, and then you find out that in order to understand one of the concepts in chemistry, you need to go read a physics book. Where is this physics book? Which one should I read? Which one is the best one? And then you realize that you need to go and read some experiment data. Where is the experiment data? Is it even in the library? So all these questions need answers. And when you do data preparation in advance, you can answer them in advance, instead of relying on each of your models to try and figure it out live.

[00:21:32] And the real test for that, and this is pretty big news for Flexor and for the industry in general, is a benchmark that was released quite recently, called Enterprise RAG Bench. Enterprise RAG Bench is actually the first ever real benchmark for enterprise tasks.

[00:21:54] The reason I’m saying that is that nobody measures a business on how well they answer questions on a single document, right? Because if I answer questions amazingly on the HR policy of two years ago, I provide the wrong answers very well. And also, nobody measures businesses on how well they extract their PDFs. It’s great that you can get the accurate information out of them, but do you even process the right documents? Can you tell that the contract you just extracted has three amendments lying around somewhere in the enterprise that contain new information about how to interpret the document? So all these semi-technical benchmarks are great, but they don’t give you the sense of whether a system can solve a real-world use case.

[00:22:45] And Enterprise RAG does it differently. It’s over 500,000 data points from different real enterprise sources that connect documents and live communications. So we have emails and transcripts and documents and Jira tickets, Slack channels and more. And on top of that, the benchmark contains 500 complex questions. Some of these questions don’t even have an answer in the data, which is a real-world scenario. It sometimes happens.

[00:23:19] And what we saw is that the best performing models scored an overall score of 80. Eighty is not a lot. Eighty is not enough for mission-critical use cases. On the hard questions, you can see that the best in the benchmark was able to answer 50% of the questions. That’s a tiny amount. The average participant in the benchmark was able to answer between 13% and 15% of the questions. That’s quite miserable.

[00:23:49] And what you see here is Flexor’s preliminary results on the benchmark, placing us at an average score of 87 currently, which is 7 points above the best performing player right now. And we expect to score over 90, and over 95, within the next couple of weeks, with a few improvements that we’re introducing to the platform.

[00:24:15] And that completely changes how you look at enterprise tasks. The reason I’m saying that is that when you evaluate the complexity of your use cases, when you evaluate the right architecture for your solutions, these are the things you need to take into account. Do I have a lot of data? Is it diverse data? Do I have contradicting facts, or is it all well organized, which happens in some use cases? And the last question is: do I want to compose the architecture step by step, or get an end-to-end pipeline that provides my agents with the ability to answer the questions?

[00:24:54] And the way that magic happens, or how you score 87 and soon 95 in one of the most complex benchmarks around, starts with building, guess what, data pipelines. And Alan, I think that we named this webinar “Fix your data, fix your AI,” right?

[00:25:15] Alan Jacobson: Yep.

[00:25:16] Or Zabludowski: That’s the original title. And the reason is exactly what Alan said at the beginning. I think we saw that happen in all kinds of data scenarios in the past, right? We saw that before for machine learning. We saw that for data engineering and reporting. Alan, if you want to give the perspective before I dive into some architecture.

[00:25:37] Alan Jacobson: Yeah, I think actually I’ll go back to the results that you showed relative to this architecture. You were comparing running Flexor to other RAG engines, basically trying to execute this architecture, preparing the data for the foundational model runs. But I think it’s important that people understand that if you didn’t do any preparation, if you just ran the foundational model, which is really not what was in these scores, it would actually struggle even more.

[00:26:07] And so the importance of doing this preparatory work is tremendous. And then, if you set your teams to go do the preparatory work, there’s a large spread between doing it at a state-of-the-art level versus the beginner level of how to do that prep. So I think people are recognizing, RAG’s been around for a while, that doing this work is important, but doing it really well is really important. I see a lot of enterprises that aren’t even in this architecture. They’re just feeding the questions directly into an LLM.

[00:26:48] Or Zabludowski: So that’s a great segue, I think, to data preparation. Do your homework is an important principle, and it’s also important to understand what you see in a benchmark. We talked about single document benchmarks, we talked about PDF extraction benchmarks. I will say something very important about the enterprise one: all of the data provided in this benchmark was provided as markdown files. And that makes life very much easier for the tools that focus on retrieval.

[00:27:25] Now, if all these documents were PDFs, you’d start seeing all kinds of solutions struggling, because all of a sudden you can’t grep and search keywords inside the data unless you extracted it. And when you have emails, you’ll start seeing duplicate information repeating again and again, because in email, each email contains the quotes of all of the previous emails underneath it. And that puts the Enterprise RAG benchmark as a very powerful test for the ability to handle contradicting information, search, and all kinds of complex reasoning tasks on the data, not just question answering.

[00:28:09] Alan Jacobson: Yeah, and in addition to that, every time you would have asked one of these 500 questions, if you just fed it directly into a foundational model, it would have re-translated the PDF all over again. So you would have been re-reading and re-ingesting all of this data again.

[00:28:27] Or Zabludowski: And talking about shift left, you’ll talk with every engineer, every architect on your teams, and you’ll get the very intuitive answer: “Oh, that’s easy. Let’s build a caching mechanism. Let’s do some pre-processing. Let’s build an index.” And that’s exactly what it is all about. There is no new invention here. It’s just applying these engineering principles that have helped us throughout history, in car manufacturing and in data engineering and everywhere, to get better results. And the thing is that Flexor ACE packs them nicely as a unified pipeline, because there’s a big advantage in reading the data once.

[00:29:03] Let me walk you through it real quick before I show you another live demo of how it works in real life.

[00:29:15] The first thing you have to do, and the Enterprise RAG benchmark did this for us, is data preparation, which is extracting the contents of data points. You have a scanned PDF, you have an MBOX file containing a 500-gigabyte mailbox of one of your most senior employees. You can’t even search that. You need to extract that first. There are transcripts that sometimes need translation. You need to prepare the data. You need to bring it into a form that is easier for the downstream models to parse.

[00:29:47] Now, in order to do that, many times you have to use an LLM or an SLM, a small language model, to actually read through the data and do some cleanup. You see two email threads, and you want to make sure whether they’re duplicates or not. So you spend some LLM tokens on data preparation first.

[00:30:07] Then the second stage is to do some context building, just like you saw in the example of the Vanguard file. When we do preparation in advance and we link the right chunks, we get the benefit of faster, more accurate retrieval.

[00:30:22] Now, you have a lot of documents lying around, you run the Enterprise RAG task, and you let the model navigate and connect the dots. But a few of these LLMs already read the data. Could they somehow contribute to this work of doing data preparation? Could they save some time, some tokens, and enhance the accuracy of the model doing that later? Because they have almost infinite time, practically, to get the job done.

[00:30:52] So the answer is yes. Context building done in advance can help you link emails with their attachments that are really important to read together, and can help you identify contracts and their amendments. And the way to do that is to create content-based metadata: while the engines scan the data for preparation, they can start extracting information that will help agents navigate this ocean of half a million documents, or probably, in your reality, the ocean of half a billion, maybe 17 billion data points in some of the examples.

[00:31:28] So that’s context building. Now the last piece, going back to the example of the mining company, is domain intelligence. When you start reading through this data, you quickly find out how rich the universe of your enterprise language is. You have finance and legal, but you also have engineering of multiple disciplines. You have sales, you have product, and maybe in finance you have different disciplines of finance.

[00:31:56] And when you run an agent on these tasks, you basically expect the agent to understand all of these unique business lingos, but also to be consistent about them between runs and between versions. And if your Fable 5.1 agent spins up Haiku subagents that are smaller and not as smart, you also expect these subagents to understand the terminology in the same way. So creating a semantic layer for unstructured data, for the business terminology, proves to be useful.

[00:32:36] And when you do that, you can start writing glossaries, but you can also use the fact that you’re already reading through the data to start explaining through examples. And that’s what domain intelligence does. It actually mines the data as it reads it, identifies unique domain terminology, and connects it all together into a semantic layer for unstructured data. So Haiku and Fable share the same business definitions of each term.

[00:33:07] And that’s a shift left in architecture. Instead of loading all this work onto a powerful agent, we do it in advance. We take more time, we run multiple iterations, and we improve the quality.

[00:33:21] Now, something that completely changed our thinking about AI agents happened around a year ago, when agents were quite a new concept. We realized that while we were doing data preparation quite well, there’s another very important component, which is guiding the agent on how to get the work done.

[00:33:46] In 2025, we did it through prompting, right? We would prompt the model to do the exact task and follow the steps that we prepared. But now we have an agent that can navigate through different kinds of tasks, and this agent can navigate through different kinds of data sets. And we realized that providing a set of rules and guidelines for how to retrieve unstructured data is the missing piece in the puzzle. It’s great that you prepare your data in advance, but can you make sure that you also provide your agent with the handbook for how to get the job done the right way?

[00:34:24] And that’s MDP, Flexor’s Model Data Protocol. It’s an agent harness for unstructured data retrieval. This component sits between the agents and the data, and you can think of it as the delegate for unstructured data retrieval tasks. Whenever the agent needs to gather information that is textual, instead of trying to figure out by itself how to do that, it will delegate the task to MDP. It’s a skill and some tools that do a great job of navigating your data preparation universe.

[00:35:03] I think that’s a great point to stop and show you how these things work live. While I’m sharing my screen, Alan, if you have any more comments.

[00:35:14] Alan Jacobson: No, this is great. I can’t wait to see what you’ve got up your sleeve for your next demo. How much data are you going to process this time?

[00:35:25] Or Zabludowski: Yeah. We used to joke about big data, right, in the past. But nowadays I think we’re realizing that big data is the reality for unstructured data. You can’t avoid it by narrowing down your data or saving less data, because you can’t ignore the fact that if something in the business happens over emails, agents need to read the emails to get the full context.

[00:35:54] Alan Jacobson: That’s right.

[00:35:54] Or Zabludowski: You’re more than welcome to process it in advance to get better results. Okay, so let’s see what you see here.

[00:36:03] What I’m doing here is, first of all, what you see is Flexor’s ACE 2 platform, the one that ran the Enterprise RAG experiment. And we’re in the agent playground. Let me go full screen. This agent playground lets you connect what we call context agents, a concept I’ll explain in a moment, to powerful agentic models, and run questions. The purpose of it is just to make sure that you connect the data and your context the right way and get predictable answers. So this is not an agent-as-a-service kind of platform, but it lets you run tests.

[00:36:45] So we’re taking an SEC filings data set containing hundreds of pages of PDFs, 100 different SEC filings actually, and we’re going to run quite a straightforward task using Terra 5.6 on medium effort: list all of the companies mentioned in these filings, and I want the legal name and the ticker.

[00:37:13] And this is with no shift left.

[00:37:14] Alan Jacobson: With shift left?

[00:37:15] Or Zabludowski: Oh, sorry, this one is going to run with the shift left, and I’ll show you.

[00:37:17] Alan Jacobson: Yeah, just run it in the background so we can talk about other things in the meantime.

[00:37:18] Or Zabludowski: Yes. And what you see here is that we asked it, just like we instructed a regular agent, don’t use any formatting but a numbered list, and count how many were mentioned. So we’re going to run this agent in the background, and I’m going to quickly explain what a context engine is.

[00:37:40] Going back to our complex mining company task. It all starts with the reality that you need to connect multiple data sets in order to answer a simple enterprise question. If you just relied on your manuals but you ignored that there was some replacement part that got in, and the manual or the adjusted maintenance instructions show up in an email, you’re not going to get a real answer. And somebody will have to say, “Hey, I remember this email, let’s look up the emails too.”

[00:38:11] So context engines are the solution to that. They are a single endpoint that unifies multiple data sets. So you can tell your agent, “Hey, you’re our field engineering agent. These are all of the data sets you need access to, and you don’t get access to any other data set.” And that’s powerful from a governance perspective, but it also helps you optimize context on an ongoing basis for specific tasks that happen many times in the enterprise.

[00:38:43] So what you’ll do is create a context engine. You’ll select the data sets that you want accessible. These are the data sets that we prepared in advance. And once you do that, in a single click you get this unified agent endpoint. You can think of it as somewhat similar to data products in the structured data world. The data product for agents to answer the field engineering task combines emails and PDFs and Teams chats and activity logbooks.

[00:39:15] Now, behind that there are data sets. These data sets are the data that was prepared in advance, shifted left, so the agents can just consume it instead of extracting and preparing it. And I’ll show you a quick example, talking about our SEC filings here.

[00:39:36] While this data set loads, you’ll see that this data set is actually a table that shows up inside a data platform. We know how to govern tables. We know how to maintain tables. We know what the schema is. It’s not a vector store, it’s actually a table, an Iceberg table loaded into your platform. And this table contains 100 records. All of them are SEC filings, and one basically looks something like this.

[00:40:09] It’s a PDF that somebody needed to extract. You see, we have financial results. We have a decent amount of pages here, a lot of nuances. So that’s the data point. But in this table, it doesn’t show up as a PDF. It shows up as elements.

[00:40:33] You’re used to seeing JSONs for PDF extraction. Flexor does that end to end for you. It breaks every document down into elements, contains the contents, and also does the context building for you. With RAG, you need to decide on a chunking technique. Flexor connects these elements into context bundles: multiple elements go to a unified context ID. So instead of your agents trying to figure out where to connect the dots in this 112-page PDF, you just get that as an out-of-the-box data product available within your data platform.

[00:41:10] And to create context between data points, you have the references table. So this task of taking 17 terabytes of files becomes a very structured and unified task. You have data sets, they are mapped as tables, and they can connect to each other.

[00:41:29] On top of that, we’re creating structured metadata. And that’s ACE’s small language model pipelines, that let you create metadata based on your own use case. In this case, we’re doing some competitive intelligence analysis on our SEC filings. So we want to see if there’s any board movement. We create a pipeline that will efficiently scan hundreds of thousands of SEC filings just to identify the ones with an executive or board change.

[00:41:56] We’ll scan the data set for company tickers in advance. So instead of reading them one by one to find all of the company tickers, we just get that as an out-of-the-box structured answer. This is a useful guideline that shortens runtime, reduces token cost, and also increases accuracy. And we’ll also identify financial results and reporting of M&A. Creating structured metadata accelerates downstream use cases.

[00:42:29] Now we can get back to our agent that’s running in the background. You see the agent running here, and we can see it’s working. Let’s give it a few more seconds. It’s now scanning hundreds of files to try and identify every single piece of evidence of a data point.

[00:42:51] So let’s get back to our data sets. We have multiple data sets unified under a context engine, and all these data sets come directly from sources, so you don’t have to do any PDF processing in advance. You don’t have to do any email extraction or cleanup in advance. You just point the engine at a path in a bucket, and this path gets processed on a recurring basis for you.

[00:43:20] So no pipeline management, no scaling management. And this is all a single configuration process, instead of clicking through 50 or 70 different parameters for how to parse your PDFs, which you’ll see in all kinds of tools available. We took the approach that PDF optimization is usually not the job of an AI engineer. Email deduplication techniques, also not the job of an AI engineer.

[00:43:52] Can you just point and parse? Give us the path, we’ll analyze the data set, run testing automatically, and identify the best configuration to parse your PDFs. So this is what happens in the background.

[00:44:04] And the last piece, and I’d say one of the most important pieces, is this domain intelligence. We told you that an engine runs through the data, analyzes the content, and comes up with a vocabulary explaining how Flexor, or how the business, defines all kinds of terminologies.

[00:44:28] So all this gets into a domain intelligence hub. It contains the explanations of these terminologies, like XBRL, Extensible Business Reporting Language. This is the first time I’m seeing this term, so this term shows up in the data. And you see that not only does it explain it and give a full explanation of every term, it also gives examples of usage from the data. The idea here is pretty similar to few-shot learning, but it also helps subject matter experts audit that, curate that, and correct that.

[00:45:09] So let’s get back to our agent running in the background. Okay, we’ve got the list. We found 63 companies. That’s funny, because I told him to use bullet lists, and now, that’s Terra, that’s not Flexor, it decided to bullet 64 as the number of companies. But look how many companies and tickers we got.

[00:45:34] And this entire task took us close to 5 minutes, that’s it, and consumed just 9,000 output tokens and 700,000 input tokens. Now, the entire data set is almost 10 times bigger than that. We didn’t have to read the entire data set.

[00:45:54] Now let’s see what happens if we run the exact same query using RAG. Okay, so this RAG was also actually pre-processed by the Flexor engine, but the thing is that it doesn’t have the guidelines that MDP provides in order to produce the right answers. Same instruction, wrong engine, running in the background, doing a cold start.

[00:46:23] What do you think, Alan?

[00:46:25] Alan Jacobson: Something tells me it’s going to be a little faster. I think we’ll probably get the same answer, but I have a sense this is going to be an order of magnitude faster. And probably a lower token count.

[00:46:40] Or Zabludowski: Yeah, so what’s going to happen in RAG is that, first of all, if you compare it to raw RAG, it’s going to be so much faster, because it was chunked the right way. It’s going to consume fewer tokens. But what you’re going to see here is that, since we chose the RAG technique and not the agent mode, it’s going to provide us with a smaller subset of results. So here we got a total of 27.

[00:47:06] When you take RAG out of the box, you’ll get something between 1 and 14 results, because when checking the chunking strategies, the amount of company names that fit into the top 10 chunks doesn’t go beyond that. So RAG is inherently limited in its ability to retrieve the data.

[00:47:27] You do the data preparation right, you get much better results at better cost efficiency. You run an agent with MDP, you get the full data set results.

[00:47:37] And the very interesting thing here is that we hear people say, “Hey, you can do RAG with a few iterations, you can start navigating.” So basically you’re building your own retrieval strategies. You’re building techniques to help RAG filter out irrelevant results, and that’s building another retrieval system. And this is what we try to simplify into a one-click MDP endpoint that does that.

[00:48:08] I think we have ballpark 10 minutes left, and that’s time for Q&A. So thank you, everyone who stayed that far. I see that we have a decent amount of participants. Sahar?

[00:48:24] Sahar Dolev-Blitental: That was fantastic. And we do have a few questions already in the Q&A, but I’m inviting everyone to just drop your questions there and we’ll be happy to take them now, live. Or, I think we can drop the presentation and then we’ll see everyone. There we go.

[00:48:41] All right, so the first question is: what’s the difference between what you’ve shown here and other PDF parsers? Why shouldn’t I just go with a PDF parser to get my data ready?

[00:48:52] Or Zabludowski: Okay, so that’s an excellent question. First of all, let’s say you parse through a PDF perfectly, the right way, as you need it. There are a few other components you need in place for agents to utilize the data efficiently. That would be the caching mechanism and the index. If you just use a PDF parser, you have to build your own index, you have to set your own recurring pipelines, and that creates a lot of downstream tasks. When you do that on 100,000 documents, that’s a no-brainer. When you have an ongoing stream of tens of thousands of documents a day, that’s another story. When you have a store of 15 million documents that you need to handle, that’s another story.

[00:49:37] That’s part one. Part two is that there’s a huge difference between extracting the content of PDFs accurately, getting all the right words, and making the data ready for efficient agent consumption. And I’ll explain. Getting the right words when you have a document with a simple layout does most of the job. You have a Word document with paragraphs, that’s easy. Now you have a two-column document, and it has some illustrations and it has some references. It’s not enough to provide the data. You also need to provide reading order.

[00:50:14] But reading order isn’t just dependent on how you read the document. It also depends on the task at hand. So somebody, and I’m saying somebody because that can be your PDF parser, that can be your data engineers doing that, that can be your data scientists, but somebody needs to build the map of how to read the document the right way. So that’s another complexity that you have.

[00:50:39] And all of a sudden, even when you read the document the right way, it contains different references. Do you want to resolve them on the fly and let the model decide whether it wants to go and retrieve page 29 to get some extra information, or do you want to enforce that to get consistency?

[00:50:51] So we’re doing PDF extraction with an agent-first state of mind. The idea is to give agents the right tools to navigate huge document data sets and get the relevant answers. And the evidence for that is what’s happening in the ability to answer the very complex questions of the Enterprise RAG benchmark.

[00:51:18] Sahar Dolev-Blitental: Fantastic. And the second question is maybe a good one leading into that. The question is: for a company that’s not running agents yet, what are the biggest use cases you see for unstructured data that you can run today and couldn’t run two to three years ago?

[00:51:37] Or Zabludowski: So that’s another good question, because as agents come out, we’re all talking agents, agents, agents, forgetting that people still do reporting, because somebody needs to track the revenue numbers every morning and make sure that companies are on track.

[00:51:54] So agents right now, quite honestly, are at the very early beginning of their adoption curve. Many companies will declare having 15,000 agents in production. We talked with a few, and when you dive deeper you realize that they consider every skill that somebody wrote for the cloud setup personally as an agent. And when we were talking agents, we were talking about building the brain for the field engineering, not “read my email, write a summary, forward it to my manager.” That’s not the thing.

[00:52:31] So agents are quite early in the adoption curve, and still, we believe that within 12 months they’re going to be the number one consumer for unstructured data.

[00:52:45] That’s about the agent piece. Now, what’s outside of that? Documents, emails, calls, they’re all human-driven processes in the enterprise, and many of them have a lot of downstream tasks. You send a PO over email, and you get a response, and you get feedback, and you need to make corrections. And these things can be fully agentic if you want, but they can also start with reliable information extraction.

[00:53:16] Can I take all of my customer service calls and identify the product lines that they’re discussing, the kinds of problems they’re having, to inform product decision making? Yes. In order to do that, I need to prepare unstructured data, and I need pipelines that just do classification and information extraction. So the same pipelines that you saw for metadata extraction, like the M&A question, like the board movement question, can just be transformed into questions that help you do analytics and automation.

[00:53:41] You’re in insurance and you have a huge amount of claims streaming in, or you’re in healthcare and you have intake forms and referrals. You can use these pipelines to do the PDF extraction and then extract different fields. They can be very simple, like the name of the patient, and they can be very contextual, like the dosage of medicine that is related to the primary condition mentioned in the report. With powerful enough reasoning, you can extract this information.

[00:54:20] So if you don’t do agentic AI for end-to-end automation, the step before that will be to structure the unstructured. Take your unstructured data, bring it into a structured form, ETL that, automate that, propagate that through your operating systems.

[00:54:40] Sahar Dolev-Blitental: Fantastic. And there’s another question here, maybe for Alan, a little bit about what organizations need to do in order to prepare for AI agents, for harnessing unstructured data and turning that into AI-ready data. How do organizations prepare, whether it’s on the team front or on the structure front, so not just the tech but also more of the organizational components? If you could say a couple of words on that.

[00:55:07] Alan Jacobson: Yeah, it’s a great question. So first I want to back up. When I talk to organizations about how it’s going with AI, one of the most frequent things you hear is, “Our data is not ready,” kind of an answer. And one of the most fascinating things, which hopefully you saw today with what Or showed, is that one of the better use cases of using AI is using AI to help you, I’ll say, clean up and organize your data so that AI can better attack the data.

[00:55:36] And so one of the better use cases right now for these agents, for AI, is doing exactly that. The data isn’t going to, in a sense, clean itself. You’re not going to manually go clean that data. And if every time you have a question of the data you haven’t done that pre-work, you’re going to have a challenge.

[00:56:01] Now, by the way, this is not new. This happened in the prior generation, before AI, when people tried to do analytics on data, and again, you heard the biggest struggle they had was the quality of the data. And so data engineers spent a lot of time manually doing that. We’re basically just repeating that now, using the more agentic approach. And so I think that’s probably one of the key areas companies are both struggling with, but also starting to apply this agentic approach to.

[00:56:37] Sahar Dolev-Blitental: Another question here is about the architecture. What does the architecture look like in order to support what you’re both describing? And how does Flexor, for example, work with other enterprise components of the data stack?

[00:56:54] Or Zabludowski: So from an architecture perspective, there are a few design principles that we strongly believe in. And although we’re a company building software and AI, we believe in architecture openness and portability.

[00:57:10] The reason is that it’s kind of hard to believe, with the pace of things changing in the infrastructure, that a single vendor will win them all when it comes to how to do things. However, we do have very, very solid standards when it comes to open architectures. The open source community is doing a great job, and a lot of tooling is being built compatible to that. What we’re talking about is context as data and data as open, federated data architectures.

[00:57:48] So the first component that we believe is important is to store all of the primitives you create, the AI-ready data, the context maps, everything, in tabular data. It might be surprising, but that’s the easiest way to guarantee that the effort and the cost you’re putting into inference to generate this data resides in the kind of storage that is most useful and can be reused for different architectures.

[00:58:10] And what I mean by that is that you can take a table and map it to a graph database. But taking a graph database and running a SQL query on it, when it’s not indexed the right way, is much more complex. Throwing that in a bucket is very portable, very cheap. So Iceberg tables at the foundation, everything saved as data: the extracted PDF, the extracted call transcript, but also the context tables. Domain intelligence also goes into that.

[00:58:45] And on top of that, you need another important component, which is a query engine. The reason is that the task of taking huge data and narrowing it down into small, relevant, contextual data is best performed by the powerful query engines that were designed for years by the database companies. So anything from Trino, one of the managed versions, Snowflake, Databricks, all these kinds of engines running on the open data architecture serve as the gateway for agents. Agents will have their own memory, but they need an architecture gateway for that.

[00:59:23] And other than that, we’re talking about inference parts of the architecture. You can host that, you can serve that yourself. That’s the main thing.

[00:59:35] Other than that, since we work with Iceberg, we natively integrate into all of the big data platforms. We have Microsoft Fabric, we do Google BigQuery, Databricks, Snowflake, and we’re soon introducing a Starburst integration. So all these things just live natively within the modern data stack, and we believe that’s going to be the go-to approach for the coming years.

[01:00:01] Sahar Dolev-Blitental: That’s great. That’s really interesting. I think we have time for just one question, because we’re coming up to time. So the last question here is: how do we get started? If someone wanted to start out with Flexor, what would be the best way to kick that off?

[01:00:19] Or Zabludowski: So honestly, I think the harshest feedback that we got from the market over the last couple of months was, “Hey guys, it’s great that you built an enterprise product, but I can try everything open source. I can try everything using APIs right now, and I cannot try Flexor like that.”

[01:00:39] And the good news is that we’re introducing ACE 2, Flexor ACE 2, the AI context engine that you saw in the demo, for the first time ever as a full self-service online trial. We’ll be launching that in the last week of September. I believe it’s going to be September 23rd or 24th.

[01:01:03] And if you’re interested in giving it a try, think information extraction and preparation for any framework. Think structured data extraction at scale, or the agent harness to let agents scan the entire enterprise library. You can drop us a note here, you can shoot me an email directly, or contact any of the team members, and we’d love to have you give it a test run.

[01:01:30] Alan Jacobson: That would be great.

[01:01:31] Sahar Dolev-Blitental: Amazing. And there’s one question in the chat about whether the recording will be available. Yes, the recording will be sent to everyone after the session, and of course you can rewatch it at your convenience.

[01:01:40] So at this point, I just wanted to say thank you so much to Alan and Or for this great webinar, and thank you all for joining us. We’re happy to take any questions offline as well. Thanks for being here with us.

[01:01:53] Alan Jacobson: Thanks, everyone.

[01:01:54] Or Zabludowski: Thank you so much. Goodbye.