# Reducto: Solving AI Document Infrastructure

**Podcast:** a16z Podcast
**Published:** 2026-10-21

## Transcript

The day we got into YC, we told that we were going to pivot.
Nobody thinks about complexity when they upload a document to ChatGPT.
You just expect it to work.
On the other hand, the tools that you had to solve them were much, 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 on many tests.
The best version of Reducto is one where you can kind of abstract away the PDF processing problems, even if the PDFs contain these like sub intricacies along the way.
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 like Reducto 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 Reducto 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 Reducto 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 move into 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 Reducto, I think working on some memory related problems.
What turned the attention to documents and why it's still not a solved problem?
So we started in 2023 when models had horrible context windows.
And so memory was this top of mind thing that you could feel.
And 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, right?
So much white-collar 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.
And so 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, right?
It's not like an...
oops to say, oh, I messed up a checkbox.
It's like, oh, that's a patient's outcome, right?
And so that's where we got really excited of thinking of it as you're going to process more documents than ever before in history.
How do you build this sort of 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.
And 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 infra.
And because our background was in CV 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.
There has been OCR technology from, I think, 20 years ago.
A while.
Yeah.
And I know Redux has been on 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 VLMs 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 for us.
Yeah, I always joke that I've literally met people that have worked on PDF processing longer than I'm alive.
There were people in the 1990s that were working on drivers to print PDFs, which was the original purpose of the format, right?
Like, how do you faithfully represent all of the characters on the page?
You can kind of break this down into a few epochs.
Like first it was a file processing problem.
Then you started having these like 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.
And that was 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 ChatGPT.
You just expect it to work.
On the other hand, the tools that you had to solve them were much, much more powerful.
Like, BLMs have this notion of reasoning on the contents that historically you 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 9 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 and the second column.
When you have a table, it's two dimensions of data, but you want to preserve the rows, the columns, the merge cells, and everything in between.
And so when we first started, we started looking at this from a two-part problem of how do you use traditional computer vision to preserve structure and how to use VLMs as like a correction loop.
because there were clear accuracy costs and latency trade-offs.
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 VLMs for this type of task.
And that's...
where R1 came in.
Now we have one unified model that does that end-to-end.
Without the trade-offs that historically you would have had, you still have bounding boxes.
It's still very consistent, but it captures everything on the page.
Since 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.
Maybe talk a bit more about how you achieved the critical 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 can unlock a different...
you just have use cases you haven't imagined that's possible before that can be possible now that I think Reduct has proven time and time again.
Yeah, there's a lot to the work that we do.
Like 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 we work with.
the largest enterprises, 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 it.
It's how we eval the products and having a really good RL loop around post-training and mid-training 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 VLMs, for example, is repetition becomes really annoying.
And you'll have PDFs where you use periods to separate two different spaces, like people just structure things like that.
And when you have 100 periods in a row, VLMs start just repeatedly opening 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.
You can imagine that when people are capturing things like blueprints and diagrams, these are really, really dense pages.
You as a human need 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 were incredible at.
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 OCR is actually in its 70, 80 range.
It's not even close to the 97, 98 or sometimes 99s.
What are you shooting for?
Like, how do you think about that trade-off 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 doctor's 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 end-to-end 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 compound, 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.
Like 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.
Like, what is the comparison point?
But when you think about it, like humans make all sorts of mistakes, right?
Like people miss content.
They might drop rows.
Maybe they get lazy and only fill in part of the information.
But if you have a harness where the agent is not only extracting the information, but correcting itself, reviewing its outputs, you kind of get to unbounce that in the favor of perfect accuracy.
So 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 else it can unlock?
What are the use cases you've seen that people were hesitating to put through a model or put through a pipeline now that we can?
you know, really economically think through to use agent for.
Yeah.
I mean, for a while, most AI products were these chatbots where you had a constrained set of sources and like that's what you were working with.
If you're going to have agents do work, like humans are really good at understanding, hey, I'm missing information.
Let me go look for more.
Right.
And so.
you ideally want your agents searching the web for content.
You want them looking in your knowledge bases and retrieving more.
And 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 process 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, like at higher volumes, if somebody wants to process tens of billions of pages, how do we make that work at scale?
Very cool.
And congrats on the passing 7 billion.
Thank you.
I remember you, I think, tweeted about it, how long it took to get to 1 billion.
It just goes faster every single time.
Yes.
Want to have a prediction for when you reach 8 billion?
We said this would come out end of October.
I think we'll be past 8 billion by then.
Very cool.
We keep breaking our record for pages processed in a week.
That's awesome.
Well, 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 really 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 AI native companies like the Harveys of the world, the Rogos 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 in 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.
Through that, we'll have to talk about the harness you have built.
but more about inspiration behind that and how does the largest private equity funds and the largest 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 great parsing accuracy, you need tools for evaluation and review and it's like constructing your individual workflow.
And we wanted 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.
It's like if you've negotiated a contract before, you have multiple versions of like a red line term sheet in your 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 contradict.
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 document, but like, here's the individual word for why we know X was the answer.
And if you know that on one document 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 underpinning that for us is like, I was talking to the team about it recently.
If you look at the code 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'd all shaved their heads for a million in ARR.
And that was like a big milestone.
From Cursor?
Yeah.
And now like you look at the market and many of them are past a billion in ARR.
But you don't really see that in like the professional services markets yet.
And the question is why?
Like, is it that there isn't sufficient value?
Like, clearly not.
Healthcare has so much work that is paper heavy and insurance and legal and finance.
I think a lot of it is like there are 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 a 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 or the models will be much more accurate for some type of work than humans dropping rows like missing columns and not filling the data but they still just like you know having this routine versus you know there is the the massive force behind like developers wanting to automate their jobs away.
Like that's culturally acceptable and exciting.
Yeah.
There's certainly some part of enthusiasm in 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'd love to also touch deeper on like how now that you have moved.
into very much owning your own model and harness and building deeper 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 the office suite, which is weird because that's where a lot of human work happens.
If you imagine all the different things that would be in lots, one good example that I really like is localization is a really hard problem.
People put a lot of time on it, but translation is really easy.
Models can take freeform text and translate them.
And we want to make it easier to apply those translations.
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 plugin on ChatGPT where you'll be able to edit whatever you want.
Think of it as 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 evals, 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 Reducto.
And that'll start with things like schema optimization as like a first-order problem.
But really, we want to get to a point where people can apply their context effectively.
Maybe on the point of building the ChatGT plugin, like, 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.
Like, why do you think this is not a problem?
that they will solve where it requires independent company like Reducto 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 compete with the labs on reasoning quality.
And I think one of the things that's underappreciated is how deep the range of problems gets.
Like even after probably looking at more PDFs than 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 aren't 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, you know, 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 GPT, it needs to be able to take a selfie and, you know, turn it into a 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, like 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.
You can't throw Astra at all of your PDF parsing tests, but we want Astra-level quality for the work that we're doing.
This is also where I find a lot of people's misunderstanding lies that you can just do a one-shot of a model call to get information you need from a long document, but usually it's a pipeline.
You kind of have to decompose the document, breaking them into parts.
And that's where I think you guys have spent a lot of effort in.
you know, decomposing what's in the document, understanding the format, like being able to translate it accurately and getting through all the nitty gritty details to make sure like each piece is parsed and 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 compared to this one-shot type of approach?
There's actually a really interesting benchmark that MicroOne 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 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 recall 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.
Like it's not just a model focused on extraction.
In fact, the harness is kind of agnostic to the model.
create a lot of tools for the model to be able to use to review its own outputs, to create validation rules.
Like if you have a massive invoice, how do you have a parent agent make sure that the item's 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 to near-perfect accuracy there.
And that applies across all sorts of stuff that we do, like document splitting as well.
Maybe touching on the benchmark piece.
A benchmark can look great.
And we spend a lot of time benchmarking across all the real-world scenarios.
The 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 a useful eval for a benchmark look like when your customers are evaluating Redactal 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 of how you even decide what to measure.
Where we made a post about this recently, 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 of this, 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 like sometimes egregious versions of this where I'm not going to name names, but like we tested a...
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 like Gaussian blur, the provider that published 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, LLM as 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 evaluation easier.
But instead of trusting like 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 like a golden data set that they are ready to eval Redactal on versus you kind of do work with them?
Does the golden data set need to be good?
I mean, I guess that's the expectation, but.
Yeah, so it's often the case that people have some sort of golden data set, but we find that like 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 LLM generated, but for cost reasons, maybe they use Sonnet instead of Opus and like Sonnet made some sorts of mistakes.
I find that it's increasingly common for people to have at least some form of an eval.
But it's really, really hard to make sure that the eval 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 into any sort of headset comparison.
And are you still today seeing the majority of the type of documents being PDFs?
Or are there other formats that starts to trickle in and becoming more dominant and harder for LMs to work with?
It's actually kind of all over the place.
So we support over 40 file types.
PDFs are, I think, like a good flagship name.
But for us, at the end of the day, a lot of this is image processing.
But you can imagine like Excel files can be arbitrarily large.
You don't know if it's going to be one massive sheet or like 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 break it down into image processing.
I guess it's a lot more generally available or approachable for...
But at the same time, it probably is harder for other, I guess, traditional approaches to deal with it.
Like, how do you think about, you know, the file format itself becoming more and more involved and including more modalities?
Yeah, I think at the end of it, there's a sort of like layers unfolding as you look at complexity.
Like, first order 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 point, like 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, okay, this is a line chart and we need to not just characterize like revenue went 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 reductive is a state of the art there.
We should pull up the benchmark on that one because it's actually hilarious of how bad 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 doesn't have 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 if the PDFs contain these like sub intricacies along the way.
And there are nested tables too.
There are like in Excel, there's like multiple tabs.
The more like we dive into these set of issues, the more I feel like it's a 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 as you're moving more into, I guess, building the harness, building the workflow, solving more longer horizon end-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-house.
And I really want Reducto 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 exists 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 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, Reductive is turning PDFs and documents into that data that fed into LLMs.
The other one is just compute that LLMs 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 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 these are physical documents.
They will have packets that are inches in height.
And the weird thing, like, 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 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, it's like 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 with the search products.
Like imagine if an agent was making that sort of adjudication decision.
Like 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 measuring by pages, but by...
inches of how tall the document 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 miss the chest pain.
Oh, like people make mistakes all the time.
There are millions of Medicare claims that are rejected every single year for prior auth.
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 made.
80%?
80% of appeals.
Wow.
I found that to be unbelievable, but it extends 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 bottlenecked by needing high enough accuracy that warrants a human today.
That if you had an infinite aperture for, you know, accuracy and cost and latency, such that you could just apply frontier models on these tasks, you can make a lot of these processes easier for humans throughout the world.
Having seen some of the findings 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 and human loop of work that can be automated today, but not yet.
If AI can really reliably understand, evaluate, and change the document the 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.
Like, 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% of tax filers still file via paper mail.
And so all these things that just like...
add weeks of work in a way that is kind of rote 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 or application layer that you think people should know?
It really depends on the industry.
In accounting, we're seeing basis to incredible work, for example.
But this 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 of problems.
Very cool.
Can't wait for more of these.
menu, mundane, and so sucking human in the loop work to go away and we can focus on more exciting things.
Awesome.
It's so great to have you, Adit.
Thank you so much for coming by today.
Thanks again.
This was fun.
Follow us on X at A16Z and subscribe to our Substack at a16z.substack.com.
Thanks again for listening and I'll see you in the next episode.
including a link to our investments, please see a16z.com forward slash disclosures.