Multi-agent document processing breaks extraction into a chain of specialised AI agents: one classifies the document, one reads it into structured text, one extracts fields into a defined schema, and one validates the result and sends failures back for retry. This handles varied layouts far better than template OCR, and routes low-confidence results to a person for review.
Key takeaways
- Single "extract everything" prompts and fixed OCR templates both break on varied, changing layouts.
- A pipeline of classify, read, extract and validate agents is more reliable because each step has one job.
- A strict output schema plus a validation agent that checks the result, without re-reading the document, catches most errors.
- Low-confidence or failed documents go to a person, never silently into the system of record.
- The same pattern applies to ESG data, invoices, contracts and compliance documents.
Why is document processing so hard for ESG and finance data?
Carbon and ESG reporting is a data problem. Utility bills arrive as PDFs, spreadsheet exports, email bodies and scanned images, from hundreds of providers with different layouts. Invoices, delivery dockets and compliance certificates have the same issue.
Traditional OCR templates are brittle: they break whenever a provider changes layout, and every new provider needs developer time. Sending the whole document to one large prompt with "extract everything" is flexible but inconsistent, and hard to debug when it goes wrong.
What is the multi-agent document processing pattern?
Instead of one giant prompt, the problem is split into a chain of specialised agents, each with a narrow role and a clear output.
- Document InputPDF, spreadsheet, email, scanned image
- Classification AgentIdentify document type (electricity, gas, water, invoice)
- Reader AgentVision model transcribes with table structure preserved
- Extraction AgentExtract fields into a strict schema
- Validation AgentAudit results, retry if invalid
- Human ReviewLow-confidence items checked by a person
Phase 1: Classification agent
Role: decide what the file is: an electricity bill, a gas bill, an invoice, or irrelevant. Result: routes the document to the right specialised extractor, with the right schema and instructions.
Phase 2: Reader agent
A vision-capable language model transcribes the document. Unlike basic OCR, it understands tables and column relationships, preserving the structure of the bill: which number is usage, which is the tariff, which is the total.
Phase 3: Extraction agent
Role: extract specific fields, such as kWh usage, billing period, meter or NMI number, supplier and amount, into a strict schema (for example, defined with a schema library such as Zod or Pydantic). Instructions: domain rules such as "if usage is missing on page one, check page two" or "estimated reads must be flagged".
Phase 4: Validation agent
This agent does not look at the document. It checks the extraction result:
- Does the start date come before the end date?
- Do the line items sum to the total?
- Is usage within a plausible range for this site and season?
- Does the meter number match the site record?
If a check fails, the job goes back to the extraction agent with specific feedback. After a set number of retries, it goes to a person.
Why do specialised agents beat one large prompt?
| Template-Based OCR | Multi-Agent AI | |
|---|---|---|
| Extraction errors | Frequent when layouts vary | Lower, with validation catching most of the rest |
| New provider handling | Developer intervention required | Usually handled without new templates |
| Layout change response | System breaks, needs update | Adapts, with validation flagging issues |
| Debugging | Template by template | Step by step, each agent logged |
| Scalability | Limited by template library | Broad document variety |
Each agent has one job, a small prompt and a testable output. When something goes wrong, the logs show which step failed. You can improve one agent without touching the others, and swap models per step, using a smaller, cheaper model for classification and a stronger one for reading complex tables.
How should confidence and human review work?
No extraction pipeline is perfect, so design for exceptions:
- Confidence scores per field. The extraction agent reports confidence, and the validation agent adds rule-based checks.
- Routing thresholds. High-confidence, validated documents flow through. Anything below the threshold goes to a review queue.
- Side-by-side review. Reviewers see the original document beside the extracted fields and correct in one place.
- Feedback loop. Corrections become test cases, so the pipeline improves over time.
A person approves before anything reaches the system of record, and every step is logged for audit. For ESG data that will be assured, that audit trail is essential.
What did the pipeline produce?
- All validation checks pass, high confidenceApprove in batch review and post to the system of record
- Validation fails after retriesHuman review queue with the failed checks shown
- Low confidence on key fieldsHuman review of those fields only
- Document type not recognisedRoute to a person to classify and add to training examples
Where does this pattern apply beyond ESG?
- Invoice processing: supplier, ABN, line items, GST and totals, matched to purchase orders. See our invoice processing guide.
- Contract analysis: key dates, obligations, indemnities and termination rights. See contract review AI.
- Compliance documents: insurance certificates, licences and safety records, as in AI supplier onboarding.
- Operational records: delivery dockets, timesheets and inspection reports.
How was this pattern used in practice?
We built Carbonly.ai, our own ESG and NGER automation product, on this multi-agent approach. It ingests utility bills and activity data from many sources, classifies and extracts them through specialised agents, validates the results and keeps an audit trail for reporting. The same pattern is what we would apply to other document-heavy processes. Our Tier 1 infrastructure carbon reporting case study shows the reporting side of this work.
How do you deploy a multi-agent pipeline safely?
- Weeks 1-2Sample and SchemaCollect representative documents, define the output schema and validation rules
- Weeks 3-5Build AgentsClassification, reader, extraction and validation agents with logging
- Weeks 6-8Run AlongsideProcess documents in parallel with the current method and compare
- OngoingReview and ImproveHuman review queue, corrections become test cases
- Run it on your infrastructure. Models and data can stay in Australia, in your cloud or on your own servers. See our private AI infrastructure service.
- Version prompts and schemas like code, with regression tests on a fixed document set.
- Monitor accuracy by document type and provider, so drift is visible.
- Share of documents processed without human correctionBy document type
- Field-level accuracy on a held-out test setBefore go-live
- Time from document receipt to posted dataDays to hours
- Review queue size and ageDaily
How Solve8 can help
Our engineers build multi-agent document pipelines for ESG, finance and compliance documents, running on your infrastructure in Australia with a person approving exceptions. See our custom AI development service, or talk to us about your documents.
