**Agentic Document Parsing: A Deterministic Dispatcher for Enterprise RAG**
In enterprise Retrieval-Augmented Generation (RAG), few topics are more overhyped—and simultaneously more misunderstood—than “agentic AI.” The principle often boils down to a single idea: *let the model decide*. While this makes sense for a general-purpose assistant, it is dangerous for enterprise RAG pipelines where answers drive real decisions. In such contexts, we must know every step and control the flow between them.
This article takes that stance to the next logical layer: choosing the right parsing method for each document. Rather than letting an LLM decide, we build a **deterministic dispatcher** that reads a PDF’s nature, selects a predefined plan, executes each parsing method in order, and synthesizes every output into a single enriched corpus ready for retrieval, generation, and evaluation. Each decision is explicit, logged, and inspectable—so the plan can be reviewed before anything runs.
This article closes the parsing “brick” of the Enterprise Document Intelligence series, composing the methods developed across the series into one callable function: `parse_pdf_agentic()`.
—
## 1. Why the Scare Quotes on “Agentic”
Many RAG vendors now label their document-parsing loops as *agentic*. In practice, the implementation is almost always the same:
– A rule-based dispatcher reads a few file signals.
– It picks an ordered plan of parsing methods.
– Each step runs in sequence.
– Outputs are folded into a unified corpus.
Where LLMs appear is inside individual *leaves*—for example, a vision model for charts or an OCR post-processor. The dispatch layer itself does **not** use an LLM to decide what to run next. There is no feedback loop where an agent observes an output and replans.
Calling this setup “agentic” is, at best, buzzword inflation. At worst, it misleads. This article uses quotes to stay honest.
What we build here is a **rule-based dispatcher**—not a true agent—sufficient for most enterprise use cases. True agentic parsing, where an LLM can add, drop, or reconfigure steps on the fly, belongs in Volume 3 (Agentic Bricks) of this series.
—
## 2. The Document We Want to Use to Its Full Extent
Think of complex documents:
– 200-page contracts with dense rate tables
– Quarterly reports full of charts and footnotes
– Grant applications, patents, or NIPS papers with equations and results tables
Each defeats a single parsing method:
– **fitz** captures text but misses tables
– **Docling** captures tables but offers shallow outlines
– **Azure Layout** is strong on structure but ignores typography
– **EasyOCR / Mistral OCR** work on scanned pages but require explicit invocation
The series’ philosophy has always been “one method per problem.” That works at the method level—but it does not scale to the document level. In production, you do not want a caller to write a switch statement over parsers. You want one function call that returns a fully enriched corpus.
Two regimes exist:
1. **Ex ante (agentic) parsing** (this article): parse once, enrich fully.
2. **Lazy (adaptive) parsing** (a future article): retrieve first, parse on demand.
Both have their place. This article focuses exclusively on the first.
—
## 3. Nature, Plan, Execute, Synthesize
The loop has four deterministic stages. No LLM decides at the dispatch level. Instead, LLMs are used only inside individual parsing methods under fixed contracts.
### 3.1 Nature: A Coarse Read of the Document
The first step infers a lightweight `DocumentNature` model using:
– `line_df` and `span_df` row counts
– Presence or absence of a native table of contents
– Detection of a printed sommaire (dot-leader pattern)
– Document boundaries inferred from typography
– Image density
– Presence of a table grid signal
This stage is fast, rules-based, and entirely LLM-free.
### 3.2 Plan: From Nature to an Ordered Method List
`plan_parsing_methods(nature)` maps the nature to a hard-coded list of `MethodStep` objects. Each step records:
– The method name
– A one-line rationale
– Whether the step is optional or required
Two rules keep the plan honest:
1. **`fitz_native` always runs first.** Line and span frames are foundational.
2. **Optional flags are used sparingly.** Only heavy steps (e.g., vision LLM or OCR) are opt-out; required steps (e.g., TOC or layout) always run.
### 3.3 Identity Cards for Parsing Methods
Each parsing method is described using a consistent template:
– Family (blue = native text, teal = layout/table, amber = OCR, violet = structure/TOC)
– License
– Runtime, speed, LLM usage, typography exposure
– Input and output schemas
– Strengths and failure modes
These cards live both in prose and as PNG summaries under `book_1/_figures/…`, making them easy to reuse in reports or presentations.
### 3.4 Execute: One Call Per Method
A thin shim, `_run_step(step)`, adapts to each method’s signature. Optional steps that raise exceptions are logged and skipped; required steps abort the run. This keeps the pipeline observable and auditable.
### 3.5 Synthesize: One Enriched Corpus
Outputs from each method are merged into a single dictionary with:
– `line_df`
– `span_df`
– `toc_df`
– `image_df`
– `reference_df`
– `table_df`
Merging rules preserve the most informative version of each key. The dispatcher does not reimplement domain-specific reconciliation—that stays inside each method module.
—
## 4. A Real Run on the Attention Paper
Running `parse_pdf_agentic()` on `data/paper/1706.03762v7.pdf` yields:
– **Nature:** `native-with-outline`
– **Plan:**
1. `fitz_native` (mandatory)
2. `fitz_native_toc` (mandatory, from built-in `get_toc()`)
3. `toc_body_structure` (advisory, adds deeper headings)
4. `image_pipeline` (optional, skipped)
– **Result:**
– 15-row `toc_df`
– 1048-row `line_df`
– 3480-row `span_df`
– No image or reference data
The run required one text extraction pass, one TOC pass, and one lightweight body-structure pass—no OCR, no vision LLM, no Docling.
—
## 5. Cost, and When Not to Use It
Agentic parsing is not free:
– A 15-page paper costs milliseconds.
– A 300-page contract with tables, figures, and no native outline can cost minutes and real money.
Use agentic parsing for:
– Contracts reviewers will read end to end
– Papers you want to search deeply
– Documents where completeness matters
Use adaptive (lazy) parsing for:
– Corpus-scale ingestion
– Documents where most pages will never be queried
The two regimes coexist; the caller chooses based on use case.
—
## 6. What This Closes and What Comes Next
This article closes the parsing brick of Enterprise Document Intelligence. A caller can now invoke:
“`python
corpus = parse_pdf_agentic(pdf_path)
“`
and receive a fully enriched corpus with all available frames. Every method from the previous articles has a place in the dispatcher, and the output becomes the input for retrieval and generation in later stages.
Two follow-ups are available:
– Stubs for `azure_layout`, `docling_local`, `easyocr_scan`, `mistral_ocr`, `vision_llm_figures`, and `image_pipeline`
– A future article on adaptive (lazy) parsing
Case 4 from Article 5octies (body-structure TOC reconstruction) pairs with this article to complete the brick.
—
## FAQ
**Q: Is this truly agentic?**
A: Not in the strict sense. The dispatcher is rule-based; LLMs live only inside individual parsing methods. This is why we use quotes.
**Q: Can I add my own parsing method?**
A: Yes. Implement the method to accept and return the standard frames, register it in the plan matrix, and the dispatcher will invoke it like any other step.
**Q: What happens when an optional step fails?**
A: The exception is caught, logged on the step output, and execution continues. The enriched corpus will simply lack that method’s contributions.
**Q: How is the “more informative” frame selected during synthesis?**
A: The merger compares row counts and column compatibility, keeping the version that contributes more structured data while preserving schema alignment.
**Q: When should I use adaptive parsing instead?**
A: When ingesting large corpora where most pages are never queried, or when you want lazy, demand-driven parsing to save cost.
—
## Conclusion
This article delivers a deterministic, inspectable, and auditable approach to document parsing for enterprise RAG. By reading a PDF’s nature once, planning an ordered sequence of proven parsing methods, executing them with robust error handling, and synthesizing their outputs into a single enriched corpus, it closes the parsing brick of the Enterprise Document Intelligence series.
The result is a practical production pattern that balances completeness, cost, and controllability—without leaning on buzzwords. Together with the upcoming adaptive parsing article, it equips you to choose the right regime per document, ensuring that every file gets exactly the parsing it deserves.
