The day we got into YC, we told that we were going to do it. Nobody thinks about complexity when they upload a document to Chatchit 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 to really focus on it? One of the things that's under appreciate is how deep the range of problems gets. Yes, the labs can maybe go into this deep dive of trying to build all these individual tools, but I personally believe that they're on an arm's race for AI agents, or 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 the machines struggle to reliably understand. In this episode, A16C general partner Jennifer Lee sits down with reducto co-founder and CEO, Adita 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. Adita also explains how reducto built its own specialized model, why agents can sometimes outperform humans and structure extraction by reviewing and correcting their own work, and what becomes possible when AI can not only redocuments, 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. Adita, 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 the 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.
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. 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 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 of our great place where it's time, like vertical AI apps were first ending 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 and because our background was in CD research, we wanted to look at it from the 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 all this technology from 20 years ago. Oh, wow. Yeah. I know we're actually going to top of the digital technology models.
Maybe do a quick teaser of the difference where you see that the traditional technology is not getting enough and where the large models and frontier VR lands 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 reductuous documents. Yeah, I always joke that I've literally met people that are working on PDF Ross longer than I've been live. 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 represents all the characters on the page?
You can break this down into a few epods. First it was a file processing problem, then you started having these OCR-based IDP companies. Typically, what you would have done is you have something like a W2, you template out what a W2 looks like, you have a pixel level understanding of the name of your Sierra, and you post-process that text. That'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 GPT. Very huge expected to work.
On the other hand, the tools that you had to solve them were much, much more powerful. BLM's had this notion of reasoning on the contents that historically wouldn't have had. Those two things came together right around when we were founded, where ultimately these documents are just images, you have this 9x11 grid, and you can 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 the data, but you want to preserve the rows, the columns and merge cells and everything between.
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 VLMs as a correction loop, because there were clear accuracy costs and lead to chaos. We care a lot about not just accuracy but determinism and traceability. Our customers need to know where we got an answer from. And traditional CD was really good at that. But over time, as people have pushed more on multi-modality, we've been doing a lot of interesting work on how do we build the best BLMs for this type of task?
And that's where R1 came in. If now we have one unified model that does that and send, without the trade-offs 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 started from using off-the-shelf models, but decided to post-training your own condition 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 per-tiffon tier 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 unlock a different tier, you just have use cases that have been imagined as possible before, that can be possible now, that I think R1 has 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 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 and 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 large enterprises, the leading AI native companies, and they've helped us understand the core in cases of where different types of models go. And so we put a ton of time into not just model architecture, but also the data pipelines around us, how we eat all the products, and having a really good RL loop around post-training and maturing the model. What are some of the messiest type of data in the hardest solve for those edge cases?
Give us some examples. It depends on the tools that you're using. 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 just structure things like that. And when you have 100 periods in a row, I'm just repeatedly out of 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, like, when people are capturing things like blueprints and diagrams, these are really, really dense pages. Like, 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 incredibly proud of. 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 automated range. I mean, a lot of traditional CRs, actually, it's 78D range.
It's not even close to the 98 or sometimes 9Is. What are you shooting for? Like, how do you think about that trade-off of still having human-aloup versus, you can actually use Agent to replace a whole sort of talk-and-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 to even understand what was on 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 lone packet, it's not just parsing, you're splitting the contents, you're extracting individual fields, maybe you're editing a lone 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 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 a comparison point? But when you think about it, like humans make all sorts of mistakes, right? Like, people miss contents. They might drop rows.
Maybe they get lazy and only fill in part of the information. But if you have a harness where the agents is not only extracting the information by correcting itself, reviewing its outputs, you kind of get to unbalance 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. Like, how do you think about what becomes possible when you have this very powerful document processing pipeline?
Like, what are the use cases I'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 4? Yeah. I mean, for a while, mostly I products where these chatbots where you have to constrain some sources and that's what you're 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. And so you ideally want your agents searching the web for your content.
You want them looking at 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 as a team, one center 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 7 billion. I remember you, I think, about it, how long it took to get to 1 billion.
It just goes faster. Everything goes on. I want to have prediction for when you reach 8 billion. We said this would come out end of October. I think we'll be passing a billion by then.
Very cool. We keep breaking our record for pages processing a week. That's awesome. Well, maybe talk a bit more behind the what's driving that growth. Like what are, I guess, the type of workloads you'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 Harvey's, the world, the Robos and so on. But more and more, we started getting adopted by the largest hedge funds, the largest private equity firms, tech companies, where these 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. And so if you can be faster and more robust in gathering all the signals that are available, that's all the. And those are sorts of things that we're starting to see more and more. With that, we'll have to talk about the harness you have viewed, talk a bit more about inspiration behind that, and how the largest private equity funds and the largest under 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 valuation and review and constructing your individual workflow. And we wanted to make all 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 like a red line term sheet in your laptop somewhere. And it is hard for people to understand what is the latest version.
It must not be 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 document, but like here's the individual word for why we know X was the answer. And if you know that on one document, 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 sources 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 coach in market in 2023, like when tools were just code completion tools, they read a fraction of what they were saying.
I admire Curse a lot as a company. And I remember when my friends came to dinner with a shaped head, they'd all shaped their heads for $1 million in AR. And that was like a big milestone. And now like you look at the market and many of them are passabillion in AR. But you don't really see that in like the professional services market set.
And the question is why? Is it that there isn't sufficient value? Like clearly not. Healthcare has so much work about its 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? It's 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 order. Type of work, then humans dropping rows like missing columns and not feeling the data. But they'll just like, you know, having this retain versus, you know, there's 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 buy code something and it's filled with bugs, like you get to roll back your PR in a way that's not true if you're making decisions in healthcare. Right.
So 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 you have sufficient guardrails, like how 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 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 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 you work habits.
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. Models can take free form text 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 plugin on TragPT 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 E-Bowl'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 reducto. And they'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 TragPTT plugin, like given the big model ads are also focused on knowledge work and they're also always improving the capability of their own models to be good at multimodality. And as well, why do you think this is not a problem that they will solve where it requires independent company reducto to really focus on it? Yeah, a lot of the work that we do is kind of tangential intelligence.
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. Even after probably looking at more PDFs than most humans, I still find corner cases that we didn't expect. Within PDFs, you can have folders of PDFs that contain other PDFs. 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 trying to build all these 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 info 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 like, 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 turn it into a studio-ghibli image. We know the domain of information that we're working on. We need our models to be exceptional on this specific set of tests. And so for our customers, when you're pressing at a scale where it's not just accuracy, like you need cost and lean-scale, we're 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 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 a long document. But usually it's a pipeline. We can have to decompose the document, 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, understanding the format, being able to translate it accurately and getting through all the great details to make sure 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 typical components of a pipeline and how does that maybe on the pricing latency compare to these one shot type of approach? There's actually a really interesting benchmark that Micra 1 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 reductive and specialized document parsers. And we found actually that frontier models were better than a lot of specialized document parsers at precision. Given that they were extracting something, they were more likely to be correct. But the failure mode was actually recalled for the frontier models. They would silently drop information.
That's the kind of thing that'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. We create a lot of tools for the model to be able to use to review some outputs to create validation roles.
Like if you have a massive invoice, how do you have a parent agent make sure that the item 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 your perfect accuracy there. And that applies across all sorts of stuff that we do like document splitting as well. Maybe you're touching on the benchmark piece. The benchmark can look great.
And we spend a lot of time benchmarking across all the real world scenarios. The micro one is representative of that. But sometimes they do missing the details to the customer themselves. Like how do you think your, I guess, what is it useful, eval for a benchmark look like when your customers are evaluating the reductal versus maybe open source models or like other frontier models to some more tasks? What do the care most about?
Yeah. And what do you think they should care most 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 if like how you even decide what to measure. Where we made a post about this recently. Like it's generally mistakes have really strict rules on 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 reductal this. So 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. Or I'm not going to name names where we tested 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 the average person is not going to go out to do. 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, which tools maybe to make that valuation easier. But instead of trusting like a generic benchmark, you really should be out of points where you know where it 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 evolve reductal on versus you kind of doing work? Does a golden data set needs to be good? I mean, I guess that's expectation. 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 LM generated, but for cost reasons, maybe they use SANA instead of focus and like SANA 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 there are other formats that it starts to go in and becoming more dominant and harder for LM to work with? It's actually kind of 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 sheets or like multiple spreadsheets with clusters all across. And models, even if they support a large enough context, but 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, but multi media type of assessing to it and break it down into image processing. It's a lot more generally like 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. Like how do you think about 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 so your points 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, but to characterize the individual data points, such that you can reason on those data points, that's a whole sub-domain of problems where we train like dedicated chart agents. I feel really good about saying reductives 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 doesn't have to think about it is our goal. Like the best version of reductives, one where you can kind of abstract away the PDF problems, even at the PDFs contained these like sub intricacies along the way. And then there are nested tables too. There are like many weeks out, there's multiple tabs. The more like we dive into these set of issues, the more I feel like it's an unbounded set of problems.
So with that, how do you think about over the, like, let's say the horizon of the next few years, what that's great that will become, I mean, you're known for the document processing capability and also the parsing accuracy and all that. As you're moving more into, I guess, you're in the harness, you're in the workflow, solving more longer horizon end to end problems. What do you think is the opportunity that people haven't realized? This goes back to what we were talking about in the beginning, but I think there's so much incredible work happening, both with AI natives and 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 reducted 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 of 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'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 inputting into the models.
One is data, which reducted is turning PDFs and documents into that data that fit into LMs. The other one is just compute that LMs can use to run out. So there's even opportunity to create value for lunch 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' trust thing, 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 essential for doctors to be able to capture information.
And they work with some of the harder situations in healthcare, so the point where these are physical documents, they will have packets that are 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, because the initial pipeline read something as chut pain instead of chest pain, somebody's claim gets rejected because the doctors searches where 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 that 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 adjudication decision. It's 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 the pages, but I interest of how tall the document is. And what's the rough accuracy of 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%. The best you can do is have some approximation of where information sits and then a human has to look at it. A given patient's packet could be tens of thousands of pages. And so even if you show the best examples, a doctor can't really dig into it. Those are sorts of friends here problems that I hope we can solve for the world.
Definitely. And what is the fallback today, I guess, if you miss the chest pain? People make mistakes all the time. There are millions of Medicare claims that are rejected every single year for PyRoth. 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 written.
80% of appeals. Wow. I found that to be unbelievable, but it extends not just in healthcare. If you look at the backlog that currently exists for USCIS, for immigration, so many of these are just paper processes that are bottlenecks by needing high enough accuracy that warrants a human today. That if you had an infinite aperture for accuracy and cost and lean C, such that you could just apply friends or models on these tests, 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 in human loop of work that can be automated today, but not yet. If I can really reliably understand, evaluate and change 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% of tax dollars still filed by a paper mill. It's all these things that just add weeks of work in a way that is kind of gross 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 customer's application layer that you think people should know? It really depends on the industry. Like in accounting, we're seeing basic, 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 BTO 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. Can't wait for more of these manual mundane and so sucking human in the loop work to go away and focus on more exciting things. Yeah.
Awesome. It's so great to have you. Thank you so much for coming by today. Thanks again. Thanks for listening to this episode of the A6D podcast.
If you liked this episode, be sure to like, comment, subscribe, leave us a rating or review, and share it with your friends and family. For more episodes, go to YouTube, Apple Podcast and Spotify. Follow us on X, A6D, and subscribe to our substack at A6D.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.
It 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 A6D fun. Please note that A6D and its affiliates may also maintain investments in the company's discuss in this podcast. For more details, including a link to our investments, please see a6D.com forward slash disclosures.