The Missing Infrastructure for AI Agents: Documents | Reducto’s Adit Abraham

"The day we got into IC, we told that we were going to give it." Nobody thinks about complexity when they upload a document to Chaturgy TV. You just expect it to work. On the other hands, the tools that you had to solve them were much more powerful. Documents to us are almost these abstractions and artifacts of human work. It's the first time where I find that agents can be better at structured extraction than humans have any tests. The best version of Redocto is one where you can kind of abstract away the PDF processing problems, even if the PDFs contain these sub-intercities longer. Given the big model labs are also focused on knowledge work, why do you think this is not a problem that they will solve where it requires independent company Redocto to really focus on it? One of the things that's underappreciated is how deep the range of problems gets. Yes, the labs could maybe go into this deep dive of trying to build all these individual tools. But I personally believe that they're on an arms race for AI agents are getting dramatically better at reasoning. But much of the information they need to do real work is still trapped inside PDFs, spreadsheets, scans, and other documents that machines struggle to reliably understand. In this episode, A16z General Partner Jennifer Lee sits down with Redocto co-founder and CEO Adit Abraham to unpack the surprisingly difficult infrastructure problem behind getting AI agents to work with documents. They discuss why traditional OCR isn't enough. How vision-language models change document processing, and why a model that looks accurate on a benchmark can still silently drop critical information when it encounters a long or messy document. Adit also explains how Redocto built its own specialized model why agents can sometimes outperform humans at structured extraction by reviewing and correcting their own work, and what becomes possible when AI can not only read documents, but reliably edit and act on them. Because as agents movement to healthcare, legal, finance, and insurance, a document processing mistake is no longer just an OCR error. It can change a real-world decision. Adit, welcome to our podcast studio. It's so great to have you here. Thanks for having me. I would love to start a conversation by asking when you and Ronik first started working on Redocto. I think we're working on some memory related problems. What turned the attention to documents and why it's still not a solved problem? We started in 2023 when models had horrible context windows, and so memory was the top of mind thing that you could feel. I remember the day we got into YC, we told Diana that we were going to pivot, which she was surprisingly accommodating about. The framing retroactively that we have that, honestly I think, wasn't actually as lucid back then, is when you think about it, agents are going to do all sorts of human work, and it happens to be the case that documents to us are almost these abstractions and artifacts of human work. So much white color work across healthcare and legal and finance and insurance is in things like PDFs and spreadsheets. You read from them, you write to them, and they catalog that knowledge. If you're going to have agents doing work in healthcare, reading things like patient records, it's really important that you have the same fidelity that you did when a human was looking at it. It's not like an oops to say, "Oh, I messed up a checkbox." It's like, "Oh, that's a patient's outcome." So that's where we got really excited at thinking of it as, "You're going to process more documents than ever before in history. How do you build this interface that connects synthetic intelligence and human knowledge?" That's been a really deep spiral. The honest answer of how we actually got here is some amounts of right-place right-time, like vertical AI apps were first spinning up, and our background was in computer vision. We started talking to a lot of these early AI native companies and surprisingly kept finding this recurring trend of people were struggling with their document processing it for a. And because our background was in CD research, we wanted to look at it from this broader problem of, "How would you read it the way that a human would have?" And it's spiraled from there. I guess maybe break it down a little bit. It has me OCR technology from, I think, 20 years ago. Yeah, a while. Yeah. And I know Redactors will be on the top of visual language models. Maybe do a quick teaser of the difference where you see the traditional technology is not good enough and where the large models and frontier violins are really driving to solve these messy problems. And where they're still lacking. I think there's still quite a few problems to be solved. Break down the world of Redacto's documents price. Yeah, I always joke that I've literally met people that have worked on PDF processing longer than I've been alive. There were people in the 1990s that were working on drivers to print PDFs, which was the original purpose of the format. Like, how do you faithfully represent all of the characters on the page? You can kind of break the sound into a few epochs. Like, first it was a file processing problem. Then you started having these OCR-based IDP companies. And typically what you would have done is you have something like a W2. You template out what a W2 looks like. Like, you have a pixel level understanding of the name appears here and you post process that text. Now, it's fine for a lot of consistent pipelines, but the thing that changed in 2023 is nobody thinks about complexity when they upload a document to chat GBT. Really, you just expect it to work. And on the other hand, the tools that you had to solve them were much, much more powerful. Like, BLM's have this notion of reasoning on the contents that historically wouldn't have had. And so those two things kind of came together right around when we were founded where ultimately these documents are just images. You have this like nine by 11 grid. And you could have constructed information any which way. It's not just characters on the page. It's when you have two columns understanding that you're reading the first column, the second column. When you have a table, it's two dimensions of the data. But you want to preserve the rows, the columns and merge cells and everything in between. And so when we first started, we started looking at this from a two-part problem of how to use traditional computer vision to preserve structure and how to use BLM's as like a correction loop. Because there were clear accuracy costs and latency tradeoffs. Like we care a lot about not just accuracy, but determinism and traceability. Our customers need to know where we got an answer from, right? And traditional CV was really good at that. But over time, as people have pushed more on multimodality, we've been doing a lot of interesting work on how do we build the best BLM's for this type of task. And that's where R1 came in. Now we have one unified model that does that and send. Without the tradeoffs that historically would have had, you still have bounding boxes. It's still very consistent, but it captures everything on the page. So you mentioned R1, let's talk about that one. You have, I guess, started from using off-the-shelf models, but decided to post-training your own foundation model. That's R1, and it's reported better accuracy, higher speed and lower cost. Yeah. Maybe talk a bit more about how you achieved the Prital Frontier for this model. And what do you think that's going to unlock as far as use cases, given that's what I found powerful of this model, in general, in the AI space where when you account and lock a different frontier, you just have use cases you have imagined as possible before. Yeah. That can be possible now that I think reductis proven time and time again. Yeah. There's a lot to the work that we do. We are fortunate to have some of the best researchers for our domain on the team. And so this isn't like a one-quarter breakthrough. I kind of see it as a culmination of work that we've done since the starting of the company. For a while, we spent a lot of time on catching errors in production, like finding out how we can create feedback loops of, hey, we messed up this table. How do we create a better tabular representation? And we've also been fortunate to work with some of the hardest distributions of data that we work with, the large center prizes, the leading AI native companies, and they've helped us understand the corner cases of where different types of models fail. And so we put a ton of time into not just model architecture, but also the data pipelines around us, how we evolve all the products, and having a really good RL loop around post-training and matrating the model. What are some of the messiest type of data and the hardest solve for those edge cases? Give us some examples. It depends on the tools that you're using. So one characteristic of the elements, for example, is repetition becomes really annoying. And you'll have PDFs where you use periods to separate two different spaces, like people will just structure things like that. And when you have 100 periods in a row, the OEM start just repeatedly, up in periods. But the range of what we see is actually much, much harder than these sorts of, like, almost last mile technicalities. Because in the real world, you'll have contents that's a table that spans across two pages. And maybe it wasn't scanned perfectly, and so the columns are kind of mismatched. And so you need to start thinking about structure and actively applying, specialized pipelines to merge those two together and preserve that context. And you can imagine that when people are capturing things like blueprints and diagrams, these are really, really dense pages. Like, you as a human needs to zoom in to interpret it. And so you need almost like a patchwork based approach to understand what was on the page. And those are the sorts of things that we wanted to make sure we weren't cut a plot. And maybe talk about accuracy as well. I find for every magnitude of accuracy unlock, you actually unlock more use cases to be in the more fully automation or automated range. I mean, a lot of traditional CRs, actually, it's 7080 range. It's not even close to the 90s, 78 or sometimes 99s. What are you shooting for? Like, how do you think about that tradeoff of still having human loop versus? You can actually use agent to replace a whole sort of document processing pipeline. Yeah, and this actually goes to the work that we're doing beyond parsing. I think parsing is like this core building block of, how do you even understand what was on the page? And for the vast majority of use cases, we can actually be in the high 90s today. There are corner cases. Like, there's doctors handwriting that I can't read. And so I don't even know if we did a good job. But if you think of an n10 task, like you're taking in a loan packet, it's not just parsing, you're splitting the contents, you're extracting individual fields, maybe you're editing a loan application form at the end. And each one of those steps needs to be accurate. If you're taking in a dozen files, you can't have 90% on individual pages because those mistakes come out, right? And so a lot of the. interesting work for us recently is not just on the model layer. We started releasing harnesses around the work that we're doing. Deep extract is a really good example where it's the first time where I find that agents can be better at structured extraction than humans on many tests. We find situations where human annotated ground truth has a lot of errors that they wouldn't have otherwise known because it's your ground truth. What is the comparison point? When you think about it, humans make all sorts of mistakes, right? People miscontent. They might drop rows. Maybe they get lazy and only fill in part of the information. If you have a harness where the agent is not only extracting the information but correcting itself, reviewing its outputs, you get to unbalance that in the favor of perfect accuracy. After accuracy and latency, let's talk about cost. Now, we're down to a penny per page with very high quality parsing and extraction. How do you think about what becomes possible when you have this very powerful document processing pipeline? What are the use cases you've seen that people were hesitating to put through a model or put through a pipeline, not that we can really economically think through to use agent for? Yeah, I mean, for a while, most AI products were these chatbots where you had a constraint set of sources and that's what you were working with. If you're going to have agents do work, humans are really good at understanding how missing information, let me go look for more. You ideally want your agents searching the web for content. You want them looking in your knowledge bases and retrieving more. Ideally people are not thinking from the lens of like, "It cost me this much to parse a page and therefore only these pages go to an accurate pipeline." Today, literally this morning, we crossed our 7 billionth page. At this point, we processed billions of pages every single month. And so the thing that we want to get to is that every single page that needs to be read by model is read through reductive first and that needs to be frictionless. So there's a lot of work for us to do as a team. One cent per page is our list price, but we are doing a lot to understand at higher volumes of somebody wants to process tens of billions of pages. How do we make that work at scale? Very cool. And congrats on the 7,000,000,000. Thank you. I remember you. I think tweeted about it. How long it took to get to 1 billion. Yeah. It just goes faster every single time. Every single time. Yes. Want to have prediction for when you reach 8 billion? We said this would come out end of October. I think we'll be past 8 billion like that. Very cool. We keep breaking our record for a pages process in a week. That's awesome. Maybe talk a bit more behind what's driving that growth, like what are, I guess, the type of workloads we're seeing that has these pretty large amount of documents involved. I would categorize the early wave of use cases as different forms of information synthesis. Like chatbots are ultimately our search tools for a lot of people. And so early on we started working with a lot of the leading, I need of companies like the Harvey's, the world, the Robo's and so on. But more and more we started getting adopted by the largest hedge funds, the largest private equity firms, tech companies, where the use cases are all over the place. Like in some cases they are building tools where agents are reasoning over data. But in some cases they're trying to do actual work. Like if you're a hedge fund, your pipelines for aggregating information are your competitive edge in the market, right? And so if you can be faster and more robust and gathering all of the signals that are available, that's alpha. And those are sorts of things that we're starting to see more and more. So we'll have to talk about the harness you have to talk a bit more about inspiration behind that and how does the largest private equity funds and the largest other services are adopting it. We started seeing a lot of our customers use two or more endpoints together. And if you're going to deploy in production, you need not just create parsing accuracy. You need tools for evaluation and review and constructing your individual workflow. And we want it to make all of that easier. And there are little things that I think are really, really hard when you think of the real world. Like if you've negotiated a contract before, you have multiple versions of a red line term sheet and you're a laptop somewhere. And it is hard for people to understand what is the latest version, unless somebody labeled the file like final or something like that. And so you have duplicates of contents. You need to reconcile between disparate sets of information that contradicts. And it builds on a lot of the work that we've been doing. We put so much time into citing like not only, hey, this is the answer and this is the documents. But like here's the individual word for why we know X was the answer. And if you know that on one documents and you know that on another, you can make it easier for agents to actually reason through and understand, okay, like here's how I should land on the truth by looking at both sorts of information and reconciling that. And so that's what we're really trying to do. Like we want document work to be more accessible. And the thing, underpending that for us is like, I was talking to the team about it recently. If you look at the co-gen market in 2023, like when tools were just code completion tools, they were at a fraction of what they are today. Like I admire cursor a lot as a company and I remember one of my friends came to dinner with a shaved head, they don't shave their heads for a million in a year or, and that was like a big milestone. From cursor? Yeah. And now like you look at the market and many of them are passability in an error. But you don't really see that in like the professional services markets yet. And the question's why, like, is it that there isn't sufficient value? Like clearly not, healthcare has so much work about us, paper, heavy, ins, insurance, and legal and finance. I think a lot of it is like they're these second order problems that are not just intelligence. And we want to help our customers solve this. And how much do you think that's like technology problem versus like a cultural and like speed of adoption problem as like people don't feel comfortable enough of like trusting like again, when you're even though we know probably that the machines will be much more accurate for some type of work than humans dropping rows like missing columns and not filling the data. But they're still just like, you know, having this routine versus, you know, there is the massive force behind like developers wanting to make their jobs away. Like that's culturally acceptable and exciting. Yeah. There's certainly some part of enthusiasm and tech like these are almost like toys for people in tech to play with. But I think there's also like something to be said about consequences. Like if you if you vibe code something and it's filled with bugs, like you get to roll back your PR in a way that is not true if you're making decisions in healthcare, right? Like there are stakes there that are very, very real. And so I don't think we can pin it on just like willingness to adopt. I think there's a real question of like how do you have sufficient guardrails? Like how do you give the human confidence and the decisions that they're making? And that plays into everything that we talked about with citations and grounding all of that. Yeah. We'll have to also touch deeper on like how now that you have moved into very much owning your own model and harness and building deep into the workflow, like what's coming next. Number one is we've been doing a lot of work to unlock the full range of interaction modalities. And one good example of that is document editing. I don't know if you spent much time with like Cloud for Excel and like the different plugins that are out there, but it's actually surprisingly hard for agents to work with you. The office suite, which is weird because that's where a lot of human work cuts. If you imagine all the different things that would be in lots of one good example that I really like is like localization is a really hard problem. People put a lot of time on it, but translation is really easy. Like models can take freeform texts and translate them. And we want to make it easier to apply those translations. Like if you have a document in English, how do we make it really easy for you to translate it to Arabic or another language? So in the next few weeks, you'll see us launch a lot on that front. We are starting with a plug-in on chat GPT where you'll be able to edit whatever you want. I think it has like a headless version of Microsoft Word that agents can use. But it doesn't stop there. I think in general, we want to make that tooling really, really resilient as you think about eBAL's monitoring and observability. And more broadly, the thing that we want to get to is we want to make it easier for our customers to start improving their pipelines with Redacto. And they'll start with things like scheme optimization as like a first-shorter problem. But really, we want to get to a point where people can apply their context effectively. Maybe on the point of building the chat GPT plug-in, given the big model labs are also focused on knowledge work and they're also always improving the capability of their own models to be good at multimodality vision as well. Why do you think this is not a problem that they will solve where it requires independent company Redacto to really focus on it? Yeah. A lot of the work that we do is kind of tangential to intelligence. Like we're not trying to compute with the labs on reasoning quality. And I think one of the things that's underappreciated is how deep the range of problems gets. Even after probably looking at more PDFs and most humans, I still find corner cases that we didn't expect. Like within PDFs, you can have folders of PDFs that contain other PDFs. Like if you think of even rendering a Microsoft Word file, you'll find that there are good open source tools to be able to represent that faithfully. And that's why libraries like LibreOffice often fall short. And so yes, the labs could maybe go into this deep dive of trying to build all these like individual tools. But I personally believe that they're on an arms race for creating super intelligence for the world. And the work that we're doing is more so like infra around that that helps make that more useful. And the other thing is I find that focus is really, really important. The fact that we can constrain the set of problems that we need to be good at is a big part of why we're able to be ahead. We're not making generic models here. Whereas the vision encoder for a model powering chat CBT, it needs to be able to take a selfie and turn it into Studio Ghibli image. We know the domain of information that we're working around. We need our models to be exceptional on this specific set of tests. And so for our customers, when you're processing at a scale where it's not just accuracy, you need cost and latency at scale, we are able to be orders of magnitude more aggressive on price than a frontier model at a comparable accuracy profile. And that makes a huge difference on when it makes sense to use something like you can't throw astra at all of your PDF parsing tests, but we want astral level quality for the work that we're doing. This is also where I find a lot of people's misunderstandings lies that you can just do like one shot of a model call to get information you need from like a long document. But usually like it's a pipeline. You can have to decompose the document getting, breaking them into parts. And that's where I think you guys have spent a lot of effort in decomposing what's in the document, understand the format, like being able to translate it accurately and getting through all the integrated details to make sure like each piece is parsing extracted correctly, but also using the capable large models in the last mile. Maybe you can talk through like what are like typical components of a pipeline and how does that maybe on the price and latency compare to these like one shot type of approach. There's actually a really interesting benchmark that Micro1 put out. It was independently run and we got to partner with them on it, where it was focused on long extraction tests. And the reason why I think it's interesting is we tested all the frontier models at the time. We tested reducto and some specialized document parsers. And we found that actually that frontier models were better than a lot of specialized document parsers at precision, like given that they were extracting something they were more likely to be correct. But the failure mode was actually recalled for the frontier models. Like they would silently drop information. That's the kind of thing that it's really, really hard to catch in production. So when we think about something like deep extract, there's a lot that's happening there. It's not just a model focused on extraction. In fact, the harness is kind of agnostic to the model. We create a lot of tools for the model to be able to use reviews on outputs to create validation rules. Like if you have a massive invoice, how do you have a parent agent make sure that the items summed up to the total? Like those little details such that it knows when to go back and double check information. And that's the only way we were able to get in your perfect accuracy there. And that applies across all sorts of stuff that we do like documents splitting as well. Maybe touching on the benchmark piece, the benchmark can look great. And we spend a lot of time benchmarking across all the real world scenarios that Micro One is very representative of that. But sometimes it's still missing the details to the customer themselves. Like how do you think your, I guess, what does it use for Eval for a benchmark look like when your customers are evaluating redactyl versus maybe open source models or like other frontier models to similar tasks, what do they care mostly about? Yeah. And what do you think they should care mostly about? The number one thing that I think they should care about is distribution of data and understanding if it's representative for what they want to do. Like if you're dealing with really simple documents, odds are a simple pipeline is sufficient. And you don't want to look at a generic benchmark for that. But number two, I think there's a lot of places where things go wrong, like how you even decide what to measure. Where we made a post about this recently, like it's generally a mistake to have really strict rules in your benchmarking, for example, because you could represent the same information faithfully, two different ways. And you don't want to penalize that. One of the unfortunate things about the AI industry, and I'm not trying to absolve reductive this, like I think this is just a general thing, is benchmarks have become marketing over time. And the downstream side effect is it's really hard to know what is good in your context when everything is like state-of-the-art all the time. And we find sometimes egregious versions of this. But I'm not going to name names, we're like, we test it. There's a public benchmark out there that we tested where if you take the same documents and you add a little bit of noise, like you tilt it one degree, you add a little Gaussian blur, the provider that publish the benchmark gets way, way worse than everyone else, but everyone else is kind of consistent. And you can draw conclusions from that. But that's the kind of thing that like the average person is not going to go out to do. And so our recommendation is actually, LM is a judge is quite strong today. If you're thoughtful about how you think about a rubric and how to approach it. And hopefully, we want to see the industry move closer to people testing on their own data, with tools maybe to make that valuation easier. But instead of trusting a generic benchmark, you really should be at a point where you know what works best for you. How often do you walk into a customer and they already have a golden data set that they are ready to evolve redacto on versus-- Does the golden data set need to be good? I mean, I guess that's expectation, but-- Yeah, it's often the case that people have some sort of golden data set. But we find that, depending on how they made it, there's all sorts of issues. Like, we find situations where it was human generated and so the human dropped information. Sometimes it's like LM generated, but for cost reasons, maybe they use Sonnet instead of Opus. And Sonnet made some sorts of mistakes. I find that it's increasingly common for people to have at least some form of an e-vow. But it's really, really hard to make sure that the e-vow holds. And so we try to partner with teams a lot to make sure that they feel good about how they're going to test before they even get in. And Sam, you sort of had that comparison. And are you still, today, seeing the majority of the type of documents being PDFs? Or there are other formats that it stars to to go in and becoming more dominant and harder for LM's to work with? It's actually kind of all over the place. So we support over 40 file types. PDFs are, I think, a good flagship name. But for us, at the end of the day, a lot of this is image processing. But you can imagine Excel files can be arbitrarily large. You don't know if it's going to be one massive sheet or multiple spreadsheets with clusters all across. And models, even if they support a large enough context window, actually struggle with that sort of information. So there's a lot you can do of creating a representation of the Excel file that is meant for models to consume as opposed to just giving the raw file directly. And what does it mean for you when there's more multi-modality type of content? I believe even PDF today, you can embed multimedia type of assets into it. And we break it down into image processing. I guess it's a lot more generally available or approachable for your model. But at the same time, it probably is harder for other, I guess, traditional approaches to deal with it. How do you think about the file format itself becoming more and more involved in including more modalities? Yeah, I think at the end of it, there's this sort of layers unfolding as you look at complexity. First sort of problem, how do you know if a document is complex or not? And then second order problem, how do you know if a given page is hard? But then within pages, you have regions that are harder than others. And to your points, in finance, one of the most common forms of representing data is time series data, right? Like you have charts, you have line graphs or bar graphs, like whatever it is, that's really hard. And a human is really good at discerning where the trend line is going. But if you ask models, you find that they're actually kind of fickle. And so being able to understand, OK, this is a line chart. And we need to not just characterize revenue once up, but to characterize the individual data points, such that you can reason on those data points. That's a whole subdomain of problems where we train like a dedicated chart agents. I feel really good about saying reducto is a state of the art there. We should pull out the benchmark on that one, because it's actually hilarious of how that other models are. I think when you look at it visually, it's shocking how big the gap can be. But being able to do that in a way that the customer ideally does not to think about it is our goal. Like the best version of reducto is one where you can kind of abstract away the PDF processing problems, even that the PDFs contain these sub intricacies along the way. And there are nested tables too. There are like in Excel, there's multiple tabs. The more we dive into these set of issues, the more I feel like it's an unbounded set of problems. Yeah. So with that, how do you think about over the, like, let's say the horizon of the next few years, what does reducto become? I mean, you're known for the document processing capability and also the parsing accuracy and all that. but I see you're moving. more into, I guess, viewed in a harness, viewed in the workflow, solving more longer horizon and to end problems. What do you think is the opportunity that people haven't realized? Yeah. This goes back to what we were talking about in the beginning, but I think there's so much incredible work happening, both with the AI natives and the enterprises. Like, if you look at what a company like Harvey's doing for legal, but also what people are doing in the house. And I really once were doctored to be this like reliable sets of tools that both Harvey's and the largest enterprise in the world can use to apply their context with models. And that means we need to be the best in the world at parsing, but it also means all the little details that they would otherwise have to handle. Like, the infrastructure problems of suddenly needing to process 10 million documents in parallel. Like, those abstractions matter a lot for our customers. And if we do that right, it's like the value that we offer. I generally don't think of the intelligent document processing market as our category because the ambition that existed in IDP is very much not what we are hoping to do. We want to be at a place where agents can help augment human work. And I think I don't have like a market map vision of what's that means in the future. But I think playing a key role in that is a really, really important thing for the world. Yeah. As we always say, there are two things important in putting into the models. One is data, which, you know, reductives turning PDFs and documents into that data that fit into elements. The other one is just compute that elements can use to run out. So there's infinite opportunity to create value for language models to behave and perform. So definitely believe there's a tremendous opportunity to keep raising that bar. And that's why we get to work together. Great. Let's talk more about the consequences of accuracy and how does that impact your customers trusting, I guess, using agent and AI to process the documents? Yeah. I remember we have this customer that works in healthcare. They're a really large provider of what's effectively a search tool for doctors to be able to capture information. And they work with some of the harder situations in healthcare to the point where like these are physical documents. They will have packets that are, you know, inches in height. And the weird thing, it's hard to appreciate how much an error actually matters to the individual where we were talking about individual cases where like because the initial pipeline read something as check pain instead of chest pain, somebody's claim gets rejected because the doctor searches for, do they have a history of this? And if they don't, maybe they don't need the drug. And that matters, right? Because the doctors are also very overworked in a lot of these health systems that they can't double check all the information and make sure the OCR was accurate. They're just trusting that the tools that they're using are reliable. And that's just what the search products like, imagine if an agent was making that sort of a dedication decision. It is so important that you know that the inputs that you're dealing with are things that you can trust because it builds on everything else. That's incredible that they're not maddening their pages, but by inches of how tall the dog is. And what's the rough accuracy of like the current status of these OCR tools? In those sorts of situations, we actually find that there are cases where it's like sub 50%. Like the best you can do is have some approximation of where information sits and then a human has to look at it. Like a given patient's packet could be tens of thousands of pages. And so like even if you show the best examples, like a doctor can't really dig into it. Those are sorts of frontier problems that I hope we can solve for the world. Definitely. And what is the fallback today? I guess like if you-- humans. The test pain. Oh, like people make mistakes all the time. There are millions of Medicare claims that are rejected every single year for Priroc. And one of the craziest stats I learned is that in 80% of appeals, the original decision was overturned. Which should be shocking because clearly there's some inefficiency in how the decision was originally-- 80%-- 80% of appeals. Wow. I found that to be unbelievable, but it extends and not just in healthcare. Like if you look at the backlog that currently exists for USCIS, for immigration, so many of these are just like paper processes that are bottlenecks by needing high enough accuracy that weren't so human today. That if you had an infinite aperture for, you know, accuracy and constantly and see, especially you could just apply frontier models on these tests, you can make a lot of these processes easier for humans throughout the world. Having seen some of the filings for immigration, definitely a lot of different type of handwritten notes, a lot of images, photos, as evidence to go through. So I'm sure there's still a ton of efficiency in human loop of work that can be automated today, but not yet. If AI can really reliably understand, evaluate, and change like the document that business work with, what do you think should be possible today, but haven't, as the first few categories of work? Yeah. You'd be surprised at how much of data entry is still manual. And that's probably the first thing that I'm excited about. Humans have a lot to add as you think about reasoning and decision making, but there are a lot of people in the world that take physical documents and write out what was in the physical documents. It's really, really inefficient. In America, 16 percent of taxpayers still file via paper mail. And so all these things that just like add weeks of work in a way that is kind of roads and routine, those are probably the first set of problems that I'm hoping just kind of goes away. And who are working on those problems as your customers application layer that you think people should know? It really depends on the industry, like in accounting, we're seeing basis to incredible work, for example, but it also applies to large enterprises. We work with one of the largest accounting services companies where they do like customs and border patrol forms. There's a BPO company that does the back office work for a lot of these larger companies as well. I think all of them are excited to move past this category problems. Very cool. Can't wait for more of these manual mundane and so sucking a human in the loop work to go away and we can focus on more exciting things. Awesome. It's so great to have you, Adi. Thank you so much for coming by today. Thanks again. This is fun. Thanks for listening to this episode of the A16Z podcast. If you like this episode, be sure to like, comment, subscribe, leave us a rating or a review, and share it with your friends and family. For more episodes, go to YouTube, Apple Podcasts, and Spotify. Follow us on X, at A16Z, and subscribe to our sub-stack at a16z.substack.com. Thanks again for listening, and I'll see you in the next episode. As a reminder, the content here is for informational purposes only. Should not be taken as legal business, tax, or investment advice, or be used to evaluate any investment or security, and is not directed at any investors or potential investors in any A16Z fund. Please note that A16Z and its affiliates may also maintain investments in the company's disgust in this podcast. For more details, including a link to our investments, please see A16Z.com/disclosures.