Reading a document is a loop.

The forward pass that cannot check itself

A single-pass reader has one shot at the page. It runs, it produces a string per field, and it attaches a number that people treat as certainty. The trouble is what that number actually measures: it is the model's confidence in the characters it transcribed, not in whether the value belongs in that field, whether it agrees with the rest of the document, or whether the region it came from was the right region. A reader can be extremely confident about a perfectly transcribed number it pulled from the wrong column.

That gap between transcription confidence and result correctness is where most production failures live, and they have a recognisable shape. A table splits across a page break and the continuation rows lose their header, so the columns shift by one. An invoice has both a subtotal and a total and the reader returns whichever appeared first. A handwritten amendment overrides a printed value, and only the printed one is picked up. A multi-column layout reads across the columns instead of down them, producing a sentence that is grammatically fine and semantically nonsense. None of those defects lowers the character confidence, which is precisely why a confidence threshold never catches them.

The workaround most teams reach for is a rules layer bolted on afterwards: check the sum, check the date range, check the format, reject if a rule fails. It helps, and it is worth having, but it is structurally limited in one way that matters — it can tell you the answer is wrong, and it cannot go back to the page and find the right one. The rules layer detects; it has no path to recover. Everything it detects becomes a human's problem.

The reframe is small and consequential. Reading a document is not a transformation you apply once. It is a task with a goal, a set of observations that can be revisited, and a stopping condition — and that is the shape of a loop, not a forward pass.

What agentic OCR actually is

Agentic OCR is not "OCR with an LLM behind it." It is a reading process organised as a ReAct-style loop: the system observes the page, decides what it still does not know, acts to find out, and repeats until it can defend the answer or admit it cannot. Five stages make up the cycle. They are worth separating, because teams routinely implement two of them, call the result agentic, and inherit the failure modes of the three they skipped.

The ordering is not decorative. Grounding is meaningless without a layout map, because "where did this come from" has no answer until the page has a structure to point into. Validation is weak without grounding, because a contradiction you cannot localise cannot be repaired — you know something is wrong and have nowhere to look. Correction without validation is just re-running the model and hoping for a different answer. Each stage exists to make the next one possible.

Perceive: judge the page before trusting the read

The first stage asks what is actually there, at the resolution of a region rather than a document. A page is rarely uniformly good or uniformly bad: the header is crisp, one corner is in shadow, a stamp crosses the signature block, someone wrote over the printed amount. A single page-level quality score averages all of that into a number that describes none of it. Region-level perception means the pipeline can say "this document is fine except the block containing the total," which is the difference between rejecting a whole document and re-examining one area of it. This is the same instinct as checking the image while the camera is still open, applied after the fact: the earlier a defect is localised, the cheaper every subsequent decision becomes.

Structure: parse the layout, not just the text

Documents carry meaning in their geometry. A number's position in a table, the column it sits under, the section it falls in, whether it appears above or below a subtotal line — that is the semantics, and a reader that flattens the page into a stream of characters throws it away and then guesses it back. The structural stage produces an explicit map: what is a table and where its cells lie, what is a heading, what the reading order is, where one section ends and the next begins, which rows on page 4 continue the table that started on page 3. Most of the expensive extraction failures in production are structural failures wearing a transcription costume, which is why this stage buys more accuracy than another point of character precision ever will.

Ground: bind every value to its evidence

A field with no source is a claim, not an extraction. Grounding requires the system to record, for every value it emits, the page and region it came from and the text that supports it. This is what makes hallucinated values structurally detectable rather than a matter of vigilance: a plausible-looking date that cannot be traced to a region on the page fails the grounding check regardless of how confident the model was. It is also what makes the rest of the loop possible, because a correction step needs somewhere specific to look, and it is what makes the output defensible later — the same discipline as keeping an evidentiary record of every non-deterministic decision. Grounding converts "the model said so" into "here is the pixel region it read."

Validate: check the document against itself

Validation in a loop is not a downstream rules engine; it runs inside the read, and its output is a named contradiction rather than a verdict. Some of the checks are arithmetic — the line items sum to the subtotal, the subtotal plus tax equals the total, the balance carries forward between pages. Some are internal consistency — the period on the statement contains every transaction date, the currency symbol matches the declared currency, the invoice number in the header matches the one in the footer. Some are cross-field logic — a termination date after a start date, a quantity times a unit price that reconciles with a line total. The critical design decision is that a failure must name what contradicts what. "Confidence 0.71" gives the correction stage nothing; "line items sum to 4,180 but the stated subtotal is 4,810" tells it exactly which region to re-read and what to look for.

Correct: repair what is repairable, escalate the rest

The final stage is where agentic OCR earns its name and where most implementations get sloppy. Correction is not re-running the extraction and hoping. It is a targeted second look, driven by the named contradiction: re-read the specific region at a higher resolution, check whether a digit transposition explains the arithmetic gap, look for a continuation row below the page break, test whether an adjacent column produces a consistent result. Crucially, the loop must be able to conclude that a failure is not recoverable — a genuinely illegible block, a document that contradicts itself because the original is wrong — and route it to a person with the contradiction attached. A loop that can only succeed is a loop that will eventually invent a success.

A confidence score tells you how sure the model is about the characters it read. It tells you nothing about whether the value belongs in that field. The loop exists to answer the second question, which is the one automation actually depends on.

Making the loop terminate

The failure mode of agentic reading is the mirror image of the single-pass failure mode. Instead of one cheap answer nobody can verify, you get an expensive one that took nine attempts, cost more than the document is worth, and still needed a human. Four rules keep the loop useful rather than indulgent.

Budget the loop explicitly

Every iteration must be paid for, so give the loop a ceiling — attempts, tokens, wall-clock, or all three — and make exceeding it an outcome rather than a hang. A document that has consumed its budget without converging is not a system failure; it is the loop correctly reporting that this page needs a person. The budget should also scale with what the document is worth: a high-value contract earns more iterations than a routine receipt, which is the same cost-per-successful-task arithmetic that governs the rest of an agentic pipeline.

Correct narrowly, never wholesale

When validation names a contradiction, the repair should touch the implicated region and nothing else. Re-running the whole document because one total disagreed is expensive, non-deterministic, and actively dangerous — the second pass can change fields that were right the first time, and now you have two answers and no way to choose. Narrow correction keeps the blast radius equal to the defect, and it keeps the diff reviewable: this field changed, for this reason, on this evidence.

Require evidence for every revision

A corrected value with no new grounding is not a correction; it is the model changing its mind. The rule that makes self-correction safe is that a revision must arrive with the region it now reads from, and that region must actually support it. Without that constraint, a loop under pressure to satisfy an arithmetic check will produce the number that makes the sum work — which is exactly the behaviour the loop was built to eliminate, now with extra steps and more confidence.

Instrument every iteration

A loop you cannot see is a loop you cannot tune. Each stage, each contradiction found, each correction attempted and its outcome should emit a trace, in the same way you would trace any multi-step extraction pipeline. The operational value is immediate: iteration counts per document type tell you where the model is weak, recurring contradictions tell you which validation rules are miscalibrated, and the ratio of successful corrections to escalations is the honest measure of whether the loop is paying for itself. Without traces you have a black box that is slower and more expensive than the one you replaced.

Four ways it goes wrong

The teams that get burned by agentic OCR tend to make the same four mistakes.

Calling a retry a loop. Running the extraction twice and comparing the outputs is not verification — it is sampling. Two passes that disagree tell you there is a problem, and two passes that agree tell you nothing, because a systematic misread of a shifted column reproduces perfectly on the second attempt. Without a validation stage that checks the result against the document's own claims, more passes buy consistency, not correctness.

Validating without grounding. A pipeline that detects a contradiction but cannot locate the values involved has no path to repair. It can only lower a score and forward the document to a person, which is the rules-layer outcome with the cost of an agentic one. Grounding is what turns detection into recovery; skipping it keeps the price and loses the benefit.

Letting the loop optimise the check instead of the answer. If the stopping condition is "validation passes," a sufficiently capable model will find values that make validation pass. This is the most dangerous failure in the whole design, because the output looks better than a single-pass result — internally consistent, arithmetically clean, confidently wrong. The evidence requirement is the guard, and it is not optional.

Running the full loop on every page. Most documents are clean and need one pass. Spending five stages and three iterations on a legible, well-structured invoice is how a pipeline becomes too expensive to run at volume, and it is why the loop should be triggered by a failed check rather than applied by default. The route-by-difficulty thinking that governs template versus zero-shot extraction applies here unchanged: cheap path first, loop when the cheap path cannot defend its answer.

The trade-off nobody states out loud

Agentic OCR trades cost and latency for defensibility, and that trade is real in both directions. Every extra stage is compute, every iteration is time, and a loop that a fast single pass would have satisfied is money spent proving something you already had. Push it everywhere and you build a reader that is materially more expensive per page and slower to return, and at high volume that shows up in the unit economics long before it shows up in the accuracy report. Refuse it entirely and you keep the cheap forward pass while exporting its cost to the review queue, to the exceptions team, and occasionally to a customer who was billed from a total the reader took out of the wrong column.

The honest position is that the loop is worth it exactly where the cost of a wrong field exceeds the cost of checking — and that this is a per-document-type judgement, not a platform setting. A payment instruction, a contract clause that changes an obligation, a regulatory filing, a claim that pays out: those justify perception, structure, grounding, validation and correction on every field, because a silent error is the expensive outcome. A routine attachment a human will glance at anyway does not. The mistake is not choosing one over the other; it is applying either one everywhere. The systems that work route by what the field is used for, and reserve the loop for the values that decide something. This is the same confidence-and-outcome routing that governs the rest of the pipeline, applied to how hard the reader is allowed to work.

What this means for document AI specifically

For a document platform, the loop is not a feature in front of the extractor. It is the extractor's contract with everything downstream.

The output stops being a string and becomes a claim with evidence. A field that arrives with its page, its region, the checks it passed and the corrections it survived is a different object from a field that arrives with a number attached. Downstream systems can act on the first one automatically and route the second to a person, and that distinction is what actually raises straight-through processing — not another point of character accuracy.

Escalations become useful instead of demoralising. A human reviewer handed "low confidence, please check" has to redo the entire read. A reviewer handed "line items sum to 4,180, stated subtotal is 4,810, both regions highlighted, two corrections attempted and rejected" is answering a specific question with the evidence in front of them. The queue gets shorter and each item in it gets faster, because the loop did the localisation work before giving up.

The reader carries its own audit trail. Because every value is grounded and every revision is evidenced, the record of how a field came to hold its value is a by-product of reading rather than a logging feature added later. When an auditor asks why a system paid a particular amount, the answer is a region on a page and the checks it passed — the same shift from answer to checkable step that reasoning models brought to the rest of the stack.

Closing thought

The single-pass reader is optimised for the wrong moment. It is fast and cheap at the instant of reading, and it pays for that everywhere else — in the exceptions queue, in the reconciliations that do not reconcile, in the automation that nobody quite trusts to run unattended because occasionally it is confidently wrong and there is no way to know which time. The loop spends more at the moment of reading, and buys back a result that can defend itself. The difference between the two is not how well the model recognises characters. It is whether the system is allowed to look again.

At Cogneris we build document AI as an agentic loop — perceive the page, parse its structure, ground every value in the region it came from, validate the result against what the document itself asserts, and correct or escalate with the contradiction attached — so the fields that reach your systems are the ones that can be defended. If you are automating decisions off extracted values, or your reviewers are drowning in "low confidence" items with no explanation attached, see how agentic extraction works, the pricing page, or talk to our team. A reader that cannot check itself is a reader you have to check.