Document intelligence for AI agents

Document intelligence turns a set of documents into facts a system can act on. Extraction, the core of intelligent document processing, reads each document and returns its fields one at a time. A lending, claims or compliance decision also depends on whether those fields agree, describe the same party and period, and cover every document the case needs, so an AI agent should not write anything until that has been checked across the whole packet.

Key facts

Definition

Document intelligence for an AI agent checks extracted fields across the whole packet, so a write rests on one party, one period, figures that agree and no missing document.

How Bigcircle does it

1. Bigcircle resolves every party to one entity and reconciles the figures that should agree, recording a conflict instead of choosing a winner.
2. Bigcircle keeps a page and a span on every value, so a reviewer can open the source and an unsupported value cannot reach a write.
3. Bigcircle runs a policy gate in code that sends each case to a write, a review, or a request for the missing document.

Comparison

Intelligent document processing returns fields one document at a time, while a lending, claims, or compliance decision depends on whether those fields agree across the packet.

Key number

On DocVerse, Bigcircle's ESG filings pipeline, the analysis cycle went from weeks to hours, by Bigcircle's own measurement.

We put a reasoning layer between extraction and action that resolves entities, reconciles figures, checks completeness, keeps a page and span on every value, and passes a policy gate before any write.

The hard part is that extraction can be excellent and the decision still wrong. A model can read every pay stub in a loan file correctly, and every bank statement too. The borrower's stated income can still fail to hold up, because the deposits do not match the pay, a month of statements is missing, or the employer on the stubs is not the one on the application.

None of those failures shows up in a field-accuracy score, because each document was read correctly. The error lives in the relationship between documents, and a pipeline that stops at extraction hands that relationship to whoever reads the output next. Usually that is a person doing the comparison by hand, page after page, which is the work the system was bought to remove.

The second difficulty is that the wrong answer looks right. DocVerse, the ESG filings pipeline we built and which is now in production, was designed around a passage that states a correct number for the wrong subsidiary, the wrong reporting year, in thousands rather than millions, or against a superseded framework version. The value is real and the citation resolves, so no downstream reader can tell the answer is wrong.

This guide draws on DocVerse and on FinSight, a fund-operations reconciliation platform we built and tested end to end, not yet in production. Loan, claim and compliance packets appear as illustrations, and where a regulator's own rules set the checklist, the guide cites them. It closes with how to evaluate the whole case, where people stay in the loop, and when all of this is more than you need.

How is document intelligence different from intelligent document processing?

In the market the two names usually describe the same product: an OCR and machine-learning service that reads a document and returns its fields. Intelligent document processing (IDP) is the industry's name for that category. We draw the line somewhere else, because extraction stops at the edge of each document and an agent's decision does not. In this guide, document intelligence means the layer an agent needs on top of extraction.

Extraction answers a question about one document: what does this page say? An action answers a question about a case: what is true about this borrower, this claim or this supplier, given everything in the file? The second question needs the documents compared with each other, and extraction never does that comparison.

This figure is our framework. Its lending documents and fields illustrate the shape of the problem rather than any client's schema, and it carries no measured result.

Four kinds of cross-document failure pass a check on each document, which is how they reach the decision. The table sets them out with the reason a per-document check misses each one.

Test for this before you buy or build an extractor, with a check Alberto Gimeno put well from the vendor side: hand the system a complete loan file and ask whether the borrower's income holds up across every document in it. A system that answers with fields and no verdict has left the comparison to a person, and that person becomes the cross-document layer whether or not anyone planned for one.

How is a document packet different from RAG over documents?

A packet workflow and chat over documents both read documents with a model, and there the likeness ends. Our guide on why RAG systems fail in production covers the chat case, where a user asks a question and the system retrieves passages to answer it. A packet workflow starts from a case with a checklist, and has to account for every document in it.

Of the differences in the table at the top of this page, completeness changes the engineering most. Retrieval is allowed to ignore documents that look irrelevant, and ranking decides which ones are read. A packet workflow must read everything, because the document a ranker would skip is often the one that contradicts the others. Treat the packet as a closed set with a manifest, a list of every document the case should contain, and check every step against it.

What does the packet pipeline look like?

The pipeline has eight stages, and each adds something the next one checks. The model reads and proposes matches, while code resolves, checks and writes. We draw the stages separately because each fails in its own way, and a failure should point to one stage in the record rather than to the AI as a whole.

This figure is a framework showing the stage order and the three routes out of the pipeline. It does not describe the internals of any product.

Parse without flattening#

A table converted to a text blob keeps the numbers and loses what each number is a figure of, and footnotes that qualify a figure end up pages away from it. On DocVerse we built layout-aware parsing that keeps sections, tables and footnotes in their original structure, with footnotes still attached to what they qualify. Every later stage depends on that decision, and structure lost at parsing cannot be recovered in a second pass.

Pick a parser that returns structure with stable IDs, and keep that structure and those IDs all the way to the write, because the grounding later points at them. Parsers built for agents now do this directly, returning a hierarchy of pages, blocks, lines and words with an ID on every block; LandingAI's second-generation Agentic Document Extraction (September 2026) is one. A parser that returns only text forces you to rebuild positions afterwards, and a rebuilt position is a guess a reviewer cannot trust.

Extract with spans and confidence#

Extraction fills a typed schema per document type, and every field carries its value, the span it came from, a confidence score, and the extractor version that produced it. The schema is a contract, and structured output with a validator on it keeps the model from inventing fields or returning prose where a date belongs.

Confidence is a routing signal, not a diagnostic. On DocVerse every extracted field carries a score, and a low one flags the value for review instead of passing it downstream as fact. Without that, analysts face a choice between trusting everything and re-deriving everything, and they will sensibly choose the second.

This matters most on scanned annexures, rotated tables and footnotes three pages from their figure. Most of the tuning work there goes into making low confidence actually fire, rather than letting the parser produce a confident wrong reading.

Resolve entities across documents#

Entity resolution decides which names, accounts, addresses and employers refer to the same real party. Match on hard keys first, such as a policy number, a tax ID or an account number. Let the model propose fuzzy matches only where no key exists, such as "Smith, Jane" against "Jane Smith" at the same address, and record each proposal as a link with its evidence rather than a silent merge.

Some domains have no key at all. On FinSight the same economic event appears in two custodian feeds (statements from the banks holding the fund's assets) with different identifiers, different timestamps and sometimes different amounts. Deciding whether two records are the same event is a judgment the system has to encode as explicit matching rules, and those rules are versioned like code because they hold the domain knowledge.

A false merge is the most expensive error in the pipeline, because every later check compares one party's figures with another's and can find them consistent. On Prospex, our own prospect research engine, the failure we design against is a profile that is coherent, well sourced and about the wrong person, which every downstream check passes. In a packet pipeline that is the reason to send a match below the business's threshold to review rather than merge it.

Reconcile across documents#

Reconciliation compares values that should agree and records the result either way. Stated income against pay stubs, pay stubs against deposits, a loss date against the date on the incident record, and a certificate's expiry against the audit date are each a rule someone can write down. Keep those rules in code, versioned, with a tolerance the business owns.

When values disagree, the pipeline records a conflict rather than quietly choosing a winner. A written source precedence rule can settle some conflicts, such as a bank statement outranking a figure the applicant stated, and the rule has an owner. Conflicts no rule settles stay open.

FinSight holds an unresolved break as its own record with a lifecycle until someone resolves it, and never nets it into a total so the numbers balance. A netted break is the worst failure available there, because the total still looks correct.

Check the packet is complete#

Check completeness against the checklist for the case type before any conflict is judged. A missing document is a finding with its own route, which is to ask for it. Judging a conflict on a partial file wastes review time, and the missing document often settles the conflict when it arrives.

For lending, the checklist often comes from the investor's rules rather than from the team. Fannie Mae's Selling Guide, as read on 22 October 2026, asks for bank statements covering the most recent full two-month period for a purchase loan, or one month for a refinance (B3-4.2-01).

The most recent paystub must be dated no earlier than 30 days before the initial application and show year-to-date earnings (B3-3.2-01). Credit documents can be no more than four months old on the note date (B1-1-03). Rules like these catch the gaps that are easy to read past. Two months of statements where one covers only half its period, a paystub 31 days old, and an identity document that expired last week all look complete to a reader skimming the file. Each needs a rule, and the rules belong to the team that owns the process.

How do filings change across years?

A loan file is one case at one moment. Filings add time, and the cross-document question becomes whether a figure means the same thing it meant last year. DocVerse pairs a knowledge graph with vector search for this. Pure vector search cannot express "the same subsidiary two years earlier," and pure graph traversal cannot find the narrative claim that was never structured.

The questions analysts ask are comparative, and one retrieval cannot answer a comparison. DocVerse breaks a question into parts, picks sources for each, combines graph and vector evidence, and checks each claim before attaching its source.

A new filing is also checked against what the knowledge base already holds, so a restatement shows up as a flag instead of as two figures that both look true. FinSight treats a restated custodian statement the same way, as a new record linked to the old one, because an audit asks what you believed at the time.

Framework versions are the slow failure. DocVerse records the mapping version on each mapped fact rather than holding it globally, so a later comparison can separate a real change from a definitional one.

Build that per-fact version in now if you handle European filings, because 2026 figures will arrive under mixed versions. The revised European Sustainability Reporting Standards (ESRS), which companies in scope of the EU's Corporate Sustainability Reporting Directive (CSRD) apply, appeared in the EU's Official Journal on 21 September 2026 as Delegated Regulation (EU) 2026/1563. They apply to financial years starting on or after 1 January 2027, and a company with a 2026 financial year may use the old standards, the old standards with reliefs, or the revised set.

The sustainability statement has to name the version it applied. Two companies' 2026 figures under the same disclosure name can therefore rest on different versions, and a pipeline that holds the version globally would compare them as if they matched. Recording it per fact lets a revision comparison answer the question an auditor asks: did this number move because the company changed, because a document was restated, or because we changed how we read it?

How do you ground every value to a page and span?

Grounding means every value an agent might act on can be opened at the place it came from. Store it as a citation on the value itself: the document ID, the page, the block or span ID from the parser, the coordinates on the page, and the extractor version. A reviewer clicks the value and sees the highlighted span.

Derived values carry the lineage of every input they were computed from. An average monthly income over two pay stubs points to both spans and to the rule that computed it. A figure with no path back to a page is treated as unsupported, however plausible it looks. Apply that rule at the gate rather than at display time, so an unsupported value cannot reach a write. DocVerse enforces the same rule at generation: a conclusion without its citations and source-page links is not presented as a fact, even when it is probably right.

Grounding also decides how quickly a reviewer can judge a contradiction. A conflict shown as two numbers asks the reviewer to go and find both. The same conflict shown as two highlighted spans, side by side, can be judged without leaving the screen.

We made lineage a property of the data on both DocVerse and FinSight, written as each value moves rather than assembled for an auditor afterwards. Lineage cannot be added later to figures computed without it, and a pipeline that drops the span at any stage has a hole that will be found at audit.

On DocVerse lineage holds as designed. The groundedness entry covers scoring whether an answer is supported by its sources.

What should validation check after extraction?

Validation runs fixed rules over the extracted and reconciled values before the gate sees them. A model can read a date wrongly, and a rule can tell that a policy start date after its end date is impossible. Rules are fast, repeatable and easy to review, so everything that can be a rule should be one.

Model-based checks come after the rules and handle what rules cannot, such as whether a free-text description of damage fits the claimed cause. Their output is a flag with a reason and a span, and never a verdict. On DocVerse the same split applies to framework mapping, where rules encode the parts that are definitional and must not be probabilistic, and classifiers handle the rest.

What should the gate check before an agent writes?

The gate is the last step before an agent's tool call changes a system of record. It runs in code, in a fixed order, and the first failure decides the route: request a document, send to review, or deny. An agent that passes the gate writes through a narrow tool, and the tool records which evidence justified the write.

This figure is an illustrative model of a claims gate. The order is the one we recommend, and the checks are examples. Your checklist and tolerances come from the team that owns the process.

Each position in the order has a reason. Completeness goes first because a missing document can settle a conflict, and grounding next because an unsupported value cannot be reconciled. Identity follows because every later comparison assumes the parties are resolved. Conflicts are judged only once those three pass, and policy runs last because it decides whether this agent, for this case, may write at all.

The policy check is a permissions question, and our guide on AI agent permissions covers binding each write to a person, a task and an expected state. The agent never gets a general write tool that can change any field. It gets typed tools such as "set claim status to approved for payment", with the case ID and the evidence set as arguments, and the tool refuses a write the gate has not cleared.

Soft cases, such as an entity match just above threshold, can go to a decision model, which answers a typed question with a probability instead of text, which our guide on introducing Jev into agentic workflows covers. Hard failures route in code without asking anything.

Every route writes a decision record: the case, the checks run, the evidence set, the route taken, and who or what decided. Claims regulation expects that record to exist. The NAIC's property and casualty claims model regulation (Model 902) asks for detailed documentation in each claim file so the insurer's activity on the claim can be reconstructed, with each document noted by the date it was received, processed or mailed.

Size the review queue against claim deadlines too, because a case parked in review still runs the clock: the same model regulation sets 15 calendar days to acknowledge a claim and 21 days to accept or deny after proof of loss, and each state adopts its own version. Our guide on building an AI audit trail sets out the record.

What does this look like on a loan, claim or compliance packet?

Start each packet type from its cross-document question rather than its document list, because the question decides which reconciliation rules you write and the list only decides what you parse. The pipeline stays the same, and what changes is the checklist, the reconciliation rules and the write. The three packets below are illustrations of where the cross-document work sits. They describe no client's process and carry no results from any engagement.

On the loan file, the question is income, and it spans at least three documents. The pipeline resolves the borrower and employer across them, then reconciles stated income against pay against deposits for the same months. A missing statement month stops the case and asks for it before anyone reads the rest.

On the claim, the dates carry most of the risk, so build those checks first. The loss date must fall inside the policy period, the invoices must sum to the claimed amount, and the claimant on the form must resolve to the policyholder. The write is a status change, and it happens only after every value it depends on has a span a reviewer could open.

On the compliance packet, entity resolution does most of the work. A SOC 2 Type 2 covers a named service organisation's system and tests its controls over a stated period, so one issued to a parent company, or for a different system, can read correctly and apply to nothing in scope. Compare the entity, the system and the period named in each one with the supplier under review, because a per-document check passes all three.

How do you evaluate cross-document reasoning?

Evaluate the case, not the field. A field-accuracy score tells you the extractor reads documents well. It cannot tell you whether the pipeline catches a contradiction, notices a missing document, or merges two people who are not the same, and those are the failures that reach a decision.

Field-level measurement still belongs at the first layer, where precision and recall per field tune the extractor. A case-level eval set sits on top of it, built from real packets with the answer a senior reviewer would give.

Real packets contain few of the failures you most need to catch, so seed the set with them. Add a packet with one statement month removed, a second with a pay figure altered, and a third with a name variant that belongs to a different person. Each seeded case has a known right answer, so the measures below mean something.

Our guide on LLM evaluation covers building the set from real failures and when a model judge is justified. For packets, most checks can be exact, because the right route for a seeded case is known in advance.

Where do people stay in the loop?

People review the cases that earn their time, and the review queue is built around the evidence. A reviewer sees the conflict or the low-confidence value with the spans side by side, the rule that fired, and the route the pipeline proposes. Their decision is recorded with a reason and becomes a labelled case for the eval set. FinSight places access and approval on exception resolution for the same reason, because that is the one step where human judgment enters the data.

Every rule in the pipeline has a named owner. The business owns the checklists, tolerances and source precedence rules and changes them through review like code, while engineering owns the pipeline and its gates. A tolerance changed in a spreadsheet outside that process silently changes every future decision, and the audit record will not explain it.

Watch review volume for each check as well as in total. A check that sends most cases to review is either catching a real problem or set too tight, and the overturn rate tells you which. A check that never fires may be broken.

FinSight's design watches break rate per custodian for this reason, since a sudden drop in breaks is as suspicious as a spike. Our guide on AI agent governance covers how a route earns the right to write without review, and how it loses that right when its evidence drifts.

On DocVerse the analysis cycle went from weeks to hours. That is an internal working result, and it came from an automated pipeline replacing multi-week manual extraction and spreadsheet work, not from any one check described here.

When does a document workflow not need cross-document checks?

When one document drives the action and a person approves it. An invoice that a clerk checks before payment, or a contract summary a lawyer reads, needs good extraction with spans and confidence, and the person is the cross-document check. Chat over documents for research, where the reader acts on the answer, belongs to the RAG guide rather than this one.

Once an agent writes to a system of record from more than one document, every stage here applies. Start with completeness and grounding, because without them a reviewer cannot tell a missing document from a contradiction, or check either one against the page.

Common questions

What is document intelligence?#

Document intelligence turns documents into facts a system can act on. Most products sold under the name, such as Azure Document Intelligence, extract fields from one document at a time with OCR and machine learning. An AI agent that writes from a packet of documents also needs those fields resolved to one party, reconciled across documents, checked for completeness and grounded to a page before it acts.

How is document intelligence different from intelligent document processing?#

Intelligent document processing reads one document at a time and returns its fields. Document intelligence, in the sense this guide uses, reasons across a set of documents. It resolves the parties, reconciles figures that should agree, checks the packet is complete and routes the case to an action. An agent needs the second before it can act safely on the first.

Why can't an AI agent act directly on extracted fields?#

Because the fields can each be right and the case still wrong. Stated income may not match deposits, a name may belong to a different person, a figure may come from the wrong year, or a required document may be missing. None of those shows up in a per-document check, and each changes the decision.

How is cross-document reasoning different from RAG?#

RAG retrieves a few passages to answer a user's question and may ignore documents that look irrelevant. A packet workflow starts from a case and a checklist, must account for every document in it, and treats a missing document as a finding. Its output is a routed action with open conflicts listed, rather than an answer with citations.

What does grounding to a page and span mean?#

Every value carries a citation to where it came from: the document ID, the page, the block or span ID, the coordinates on the page and the extractor version. A reviewer can open the value and see the highlighted source. Derived values point to all their inputs, and a value with no path back to a page is treated as unsupported.

How should an agent handle contradictions between documents?#

Record the conflict with both values and both spans, and settle it only by a written source precedence rule that the business owns. Conflicts no rule settles stay open and go to review, shown side by side. The pipeline should never choose a winner quietly or net a difference away so totals balance.

What should happen when a document is missing from the packet?#

The pipeline should stop the case and request the specific missing item before it judges any conflict. A missing document often settles the conflict when it arrives, and judging a partial file wastes review time. The checklist that defines completeness belongs to the team that owns the process, and in lending it often follows the investor's own document rules.

How do you evaluate a document intelligence pipeline?#

Measure the case rather than the field, starting from real packets with the route a senior reviewer would choose. Then seed the set with removed documents, altered figures and name variants. Track conflict recall, missing-document detection, false merges, grounding coverage, route agreement and reviewer overturns, alongside field accuracy for the extractor.

Where should people review document-driven decisions?#

On conflicts, low-confidence values, uncertain entity matches and any write the policy gate reserves for a person. The review screen should show the rule that fired, the spans side by side and the proposed route. Each decision is recorded with a reason and added to the eval set.

Further reading

• Why RAG systems fail in production. The chat-over-documents case this guide is distinct from.
• How to set AI agent permissions and access control. Binding each write to a person, task and expected state.
• How to build an AI audit trail. The decision record each route writes.
• Rolling out AI agent autonomy. How a route earns the right to write without review.
• How to build LLM evals. Building the case set from real failures.
• How to introduce TypeSafe's Jev into agentic workflows. Asking soft gate questions as typed judgments with probabilities.
• DocVerse: per-field confidence and the claim-to-evidence path. Layout-aware parsing, versioned framework mapping and page-level lineage.
• FinSight: lineage as a data property. Matching with no shared key, breaks held as state, and restatement as a linked record.
• Fannie Mae Selling Guide, B3-4.2-01 Verification of Deposits and Assets, B3-3.2-01 Standards for Employment and Income Documentation and B1-1-03 Allowable Age of Credit Documents, read 22 October 2026.
• NAIC, Unfair Property/Casualty Claims Settlement Practices Model Regulation (Model 902). Claim file documentation and the model time limits.
• European Commission, Delegated Regulation (EU) 2026/1563 on the revised ESRS, published 21 September 2026.
• Alberto Gimeno, Forbes Technology Council, Document AI's shift from reading pages to reasoning across them, 18 September 2026. The complete-loan-file test, put from the vendor side.
• LandingAI, Introducing Agentic Document Extraction, 2nd Generation, 8 September 2026. Hierarchical parse output with stable block IDs.