AI Engineer World's Fair 2026

From Ingestion to Agents: How AI Teams Build on Document Intelligence — Adit Abraham, Reducto

Read the talk

From Ingestion to Agents: How AI Teams Build on Document Intelligence

Adit Abraham of Reducto explains how to turn visually encoded documents into useful agent inputs: combine specialized models, correct OCR without rewriting the source, separate retrieval from reasoning, and give difficult extraction tasks tools and a verification loop.

From a talk by Adit Abraham

At a glance

Ideas worth remembering

  • Combine efficient layout detection with VLM interpretation where visual complexity requires it; large models need not process every part of every page.

  • OCR correction should preserve what the document says, including its mistakes. Targeted token edits reduce the opportunity for a model to rewrite the underlying facts.

  • Format data for each consumer: natural-language table renderings for retrieval, and structure-preserving representations for reasoning.

  • Tool use and repeated verification can make difficult extraction tasks tractable, but extraction quality must include both correctness and completeness.

  • Evaluate individual stages and completed agent work, using production monitoring as well as test datasets. Agents choosing tools still need good inputs, relevant context, and usable outputs.

When documents become inputs to decisions

A bad document parse can spoil a chatbot answer. In an agent workflow, the same mistake can travel through several decisions and into the finished work. That is the practical problem behind Adit Abraham’s talk. As Reducto’s co-founder and CEO, he draws on processing many billions of customer documents, including historical material that enterprises have struggled to use beyond a demo.

Source frame: When documents become inputs to decisionsOpen full source frame
Source frame: When documents become inputs to decisions

The earlier retrieval-augmented generation pattern mostly synthesized information: retrieve context, then answer a question through enterprise search or a chatbot. Agents expand the job. They make decisions, produce work, and generate or modify documents. Input quality matters throughout that longer sequence because each step can carry forward an earlier misunderstanding while adding information from another source.

Enterprise information also arrives without a tidy inventory. Different teams put files in Google Drive, Box, and other repositories; the contents are scattered, unstructured, and multimodal. A useful document system therefore has several jobs: recover the contents accurately, retrieve the relevant context, and support the interactions or modifications the task requires. Parsing is the first problem, but it does not settle the others.

0:210:57
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

0:13 · section reference included

PDFs preserve appearance; agents need meaning

PDFs were designed to reproduce a document’s appearance faithfully and make it printable. The present task asks for something different: a representation an agent can reason over. Abraham introduces the difficulty with a document-decision benchmark on which a frontier model scored about 30%. That figure describes the benchmark he cites, rather than a general PDF accuracy rate.

Source frame: PDFs preserve appearance; agents need meaningOpen full source frame
Source frame: PDFs preserve appearance; agents need meaning

Humans encode meaning visually. A financial deck’s author is thinking about readers, rather than whether an agent can consume the slide. Abraham’s memorable example is SoftBank’s imagery of a goose laying eggs: a picture can carry part of the explanation. More routinely, merged cells establish relationships in tables, lines encode numerical trends, and handwriting holds information that even a human may struggle to read. Extracting characters alone can leave those relationships behind.

5:285:33
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

5:28 · section reference included

Use vision models selectively, then correct the transcription

A traditional document pipeline ran OCR and then processed the resulting text. That approach could work well when the layout stayed consistent: a W-2 presents a constrained problem that templates can address. Vision-language models (VLMs) widened the possibilities by reading visual content across unfamiliar layouts, with handwriting as a particularly useful case. Their generality makes the long tail more approachable.

Source frame: Use vision models selectively, then correct the transcriptionOpen full source frame
Source frame: Use vision models selectively, then correct the transcription

At hundreds of millions of documents, however, efficiency and determinism also shape the design. The work can be divided between complementary capabilities:

  • Layout detection: Small computer-vision models identify document regions and can run on CPUs at scale. They help locate the difficult parts before more expensive processing.
  • Semantic interpretation: VLMs handle challenging visual content and help identify mistakes that simpler processing leaves behind.

This division gives each task a suitable tool instead of making every region depend on a large foundation model.

Once the page has been segmented and difficult regions located, a verification layer can play a role similar to a human reviewer. Reducto calls this agentic OCR. The important decision is to apply targeted token edits to an initial transcription, rather than ask a model to regenerate the whole page. Abraham compares the approach to fast edits in an IDE: preserve the existing output and change the small pieces that need correction.

Why restrict an intelligent model’s freedom? Consider a table with a total that its human author calculated incorrectly. A model rewriting the OCR can recognize the word “total,” add the entries, and replace the printed value with the correct arithmetic result. The output becomes less faithful precisely because the model understood the table. The desired correction is narrower: distinguish 0 from O, or a period from a comma, while retaining the source’s own mistake. Reading a document and checking its arithmetic are separate jobs.

7:307:32
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

7:23 · section reference included

The table needs different forms for retrieval and reasoning

A correct parse still needs a useful representation. Simple tables fit naturally in Markdown. Complex tables may need HTML because merged cells encode relationships that must survive conversion. HTML preserves that structure, but its tags consume tokens; applying it to every simple table adds overhead without a corresponding benefit. Reducto chooses the representation according to the table’s complexity.

Source frame: The table needs different forms for retrieval and reasoningOpen full source frame
Source frame: The table needs different forms for retrieval and reasoning

Now follow that complex table into retrieval. A user asks, “how did revenue change over time,” without enumerating the table’s values. The reasoning model may understand the HTML perfectly once it receives it. The embedding model first has to find it among many documents, though, and Reducto finds that matching an ordinary language query to a mass of tags and numbers is difficult. A representation that serves reasoning can therefore obstruct the step that supplies the reasoning context.

The change is to create a second, natural-language rendering of the same table. Retrieval uses that block; reasoning uses the structured HTML. What does each consumer receive? The diagram makes the division visible: the retrieval-friendly text helps select the relevant table, while the reasoning-friendly form preserves its relationships. This addresses the matching problem without requiring the reasoning model to work from the natural-language rendering alone.

Two representations of one complex table

Complex tableMerged cells carry meaning.
Natural-language renderingretrieval — Content formatted for the embedding model.
Retrieve relevant contextretrieval — Match the human query to the table.
HTML tablereasoning — Preserve the complex table’s structure.
Reason over the tablereasoning — Pass the HTML representation to the language model.
Natural-language content serves retrieval; HTML structure serves reasoning over the selected table.
Read the diagram as text
  • Complex table. Merged cells carry meaning.
  • Natural-language rendering. retrieval — Content formatted for the embedding model.
  • Retrieve relevant context. retrieval — Match the human query to the table.
  • HTML table. reasoning — Preserve the complex table’s structure.
  • Reason over the table. reasoning — Pass the HTML representation to the language model.
  • Complex table → Natural-language rendering: Render in words.
  • Natural-language rendering → Retrieve relevant context: Use for retrieval.
  • Complex table → HTML table: Encode structure.
  • HTML table → Reason over the table: Use for reasoning.
  • Retrieve relevant context → Reason over the table: Supply the relevant table.
10:4510:49
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

10:45 · section reference included

Better inputs reduce reconstruction work; routing reduces distraction

Returning to the document-decision benchmark, Abraham reports that supplying structured parse results alongside the original PDF improved answers across models from Google, Anthropic, and OpenAI. Some tested models surpassed the earlier frontier model’s out-of-the-box result. The comparison does not establish what that earlier model would do with the same improved inputs: Reducto could not test it after losing access.

Source frame: Better inputs reduce reconstruction work; routing reduces distractionOpen full source frame
Source frame: Better inputs reduce reconstruction work; routing reduces distraction

The reported benefit also included fewer reasoning tokens and lower latency. Structured inputs let the model spend less effort reconstructing the data and more effort producing the answer. Improving the input pipeline can thus change both the quality and the amount of downstream work, without changing the model itself.

The next improvement concerns which documents enter the task. A large context window does not make every page helpful; Abraham describes quality erosion from excessive context as well as token cost. Two operations address different parts of that problem:

  • Classification: Route the right document to the appropriate processing pipeline.
  • Splitting: Select the relevant portions of a large document instead of passing the entire packet.

A paper-mail packet can run to hundreds of pages with uncertain contents. Making the final decision model sort through that packet adds a separate job that distracts from extracting information, reasoning over it, or making the intended decision.

13:2713:31
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

13:12 · section reference included

A line chart becomes a table through repeated reconstruction

Line charts expose a harder extraction problem. A vision encoder may retain the broad trend in revenue while losing the pixel-level detail needed to recover individual data points. The chart contains a potentially large table, but a rough visual reading does not recover that table. Abraham presents a case his team could not solve with a single model response.

Source frame: A line chart becomes a table through repeated reconstructionOpen full source frame
Source frame: A line chart becomes a table through repeated reconstruction

The agent harness changes the task from a one-shot reading into an iterative reconstruction. The agent has a code interpreter and can visualize the chart it generates from extracted data. It examines that reconstruction, finds mistakes, and revises the extraction repeatedly. The reported result is a Markdown table recovered from the original line chart, with a plotted reconstruction shown in the presentation. The talk does not give a numerical error tolerance for the recovered points, so the example demonstrates the method rather than establishing exact numerical recovery.

Where does the improvement come from? The loop below makes the generated chart inspectable before the table is accepted. Tools give the agent a way to expose errors in its proposed data, and repeated checks let it change that proposal. The useful capability is the whole loop—extraction, execution, visualization, and correction.

Structured extraction can use a similar harness. A parent agent sets validation criteria for subagents, which matters when a form contains tens of thousands of fields and omissions can remain silent. Abraham describes a benchmark tradeoff: frontier models at maximum reasoning were precise about the rows they returned, yet dropped substantial content; dedicated document services recovered more content while making more errors in what they extracted. Precision asks whether returned content is correct. Recall asks how much required content was recovered. Reducto reports that its harness improved both for this task, though the talk supplies no scores to quantify the gain.

Chart extraction with a verification loop

Original line chartVisual lines encode individual data points.
Proposed table dataverification-loop — Extract and revise the chart’s data.
Generated chartverification-loop — Use the code interpreter and visualize the reconstruction.
Find mistakesverification-loop — Inspect and repeat correction.
Final Markdown tableThe reported output of iterative chart extraction.
The agent visualizes its proposed data, finds mistakes, and revises the extraction before producing the final table.
Read the diagram as text
  • Original line chart. Visual lines encode individual data points.
  • Proposed table data. verification-loop — Extract and revise the chart’s data.
  • Generated chart. verification-loop — Use the code interpreter and visualize the reconstruction.
  • Find mistakes. verification-loop — Inspect and repeat correction.
  • Final Markdown table. The reported output of iterative chart extraction.
  • Original line chart → Proposed table data: Extract.
  • Proposed table data → Generated chart: Plot with tools.
  • Generated chart → Find mistakes: Inspect.
  • Find mistakes → Proposed table data: Revise and repeat.
  • Find mistakes → Final Markdown table: Finish after iteration.
16:3816:42
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

16:10 · section reference included

Evaluate each stage, then let agents choose the document tools

Evaluations should guide these design choices at two levels. Off-the-shelf datasets provide a test bed, while production monitoring catches the differences between a constructed dataset and the documents users actually submit. Within the pipeline, parsing, retrieval, and final formatting each need attention. Perfect parsing cannot help an agent that receives the wrong context. The final question remains whether the changes improve the agent’s completed work.

Source frame: Evaluate each stage, then let agents choose the document toolsOpen full source frame
Source frame: Evaluate each stage, then let agents choose the document tools

The closing architecture moves some orchestration into the agent itself. Abraham describes customers giving agents a file system to navigate and a CLI through which they can choose document tools as needed. A document no longer has to follow one predetermined end-to-end flow. The agent decides whether it needs to read a particular document and which operation to apply.

That interface separates readable content from metadata. The content field supplies what the agent needs to read; metadata retains information such as bounding boxes for citations. This gives the agent useful text while preserving a way to locate the supporting material in the original document. Editing receives only a brief mention, and document generation is presented as a direction for the coming months rather than an explained capability in this talk.

Abraham’s final recommendation is to reconsider the workflow as capabilities change. Decompose parsing to balance accuracy, cost, and latency; use verification to catch errors; format data for its consumer; classify and split before downstream work; and evaluate every stage. The file-system example extends those choices: tools and document representations can remain well defined even when the agent chooses the sequence in which to use them.

19:0119:06
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

19:01 · section reference included

Transcript download
Read the transcript and explore slides

Loading transcript and slides…