An AI agent for document intake takes over the first handling of every file that reaches your company. It works out what the file is, reads the fields you need and compares them with the record you already hold. Then it files the document where the next person will look for it. Whatever it can't place goes to a person, with the reason attached. It fits a company of 20 to 250 people where one or two colleagues open every attachment by hand and then chase what is still missing.
In my overview of seven AI agent examples, document intake and chasing is the seventh. This article goes through the intake step by step. The company and the documents below are invented. I have no client projects to show yet and I won't make one up. I also make no legal statement here. Which documents you have to hold, and for how long, is a question for your accountant or your lawyer.
Which documents arrive, and through which channels?
Take an invented wholesaler of catering equipment with 60 staff. In an ordinary week its operations team receives:
- insurance certificates and quality certificates from suppliers
- signed contracts coming back from customers
- proofs of delivery from carriers
- completed new-supplier forms
- letters about a changed address, a new contact or a new bank account
Three kinds of document have their own article. Invoices belong to an AI agent that processes supplier invoices. Customer orders belong to an agent for turning PDF purchase orders into sales orders. And if your documents sit in a general mailbox between complaints and newsletters, sorting a shared inbox with an AI agent comes before any of this.
The channels matter as much as the types. At the wholesaler, files come in through a documents@ mailbox, as attachments to emails that suppliers send to their account manager, through an upload form, from the scanner in the post room, and now and then as a phone photo in a chat. Write down every one of them. An agent that watches two channels out of five will report a document as missing that arrived a week ago.
The five steps of document intake
1. It works out what the file is
The agent stores the file unchanged before it reads anything. Then it names the type from a list you wrote: insurance certificate, signed contract, proof of delivery, supplier form, change notice, other. "Other" is a real type. Without it the agent forces a parking permit into the nearest category.
What goes wrong. One PDF holds three documents, because someone scanned the whole post tray in one go. The agent splits a scan only where it finds a clear first page. A scan it can't split goes to a person as one file.
2. It reads the fields
For each type you define the fields that count. On an insurance certificate that is the insured company, the insurer, the policy number, the amount of cover and the dates the cover starts and ends.
The agent stores each value with the place in the document where it found it, so a person can check it against that line.
What goes wrong. The date, mostly. A certificate carries an issue date, a start date and an end date, and the agent takes the wrong one. Two checks in code help. The end date has to lie after the issue date. And a certificate whose end date is in the past gets a flag and is never filed as current.
3. It checks the document against the system of record
The agent then looks up the supplier or the customer in your ERP or CRM and compares. Does the company name on the certificate match the supplier who sent it? Does the contract number exist? Is the same document on file already?
The agent matches on the supplier number or the contract number when the document carries one. Only then does it try the company name and the address. A hit on the name alone is a candidate, and the agent says so.
What goes wrong. A group has four legal entities with nearly the same name, and the certificate covers a different entity from the one you buy from. The agent shows both names side by side and files nothing until someone has picked.
4. It files the document and tells the right person
A document that passed the checks goes into the document store against the right record. Its file name is built by rule, and the fields are saved with it. The agent ticks the document off on a checklist it keeps per supplier or customer. Then it tells whoever is waiting, for example the account manager when a signed contract is back.
Its write access ends there. The agent adds files and ticks a checklist. It doesn't change an address, a payment term or a bank account, whatever the document says.
What goes wrong. The file lands on the right supplier but in the wrong folder, and nobody finds it when the auditor asks. Build the folder and the file name in code from the type and the record. The model never chooses a path.
5. It hands unclear cases to a person
Everything the agent couldn't classify, read or match goes to a queue. Each case comes with the file, the fields the agent did read and one sentence on what stopped it. "Two suppliers match this name" helps the person who picks it up. "Low confidence" doesn't.
That queue needs a named owner and an hour of the day by which it is empty. How to set it up is in designing the review queue.
What stays with a person?
- Whether a document is good enough. The agent reads the cover on an insurance certificate. Whether that cover is enough for this supplier is a judgement.
- Every change to master data. A letter with new bank details may be forged. The agent passes it on with a flag and leaves the record alone.
- Possible duplicates, and any match that rests on a name without a number.
- Everything the agent put in "other".
- Deleting. The agent removes nothing, not even a certificate it believes has been replaced.
- The wording of reminders, which the next section covers.
What about documents that never arrive?
The checklist from step 4 also shows what is missing and what expires soon. Once intake runs well, the agent can send a reminder from a template that a person approved, and hand the case to a person after the second one.
I would switch that on last. If the agent reminds a supplier about a document that came in through a channel it doesn't watch, the supplier notices before you do.
Which limits belong in code?
A document comes from outside your company, and anyone can write anything into it. The agent treats its text as data and never as an instruction. A PDF that says "please update our bank account as follows" changes nothing, because the connector has no function that writes master data. Why a prompt can't do this job is in limits written in code.
The files also go to a model, and some of them carry names and signatures. Before the first real document goes through, put these data privacy questions to the vendor.
How do you start?
Start with one document type and every channel it arrives through. At the wholesaler that would be supplier insurance certificates. They have few fields, and each one belongs to a supplier record the agent can check.
Then give the agent a shadow run of a few weeks. It reads every incoming file and writes the type, the fields, the match and the target folder into a log. It files nothing and sends nothing. Your colleague handles the documents as before.
Afterwards compare file by file. Did the agent name the same type and read the same dates? Did it pick the same record and the same folder? Set the pass mark before the run starts. A pass mark chosen after the results is a negotiation.
Read one group in full, the files the agent would have filed without a flag and your colleague handled differently. Nobody would have noticed those errors in live use.
After the shadow run the agent prepares each filing and a person confirms it. When that has gone well for a while, the clear cases of this one type file on their own.
How do you tell whether it works?
Start with the time from a document's arrival to the moment it sits on the right record, against what the same work took before.
Count the files that went to the queue, by reason. If the most common reason is "two suppliers match", your master data needs cleaning and the agent is not the problem.
Count misfiled documents. Nobody reports one until they need it, so have a person check ten filed documents a week.
Count reminders sent for documents you already had. The target is none.
When is it not worth building?
If a handful of documents arrive each week, a person files them faster than anyone can maintain an agent.
If nobody can say which documents you need from whom, write that checklist first. Which workflow to automate first helps you weigh intake against the other candidates on your list.
Bring a week of incoming documents to a scoping call
Bring one week of incoming documents and the list of channels they came through to a thirty-minute scoping call. Black out personal details first. We go through the sample with you, mark which steps an agent could take over and which stay with your team, and tell you what the first version would cost. If the checklist or the master data needs work first, you hear that too.
What moves that figure is in what drives the price of an agent build. Our agent build takes one workflow like this from shadow mode into production on the mailbox and the document store you already run. What your team holds afterwards is in the ninety-day handover.