The machine can read hundreds of pages. What decides whether you can trust it is what it does with the page it couldn't read, the sentence with no source, and the line it didn't recognize.
Anderson Silveira · October 2, 2026
A debt enforcement case file brings together the contract, the debt instruments, notices, debt spreadsheets, and court filings. It often runs to hundreds of pages, part of them scanned. At a law firm that works on these cases, reading is the heavy lifting of the day.
The lawyers were already using AI to read, each in their own chat. It worked, and that set the bar for the product I built for them: it couldn’t deliver less than that workflow already did. What the chat left loose was everything else. A sentence without the page it came from forced the lawyer to reread the entire file to trust it.
This article is about reading files in bulk with AI: what the machine extracts, where it goes wrong, how to show the original next to the reading, and when a second pass is worth paying for. The examples come from the legal agent and from a distributor’s photo-based ordering, which is the same problem at a smaller scale: a handwritten note instead of a case file.
The path of a document
- 01Input
The lawyer drops in the documents and the case is created from them. The side, creditor or debtor, is a human choice.
- 02Before reading
The panel shows what the run will read, which document is image-only, and how much it should cost.
- 03Local OCR
Scanned pages go through text recognition on the server itself.
- 04Reading in chunks
Giant case files are read in parts, not all at once.
- 05Anchored findings
Every claim comes out with the verbatim passage, the document name, and the page.
- 06Checking
The human gate counts what still needs checking. Approval is an act with a name and a time.
What the machine extracts
In the legal agent, the reading doesn’t return a summary. It returns a structure the firm already used before the product, documented from how the lawyers worked in the chat.
Triage answers a yes-or-no question: “would I file today?”, with caveats, not an essay. Below it come the findings. Each one has a severity, an explanation, and its anchors: the verbatim passage in quotes, the document name, and the page, with a button to copy the passage.
One type of finding is worth more than the others: the documentation gap paired with the defense it opens up. “The protest is missing” isn’t enough. The value is in saying what the other side will do with that gap.
In the photo order, the extraction is simpler and follows the same idea. The reading runs in the background, matches each line of the note against the catalog, and returns a proposal: product, packaging, and quantity per line.
Where it goes wrong
Bulk reading fails in predictable ways. Designing the product means deciding, for each one, what the screen does.
| The error | How the system handles it |
|---|---|
| Inferring the side of the case from the text. Creditors and debtors use the same terms | The side is never inferred. It’s a human choice when the case is created |
| Unreadable scanned page | A declared limitation in the analysis, never silence |
| A claim without the page it came from | Treated as a serious bug. The human gate counts findings without an anchor |
| Rushed handwriting, abbreviations, a loose quantity at the end of the line | A doubtful line becomes a suggestion: “We’re not sure. Is this the one?” |
| A line that matches nothing in the catalog | Never guessed. It’s flagged in red and blocks the button until someone decides |
| The whole reading fails | The system retries with a larger model before giving up |
The first row is the most important, because it’s the most expensive error. Getting the side wrong would produce a filing defending the very party the client wants to collect from. No reading accuracy makes up for that, so the decision was taken away from the machine.
The original next to the reading
The rule that most protects the user is simple: never show only the reading. Show where it came from, in the same place.
In the legal agent, every finding opens with the verbatim passage and the page. The lawyer checks the source instead of rereading the file. Next to the analysis, the human gate shows how many references still need to be checked against the original and how many findings have no anchor. Until that reaches zero, the analysis is a draft.
In the photo order, the review screen puts the photo of the note at the top, with zoom, and each line shows what was written on paper next to what the system understood. When the order is confirmed, the original photo stays attached for the picker to check.
Size has a limit, and the limit has to show up first
Every reader has a limit per run: pages, file size, cost. What matters is where that limit shows up. Before the click, as information, or after it, as a failure.
In the legal agent, giant case files are read in chunks, and before any analysis the run panel shows what the run will read, which document is image-only, and how much it should cost, against how much is still left in the case’s budget. The estimate is worst-case, calculated from the largest run the case has had so far, and the screen says so. Every case has a budget cap.
When to reprocess with a larger model
A larger model reads better and costs more.
In the photo order, the rule is to escalate on failure. The first reading runs with the default model. When it fails, the system tries again with a larger one. Only then does it give up, and the line reaches the review flagged as unidentified.
The sequence matters: try cheap, escalate on failure, and give up visibly. The red line in the review is proof that the system stopped guessing. A reprocessing step that never gives up ends up inventing a reading just to avoid leaving a blank.
Test with the real file
A lesson from another project, the sales calculator, applies to reading too. There, proposal PDFs are generated in the browser, and the logic was tested. When the real PDF was rendered, an old bug appeared: the last column of the table spilled a few millimeters past the margin. Nobody had seen it because nobody had opened the file.
Bulk reading is the same. The test with the clean sample PDF passes. The real case file has scanned pages, a document that exists only as an image, and the note with a loose quantity at the end of the line. Validating on the final artifact, here, means running the reading on the real file, with a person checking the findings against the pages.
What I take away
The part of the AI that draws the most attention, reading hundreds of pages, was the part that called for the fewest decisions. The decisions were all around it: the side the machine doesn’t choose, the unreadable page that becomes a warning, the sentence that doesn’t count without a page, the red line that blocks, the cost that shows up before the button.
In the legal agent, the creditor’s full workflow was validated end to end on a real case, from triage to an approved draft on the firm’s letterhead. In the photo order, the reading is built and tested, and it stayed switched off in production at the client’s request until the real reading is activated. In both, what goes live is the pair: the reading and the check. Never the reading alone.
In The AI proposes, a human confirms, I go into where the approval sits. The legal agent case shows the screens.
Checklist for reading documents in batches
- Does the reading return checkable items, not running text?
- Does every claim come with its source beside it: passage, document, and page, or the original next to the reading?
- Does whatever the machine couldn’t read appear as a declared limitation?
- Does whatever it didn’t recognize block the flow, instead of becoming a guess?
- Do what the run will read and what it should cost appear before the click, against a cap?
- Did validation run on the real file, scanned pages included, and not on the clean sample?
If the reading arrives looking polished and nobody can say which page each sentence came from, the manual work isn’t gone. It just moved.