Intelligence Beneath the Surface: How Ocrolus uses agentic loops to write self-correcting document processing code

TL;DR: Ocrolus uses a methodology called agentic-driven development to automate financial document processing: AI agents generate code through iterative feedback loops, tested against 10 years of labeled ground truth data, until the outputs are production-accurate. The resulting code replaces LLM inference at the processing layer, runs deterministically and self-corrects when performance degrades. Applied to bank statement parsing, this approach covered 600-plus banks in a single week at roughly $40 per bank.

The first attempt is always wrong. That is the baseline fact of modern AI agents on code generation: initial attempts fail nearly every time. Building around that assumption rather than against it is what separates companies getting scalable, verifiable output from those still trying to prompt their way to accuracy.

At Ocrolus, that assumption sits at the foundation of a methodology called agentic-driven development. An AI agent generates processing code, tests it against ground truth data, fails, receives annotated errors and revises. The loop runs until the code is production-accurate. What comes out is committed, inspectable code that runs without LLM inference, scales without GPU cost and is auditable at every step. Ten years of labeled financial documents across hundreds of banks and document types are what make the loop converge fast enough to be commercially useful.

Why inference-time processing breaks down at scale

The document-by-document inference model works at low volume. Feed a bank statement to an LLM, extract transactions, get a result. It prototypes quickly. At production scale, it creates three compounding problems.

Inference costs multiply. Every document is another set of tokens consumed. For lenders processing hundreds of thousands of applications per month, that spend has no natural ceiling.

LLM performance is unpredictable at the document level. A bank statement from a well-known institution may be processed accurately; a structurally similar statement from the same bank may cause hallucinations. There is no reliable way to determine in advance which documents will produce accurate output and which will not. In underwriting workflows where consistent, auditable results are required, that unpredictability is a fundamental liability.

Explainability erodes. When a credit decision or mortgage condition needs to be traced to a specific calculation, pointing to a model’s internal reasoning is operationally difficult. Code does not have that problem. When processing logic lives in committed, inspectable code, every output traces to a specific rule.

The structural move Ocrolus made was to use LLMs to write the code rather than to run as the code. That single change addresses all three problems.

How the loop works

An agent receives a batch of ground truth examples, real financial documents paired with verified correct outputs, and attempts to write processing code. The first attempt fails. Errors are identified, annotated and returned to the agent. The agent revises. The loop runs, typically 30 to 50 iterations, until the code achieves 100% accuracy on a held-out validation set. The full process generally completes in a few hours using a capable reasoning model.

What determines whether the loop converges is the quality and depth of the ground truth data driving it. A bank statement parser has to handle every formatting variation a bank has ever produced: different layouts, missing fields, irregular pagination, edge cases that only surface at high volume. Without labeled examples covering that variability, the loop has no signal to improve against. Ocrolus has been accumulating that labeled data set since 2014. Applying this methodology to bank statement parsing, Ocrolus covered 600-plus banks in a single week at roughly $40 per bank, exceeding three years of manual template coverage built with the prior approach.

The loop architecture is something any competent engineering team could build. A decade of labeled financial document data to drive it to production accuracy is a different problem entirely.

How the system detects and corrects errors

Code deployed through these loops is monitored continuously. A sample of live documents routes to a validation layer, a combination of LLM reviewers and human auditors, that tracks accuracy against the original ground-truth baseline.

When performance degrades, whether from a bank reformatting its statements or a document type introducing a new variation, the system detects it. An agent is booted, given the new error set, runs the correction loop and redeploys the corrected code. No engineering ticket, no sprint cycle, no manual template update.

The same loop model now covers entity aggregation, tax document parsing and fraud signal detection. Each follows the same logic: identify a workflow where the processing output is knowable but input variability makes hand-coding impractical, build a ground truth set and run the loop.

What comes next

The methodology is being extended into underwriting analytics and mortgage conditioning, two workflows where the same architecture applies and the stakes are considerably higher.

Mortgage conditioning involves reviewing loan files against agency and investor guidelines to generate the set of requirements a borrower must satisfy before closing. The process is manually intensive, highly variable across loan types and investor overlays and requires outputs traceable to specific guideline citations. That combination of high input variability, structured output requirements and a hard auditability standard is where the loop model is being applied.

The same architecture is being extended to underwriting analytics, moving from document-level extraction to the analytic outputs that inform credit decisions directly.

Where the engineering time goes

Agentic-driven development is running a significant portion of the infrastructure that processes roughly 750,000 credit applications per month at Ocrolus. The engineering teams previously maintaining the manual template system are now working on fraud models, underwriting analytics and higher-order automation. Automating the maintenance layer is what makes that shift possible. For context on the broader technical stack this builds on, the series has previously covered the inference layer in production lending, how Ocrolus maintains accuracy through observability and evals and when to deploy LLMs versus specialized models at scale.

Key takeaways

• AI agents fail on initial code generation attempts nearly every time. The companies getting scalable output build feedback loops around that failure rather than trying to eliminate it.
• Agentic-driven development uses iterative loops, typically 30 to 50 cycles, to produce committed, inspectable processing code that replaces LLM inference at the document processing layer.
• Ground truth data is the differentiator. Ocrolus has accumulated 10 years of labeled financial documents that give its feedback loops enough signal to converge reliably on production accuracy.
• Code-based processing is faster, cheaper at scale and fully auditable. Every output traces to a specific rule, which matters when credit decisions and mortgage conditions need to be justified.
• The same loop architecture now extends beyond bank statement parsing into entity aggregation, tax document parsing, fraud detection and underwriting workflows.

FAQs

What is agentic-driven development? 

Agentic-driven development is a methodology where AI agents generate, test and iteratively refine processing code using real-world ground truth data as feedback. Rather than running an LLM on every document at inference time, the agent produces committed code that handles document processing permanently. Ocrolus applies this approach across bank statement parsing, entity aggregation, tax documents and fraud detection.

How do agentic loops work in financial document processing?

An agent receives a batch of labeled ground truth examples, attempts to write processing code, receives annotated errors when it fails and revises. The loop runs, typically 30 to 50 iterations, until the code achieves 100% accuracy on a held-out validation set. The full cycle generally completes in a few hours. Once deployed, the code runs without ongoing LLM inference costs.

Why is ground truth data important for agentic AI loops?

Ground truth data is what gives the feedback loop its signal. Without labeled examples that cover the full range of input variation, the agent has no mechanism to reliably improve its code. A bank statement parser must handle hundreds of formatting variations; an entity aggregator must recognize thousands of abbreviations and naming patterns. Ocrolus has accumulated 10 years of labeled financial documents, which is why its loops converge to production accuracy faster than a recently assembled data set would allow.

What is the difference between LLM inference and code-based document processing?

LLM inference runs a model on each document at processing time, consuming tokens and GPU resources for every job. Code-based processing, generated through agentic loops, runs compiled logic without model inference. Code-based processing is faster, costs less at scale, produces consistent outputs and is fully auditable because the logic is explicitly committed and inspectable.

How does Ocrolus use agentic loops for bank statement processing?

Ocrolus trains AI agents to write bank-specific parsing code using batches of labeled ground truth statements. The agent iterates until it achieves 100% accuracy across a held-out validation set. A monitoring layer then routes a sample of live documents to a validation system and automatically re-runs the loop if accuracy degrades. Using this approach, Ocrolus covered 600-plus banks in a single week at roughly $40 per bank.