Before an AI Agent Can Think, It Has to Read

Enterprise AI can only reason over what it can read. Here’s how Donkit rebuilt its document reader to turn complex PDFs, scans, tables, and images into structured, agent-ready knowledge — faster, cheaper, and more reliably.

How Donkit rebuilt its document reader to turn complex enterprise files into accurate, structured, agent-ready knowledge

Enterprise AI is usually discussed in terms of intelligence.

Which model should we use? How large should it be? How well can it reason? Can it call tools, plan tasks, and coordinate with other agents?

Those questions matter. But before an AI agent can reason over company knowledge, it must first understand that knowledge.

And that is where many enterprise AI systems are not yet perfect.

The information employees rely on is rarely stored as clean, nicely structured text. It lives inside scanned contracts, financial reports, presentations, spreadsheets, diagrams, screenshots, tables, footnotes, and PDFs whose formatting seems to have been designed as a stress test for software engineers.

A model may be extremely capable, but if the ingestion system misses a table, misreads a scanned page, or ignores information embedded inside an image, the agent is reasoning over an incomplete version of reality.

Sometimes enterprise AI does not have an intelligence problem. It has a reading problem.

The most rebuilt part of our platform

Of all the moving — and supposedly static — parts of the Donkit platform, our document reader has probably undergone the most changes.

It has not simply been upgraded. It has been redesigned. Repeatedly.

One of our earliest versions was tested by two engineers on completely different machines. One was running it on an old Windows laptop using only the CPU, because the laptop did not have a suitable GPU at all. Another was running the same reader on a MacBook. Naturally, each implementation worked very well on the machine where it was being developed. Making it work reliably on both machines was a slightly different exercise.

That early challenge reflected a larger problem we would keep encountering: document understanding is not one task. A proper enterprise reader must handle many different problems at once:

• Extracting normal digital text
• Recognizing scanned text through OCR
• Preserving document structure and page boundaries
• Understanding tables
• Identifying headings, code, formulas, and footnotes
• Interpreting diagrams and embedded images
• Processing many file formats consistently
• Producing output that an agent can retrieve, cite, and reason over

A simple text extractor is not enough.

The first moment it felt like magic

The first major breakthrough came when we deployed a server-based version that could reliably read most common business file formats, including information embedded inside images.

During product demonstrations, we would upload a PDF into Donkit and ask a question about something that appeared only inside a chart, diagram, or scanned image.

The system returned the answer as text.

For the person watching the demo, it looked simple. Upload a file. Ask a question. Receive an answer. Underneath that interaction was a hybrid document-understanding pipeline combining several different techniques.

Layout-aware document extraction

The reader identifies document elements such as:

• Paragraphs
• Headings
• Tables
• Lists
• Code blocks
• Formulas
• Captions
• Page boundaries

This matters because documents are not just collections of words. Their visual structure carries meaning.

A number inside a financial table means something different from the same number inside a footnote. A heading defines the context of the paragraphs below it. A page reference determines whether an agent can properly cite its answer. Flatten everything into one large block of text, and valuable context disappears.

OCR for scanned documents

Many enterprise documents do not contain usable digital text. They may be scanned contracts, photographed pages, old reports, signed forms, or PDFs created from images. For these files, the reader uses optical character recognition with multi-language support. This allows the same system to process scans in different languages by default — an important capability for international companies and multilingual document collections.

Vision-based image understanding

Some information cannot be recovered through OCR alone. A diagram may communicate relationships visually. A chart may contain trends that are not written anywhere in the surrounding text. A presentation may use screenshots instead of editable elements. For these cases, the reader can send pages or embedded images to a fast vision model, which converts their meaning into structured descriptions that the agent can search and use.

We also cache image descriptions. When an identical logo, diagram, or repeated image appears multiple times, the system does not analyze and charge for it again.

The goal is not merely to “see” an image. The goal is to translate visual information into useful, traceable context for an AI agent.

From document extraction to agent-ready knowledge

Today, the Donkit reader supports more than 20 file formats, including:

• PDF
• Microsoft Word
• Microsoft Excel
• Microsoft PowerPoint
• Images
• HTML
• JSON
• Plain text

The final output is converted into clean, structured, page-aware Markdown or JSON. That structure can then be chunked, indexed, searched, cited, and used by an agent.

Different use cases can also use different reading strategies. Some documents only need layout-aware extraction. Others benefit from a combination of standard extraction and vision-based image descriptions. For heavily scanned or visually complex PDFs, every page can be rasterized and processed through a vision model.

There is no single reading strategy that is optimal for every document.

That principle mirrors Donkit’s broader approach to RAG and context engineering: there is no universal pipeline that performs best for every dataset and every use case. The system must adapt.

Accuracy was only the first battle

Once the reader became reliable, we moved to the next problem.

Speed.

Then cost.

Because Donkit is not building a PDF chatbot.

RAG is one component of our prompt-to-agent platform. A customer can describe the agent they need, provide access to the relevant company data, and let the platform build and evaluate the underlying knowledge infrastructure.

That may require reading large document collections before testing more than 100 combinations of retrieval strategies, chunking approaches, models, prompts, rerankers, and other components.

At that scale, “the reader works” is not a sufficient production metric.

The reader must be:

• Accurate
• Fast
• Economical
• Fault-tolerant
• Multi-tenant
• Deployable across different infrastructure environments

So we continued rebuilding it.

Intelligent CPU and GPU routing

Document understanding can be computationally demanding, especially when OCR, page-layout analysis, table recognition, and vision models are involved. Using GPUs for every small file would be wasteful. Using CPUs for every large batch would be slow.

Our reader therefore routes workloads according to their size and complexity. Small documents can be handled directly on CPU. Larger ingestion jobs are sent to GPU-accelerated workers with larger batches for OCR and layout analysis.

The GPU workers can start when they are needed, scale the workers when needed to process the batch, return results file by file, and shut down afterward. This helps us pay for accelerated infrastructure when it creates real value, rather than keeping expensive capacity idle.

And when GPUs are unavailable, overloaded, or unsuitable for a customer’s environment, the reader can fall back to CPU processing. That is especially important for private cloud and on-premises deployments, where hardware availability cannot always be assumed.

Fast where the user feels it

Not every document should be sent through the entire ingestion pipeline. When a user attaches a small Word or Excel file during a chat, waiting for a full knowledge-base workflow would make the experience feel unnecessarily slow.

For smaller office documents, Donkit can parse the file synchronously and insert its content directly into the agent’s context — up to approximately 15,000 tokens. The attachment feels immediate. Larger files still go through the complete ingestion pipeline, where they can be processed, structured, chunked, indexed, and made available for retrieval.

The infrastructure should adapt to the task. A two-page attachment should not be treated like a corporate document archive.

Fairness in a multi-tenant platform

Speed is not only about raw processing performance. It is also about what happens when several customers use the system at the same time. Imagine one company uploading hundreds of documents into a knowledge base while another user attaches a small file to a live chat.

Without proper workload isolation, the second user may be forced to wait behind the first company’s bulk ingestion job. That is technically functional. It is also a terrible user experience.

We introduced separate processing queues for interactive chat uploads and bulk document collections, each with its own worker capacity. We also added per-account fair-share dispatch, so one large customer cannot consume the entire queue and starve everyone else.

When a document finishes, the next eligible job is dispatched immediately. A watchdog monitors documents that may have become stuck or orphaned, preventing files from remaining in a permanent “processing” state.

This is not the glamorous part of AI engineering. Nobody posts a dramatic product video about database-backed fair-share queues. But this is the engineering that turns an AI prototype into a reliable enterprise platform.

Document reading became a platform capability

Over time, document reading evolved from an internal ingestion step into a reusable capability for every agent built on Donkit.

Custom agents can call a read_document() function programmatically.

A user-built agent can receive a scanned PDF, send the heavy OCR and layout work to the ingestion infrastructure, and receive the extracted result without implementing its own document-processing stack.

The important change is architectural. Reading is no longer just something that happens when a knowledge base is created. It is a platform primitive that agents can use whenever they encounter a new document.

The latest stress test

In July 2026, we rolled out another major overhaul of the reader.

This version is faster, less expensive, and capable of running on a single small GPU.

To stress-test it, we processed a 300 MB batch containing 37 SEC Form 10-K filings. A 10-K is the annual report that publicly traded companies submit to the U.S. Securities and Exchange Commission. These files are often long and structurally complex, containing dense text, financial tables, charts, footnotes, exhibits, and multiple formatting styles.

The result:

• 37 SEC 10-K filings
• 300 MB total
• One small GPU
• 4.5 hours of processing
• Two file errors
• Both errors recovered automatically
• CPU fallback verified successfully

The latest version performed better than the previous generation. It also introduced stronger file isolation, so a corrupt document does not interfere with the other files in the same batch.

In production, autoscaling will add multiple workers when demand rises, allowing larger workloads to run in parallel and reducing total processing time.

The test was not meant to produce a theatrical “millions of files per second” headline. It was meant to answer more practical questions:

• Can the reader process complex financial documents reliably?
• Can it recover from errors without human intervention?
• Can it keep working when GPU capacity is unavailable?
• Can it scale economically in production?

Those are the questions that matter when enterprise AI leaves the demo environment.

Why document reading matters for enterprise agents

Donkit’s mission is to free people from repetitive work that relies on existing knowledge, so they can focus on creativity, strategy, and generating new ideas.

For that vision to work, AI agents must be able to operate on real company information.

Not only the clean files.

Not only the newest files.

Not only the files whose important information happens to be available as digital text.

They need to understand contracts, reports, spreadsheets, presentations, scans, tables, and images.

They need to know where an answer came from.

They need to preserve permissions and document boundaries.

And they need to continue working when infrastructure becomes busy or an individual file is broken.

The intelligence of an enterprise agent begins long before the model generates an answer.

It begins at ingestion.

It begins with structure.

It begins with reliable reading.

We will probably rebuild it again

The document reader may never be the most visible part of Donkit.

Customers will notice the agents, the answers, the automations, and the speed at which a use case moves from an idea to production.

They may never see the routing decisions, OCR batches, queue isolation, image caching, fallback mechanisms, or recovery logic underneath.

That is fine.

Good infrastructure is often invisible. It simply works. But when an agent answers a question correctly because it understood a chart hidden inside page 47 of a financial report, the document reader is part of that success. That is why we have rebuilt it so many times.

And knowing our engineering team, this probably will not be the final version. There is always another PDF waiting to humble us.