What an Agentic Document Pipeline Actually Is

"Agentic" has been applied to enough products that it no longer distinguishes anything on its own. In document processing it does describe a real architectural difference, and it is worth stating the difference plainly rather than in adjectives.

The distinction is not whether a large model is involved. It is whether the system is a single call that produces an answer, or a set of specialised steps that produce an answer and the evidence that it is right, with control flow between them.

The one-call approach and where it stops

The simplest design sends a page to a vision model with a schema and takes back JSON. It works remarkably well and it is the right starting point.

Its limits show up in production:

• The output has no evidence attached. You get values, not reasons, and no way to tell a good extraction from a confident guess.
• Errors are all-or-nothing. If one field is wrong, nothing localises it.
• Business rules live outside the loop. Violations are discovered downstream, after the document has moved on.
• Improving one field's accuracy by changing the prompt changes every other field too.
• Cost and latency are fixed. Easy documents pay the same as hard ones.

An agentic pipeline decomposes the problem so that each of these becomes addressable.

The components

Ingestion and normalisation. Decode whatever arrived, render page images, extract any text layer and its geometry, deskew, assess quality. Reject or flag pages that are unreadable here, at the cheapest point in the pipeline.

Splitting and classification. Find document boundaries within bundles and identify each document's type. Everything downstream is conditional on this being right, and it deserves its own confidence and its own review path.

Extraction. Per document type, against a schema. The important design choice is that extraction returns not just values but provenance: for each field, the page and region it came from, and a confidence.

Grounding. Verify that each extracted value is actually supported by the region it claims. This is a separate check, and it is the primary defence against fabricated values — the failure mode a single call cannot detect about itself.

Validation. Apply business rules: arithmetic that must reconcile, dates that must be ordered, formats that must match, identifiers that must resolve against a system of record, cross-document consistency within a bundle. Rules are deterministic, auditable, and free compared to inference.

Correction. For fields that fail validation or fall below confidence, attempt a targeted retry — re-read only the failing region, with the failure as context, possibly at higher resolution or with a different strategy. This is where an agentic design earns its keep: it converts a whole-document failure into a narrow, cheap second attempt.

Routing. Decide per field whether to auto-approve, send to review, or reject. This is the confidence-and-cost policy layer, and it should be explicit configuration rather than buried logic.

Human review. A queue where a person resolves what the system could not, seeing exactly the field in question against its source region.

Feedback. Reviewer corrections are captured as labelled data and used to improve prompts, rules, thresholds and the evaluation corpus.

Why decomposition is the point

Each component can be measured independently. When end-to-end quality drops, you can tell whether classification drifted, grounding started failing on a new format, or a validation rule became stale. In a single-call system the only available diagnosis is "accuracy went down".

Each can also be improved independently. Adding a validation rule does not risk regressing extraction. Swapping the extraction model does not disturb the review interface. This matters enormously over the life of a system, because the components change at very different rates.

And each can use the appropriate tool. Grounding is a search problem. Validation is arithmetic and lookups. Routing is a threshold policy. None of these need a language model, and using one for them is slower, costlier and less reliable than the obvious deterministic implementation.

That last point is worth emphasising because "agentic" is often taken to mean "let the model decide everything". The opposite is closer to true: a well-built agentic pipeline uses models where perception is required and ordinary code everywhere else, with the model's output constrained and checked by that code.

What "agent" adds beyond "pipeline"

If it were a fixed sequence of steps, "pipeline" would be the whole story. The agentic part is the control flow: the system decides what to do next based on what it has found.

• A document that fails a reconciliation check triggers a re-read of the specific region, not a rerun of everything.
• A page that looks like an unknown variant escalates to a different strategy instead of extracting against the wrong schema.
• A bundle missing an expected document raises a completeness exception rather than proceeding with a partial record.
• An easy document takes the short path; a hard one takes the expensive one. Cost tracks difficulty instead of being flat.

This adaptive routing is what produces both the accuracy and the cost profile. Uniform treatment of non-uniform documents is wasteful at one end and inadequate at the other.

What to ask a vendor

• Can I see the provenance for a given field — which page, which region?
• What happens when a validation rule fails? Is there a retry, and what does it change?
• Which parts of this are model calls and which are deterministic code?
• Can I add my own validation rules without an engineering engagement?
• How do reviewer corrections get used?
• Can I see per-stage metrics, not just end-to-end accuracy?

Systems built this way answer these easily, because the answers are the architecture. Systems that are one large prompt with a wrapper tend to answer in generalities.

When the simple version is enough

None of this argues against starting simple. If you have one clean document type, a modest volume, and errors that are cheap and self-correcting, a single well-specified model call plus a couple of validation rules is a perfectly good system, and building more is over-engineering.

The decomposition earns its cost when documents are varied, when errors are expensive, when a compliance function needs to see evidence, or when the system has to keep working as its inputs change. Which, in enterprise document processing, is most of the time — but it is worth being honest about which case you are in before building for the harder one.