How Agentic OCR Tackles Three Million Pages of Messy Scanned Documents

When Documents Are No Longer "Clean PDFs": An Overlooked AI Deployment Bottleneck

Most people imagine AI document processing as "upload a neatly formatted PDF and ask it a few questions." But a hands-on talk by Palak, developer relations lead at Reducto, on Bilibili reveals a very different reality: the vast majority of documents inside enterprises are scans, have rotation angles, and are mixed with charts, tables, and handwriting—and frontier models perform far less gracefully on this kind of "dirty data" than they do in demo videos.

Reducto's positioning is clear—it's the layer before the model. Over the past three years, the company has raised $108 million from firms like ACC and Benchmark, processed more than 2 billion documents, and counts among its customers Harvey, Scale, and one of the world's top five hedge funds. Throughout the talk, Palak repeatedly emphasized one judgment: making AI handle clean PDFs isn't hard; the hard part is the stuff that actually lives in enterprise file rooms.

Rasterization + Agentic OCR: Letting Models "See Documents Like Humans Do"

Reducto's technical approach involves one key choice: a rasterization-based method. Put simply, it doesn't rely on the embedded information underneath a PDF—it treats documents as images, the same way humans read. This sounds plain, but it directly sidesteps the problem that a great many scanned documents have no structured text layer at all.

What really sets this approach apart from traditional OCR is its "agentic OCR framework." Traditional OCR does a single inference pass and gives an answer directly; Reducto's model actively flags uncertain areas, goes back to correct them, then moves on to the next step. Omar (one of the founding engineers) mentioned in the demo that this multi-step self-correction mechanism is the core of handling complex layouts and subjective reading order.

According to Palak, the platform offers five core capabilities: parse, split, extract, edit, and classify. Among them, parse is the foundation of the whole system—the subsequent splitting and extraction are all built on top of the parsing results.

Rasterization in this context refers to the process of rendering each page of a PDF into a pixel image (such as a PNG bitmap). A PDF is essentially a container of print instructions: text, graphics, and font positions are all described by vector commands, while scanned documents often contain only a single full-page image with no searchable text layer. Rasterization converts this layer of instructions or the image uniformly into a pixel matrix, so that subsequent models—whether facing native PDFs or scans—can process everything in a unified "image-reading" way. The cost is giving up metadata such as fonts and reading order that may exist in the PDF, along with significantly increased compute and storage overhead.

Agentic OCR, meanwhile, means treating a large model as a multi-turn "reading agent" rather than a single-pass forward-inference recognizer: the agent can first perform layout analysis on a page and generate preliminary recognition results, then crop and zoom into low-confidence regions, re-recognize or cross-validate them, and finally consolidate everything into a structured output. It handles rotation, skew, tables spanning pages, and mixed handwriting—situations where traditional OCR easily fails—but with higher inference cost and latency, so engineering typically requires batching, caching, and concurrent scheduling to balance things out.

The J-Mail Case: How Three Million Pages of Documents Became Dozens of Products

The most persuasive part of the talk is a real project. Last November, Riley Walls and Luke Igel built J-Mail—an interface product simulating the Epstein emails—in five hours. By this February, the series of sites had accumulated over 450 million visits and 18 million users. Reducto handled parsing more than 3 million pages of redacted PDFs, scans, and government files, covering complex forms, tables, and a great deal of handwriting from many different people.

Omar demonstrated the pipeline behind J-Flights (the flight records product): first parse all the flight documents, then apply a separate extraction configuration, and finally produce structured data. He also mentioned a detail—when the first wave of files was released, the team parsed through the night, putting considerable strain on the infrastructure, and an ops colleague messaged him in the middle of the night to "slow down." According to corroborating accounts from both Omar and Palak, it was precisely this parsed "ground truth" corpus that supported the subsequent derivatives like J-Amazon and J-Cal.

The Extraction Schema Is Your Paintbrush: The Path from Demo to Production

During the live Q&A, Omar used an apt metaphor: the extract schema is like your paintbrush on the Reducto canvas—it determines what you ultimately get. He demonstrated live the entire process of creating a resume extraction schema, uploading documents, and viewing results in real time—first validating accuracy on a small batch, then scaling to millions of documents once confirmed.

For schema generation, the platform offers two modes: the standard mode is a single LLM call that directly generates a JSON schema from a description, suitable for getting started quickly; the enhanced mode first parses the document content, then customizes the schema description based on the actual text, suitable for scenarios with detail requirements. Omar mentioned having seen schemas with 156 fields, with nesting depth limited to four or five levels.

The export step is equally simple: you can call the API directly, or generate a pipeline code snippet for quick deployment. In Omar's words, the core gameplay is simply "throw documents into the platform, see the data visualized immediately, then productize right away."

Schema (extraction schema) can be understood as a machine-readable "data contract": it declares field names, types, whether fields are required, enum values, nested structures, and so on, specifying what information should be extracted from documents and in what form it should be returned. JSON Schema is the most common description format, and the model uses it to map unstructured text into structured fields. The granularity of schema design directly determines downstream usability—fields that are too coarse lose information, while fields that are too fine increase model error rates and maintenance costs; overly deep nesting also amplifies the difficulty of locating information in long documents, which is why in practice nesting is often kept to four or five levels.

A companion concept, the evaluation set, refers to a batch of document samples with manually annotated correct answers, used to quantify field-level precision and recall of extraction. Because layouts and terminology vary enormously across enterprise documents, public benchmarks often fail to reflect the real distribution—which is why "first manually check a small batch, then systematically compare at scale" has become the standard path from demo to production.

Overlooked Challenges: Failed Redaction, Citation Tracing, and Evaluation Woes

The talk included a weighty discussion: Reducto parses PDF metadata and found that some files' redaction was not thorough—some had merely a black box drawn over the text, while the underlying information remained readable. The J-Mail team therefore had to do a great deal of additional sanitization work themselves. Palak admitted this brought heavy pressure of responsibility, because "data is redacted for a reason."

Another technical difficulty is citation tracing. Omar mentioned that in addition to the extraction model, there is a dedicated citation model responsible for locating the source of each piece of data in the original text. He also mentioned in passing that NVIDIA has a paper on "finding everything," which is precisely tackling the speed bottleneck of citation localization.

On the evaluation front, the team's answer was quite candid: the industry lacks a unified benchmark, and customers often need to build their own evaluation sets. The suggested path is to start with "vibe evaluation" (checking in Studio whether outputs look reasonable), then expand to 100 to 1,000 documents for systematic comparison. Palak said the company would release benchmarks in the near future, but also acknowledged that "you usually have to build your own benchmark."

Redaction in PDFs typically has two implementations: one truly deletes the underlying text objects, leaving only a black rectangle covering them; the other merely overlays an opaque graphic on the page while the original text remains in the content stream, so any tool that can read the text layer can recover it. The latter is a common root cause of leaks in many public documents. Therefore, before sending documents into a parsing pipeline, a "text layer versus rendered layer consistency" check is needed to confirm that sensitive information has actually been removed rather than merely visually obscured.

Citation/grounding requires that every field in an extraction result can be traced back to a specific location in the original text (page number, bounding box, or character span). This is not only a matter of trustworthiness but also a means of error correction: when a field doesn't match its source, the system can automatically flag it for human review. Technically it usually relies on a dedicated localization model or layout coordinate alignment; performing full localization across hundreds of pages is a challenge for both speed and GPU memory, which is why this step is often split out into a dedicated model.

What This Approach Means for Ordinary Developers

When answering a question about "custom logic," Omar pointed out the value of the agentic architecture: system prompts can be applied to different document types, letting specific models handle specific steps. For example, distinguishing different companies' logos in complex icon recognition, or handling hard-to-read layout information in architectural blueprints, requires customization at the layout prompt level.

As for model training, the team's answer offered no shortcuts—the data annotation team has to do a great deal of tedious classification work to support model iteration. Both Palak and Omar mentioned that long-context recall is an ongoing area of work; Omar described the extraction task as "not finding a needle in a haystack, but pulling every needle out of the sea."

Starting from the buzzworthy J-Mail case, what Reducto actually demonstrates is a general enterprise path: unstructured documents are everywhere—extract them accurately, and the rest of the imaginative space belongs to the product itself.