Human-centered design systems and product experiences
Core services
01UI/UX Design02Web Development03Software Development042D/3D Experiences05App Development06AI Agents & Automation07Website DesignTechnical services
Frontend Engineering
React DevelopmentNext.js DevelopmentWeb ApplicationsEnterprise DashboardsSaaS PlatformsBackend & Infrastructure
API DevelopmentCloud InfrastructureDevOps & CI/CDBackend SystemsCustom SoftwareIndustries we serve
Technology & Software
AI Document Intake and Processing Agent Development
Documents in, structured data out
An agent for the documents a business receives all day.
An agent for the documents a business receives all day. It recognises what each file is, extracts the fields that type of document needs with a reference to where each was found, checks that the set is complete and routes the resulting work to the team that handles it.
Documents arrive as attachments, uploads, scans and photographs. Someone opens each one, decides what it is, types its contents into a system and forwards it. An application is processed for a week before anyone notices a page is missing. The same form is keyed twice by two people. The work is simple, constant and exactly the kind where attention fails.
This page describes a workflow we propose to build as a custom project. It does not exist as software yet. It would reuse the pattern proven in our invoice processing demonstration on test data: fields read with their source line, completeness checks, a review step that keeps the original value, and a single approved handover. Classifying document types, reading scans and routing by type are not built.
One Case, Start to Finish
An example of one case, in 6 steps. The same steps play in the picture at the top of this page.
Files arrive
An email brings four attachments for a new account application.
Types recognised
They are classified as an application form, an identity document, a proof of address and an unknown file.
Fields read
Each recognised document's fields are extracted, with their location on the page.
Set checked
The proof of address is older than your rules allow, and the unknown file needs a person.
Reviewed
A reviewer identifies the unknown file and confirms one unclear date.
Routed
The applicant is asked once for a recent proof of address, and the case waits in the right team's queue.
Where the Time Goes Now
What is this file
Staff open every attachment to find out.
Typed by hand
Contents are keyed into a system, with the usual errors.
Incomplete sets
A missing page is found a week into processing.
The same document twice
Two people process the same upload.
Unreadable scans
A photograph of a form, taken at an angle.
No trail
Nobody can say where a value in the system came from.
Six jobs it carries through
01Classification
Recognises the type of each document.
- Your list of document types
- A confidence note
- Mixed files split into documents
- Unknown types sent to a person
02Field extraction
Reads the fields that type needs.
- A schema per document type
- The location of each value
- Unreadable fields left empty
- Tables and line items
03Validation
Checks what was read.
- Formats, dates and totals
- Values against your reference data
- Cross-checks between documents
- Rules you define per type
04Completeness
Checks the set is complete.
- Required documents per case
- Missing pages and signatures
- Expired documents
- One request for everything missing
05Review queue
Puts doubtful items in front of a person.
- Low-confidence fields
- Failed validations
- The document beside the fields
- Corrections kept with the original
06Routing and handover
Sends the result where it belongs.
- The right team by document type
- A record created once
- The source document attached
- Duplicates recognised
What We Need to Scope This
- The process as it runs today, in a few lines.
- The systems it touches, for example intake, document reading, schemas, reference data.
- Rough monthly volume, and who approves what.
Every Value Traceable to the Page It Came From
Extraction is useful only if it can be checked. Each value keeps a link to its place in the source document, low-confidence fields go to a reviewer, and a correction is stored beside the original reading.
The agent classifies, extracts and routes. Decisions that the documents support, such as approving an application, stay with the team that owns them. Sensitive documents are processed in the environment you approve.
- A link from every value to its source
- Uncertain types sent to a person
- Incomplete sets never passed as complete
- Corrections kept with the original
- One handover per case
- Decisions left to the owning team
What It Reads and Writes
The systems named here are the kind this agent works with. Which ones it connects to in your case is settled in the scope.
Intake
- Shared mailboxes
- upload portals
- scanners
Document reading
- A reader for scans and images, chosen for your documents
Schemas
- The fields each document type needs
Reference data
- Customers, products and codes to validate against
Business systems
- CRM, ERP or case management
Review
- The people who resolve doubtful items
What Buyers Ask First
How is this different from the invoice processing agent?
Invoice processing is this pattern specialised for one document type, with purchase-order matching and an accounting handover built in. This agent is the general version: many document types, each with its own schema, routed to different teams.
How is this different from the email inbox agent?
The inbox agent reads the message and works out what the sender wants. This agent reads the attachments and turns them into structured data. A shared mailbox often needs both.
How accurate is the extraction?
That depends on your documents, and we would measure it on a sample of them before promising anything. Clean digital forms read reliably. Photographs, handwriting and unusual layouts do not, which is why low-confidence fields always go to a reviewer.
What exists today?
Not as software yet. This page describes a proposed workflow. It would reuse the pattern proven in our invoice processing demonstration on test data: fields read with their source line, completeness checks, a review step that keeps the original value, and a single approved handover. Classifying document types, reading scans and routing by type are not built. A project starts by mapping your process, then proving the first steps on test data before anything touches a live system.
Send Us Fifty Real Documents
A typical mix, including the bad scans. We will measure what can be read reliably and what will always need a person.