Most small businesses have a document problem that nobody calls a document problem. An invoice arrives by email. A contract comes back as a scanned PDF. A delivery note is a phone photo. Someone opens each one, reads it, retypes the important parts into another system, checks them against something else, and only then does the actual work begin.
An AI agent for document processing targets exactly that gap between "a file arrived" and "someone can act on it." What makes it interesting is not that it can read text. It is that it can use tools.
Reading is the easy part
Extracting fields from a document is the part everyone has seen demonstrated: supplier name, document number, dates, line items, totals. A language model can help interpret different layouts and wording.
On its own, though, extraction produces a pile of text fields that may or may not be right. The value comes from what happens next.
Where tool use changes the picture
An agent is a model that can decide to call tools and act on what they return. In a document workflow, those tools are connections to your real business records:
- a query against your customer or supplier list, to see whether the company on the document already exists and under which exact name;
- a lookup in your order, contract, or ticket system, to find the record the document refers to;
- a check against your own rules, such as required fields, allowed value ranges, or approval thresholds you define.
The agent reads the document, then asks questions of your systems. If a supplier name is spelled slightly differently from the one in your records, it can find the likely match and flag the discrepancy rather than create a duplicate. If a document references an order that cannot be found, it says so instead of guessing.
The result is a structured draft: the extracted data, the records it was matched to, and a short list of anything that did not line up. Nothing is final at that point. A person reviews the draft, corrects it if needed, and approves it.
An illustrative workflow
Imagine a small distribution company that receives supplier invoices by email. This is an illustration of how such a system could be built, not a description of a real deployment.
An automation platform such as self-hosted n8n watches a mailbox and picks up each new attachment. A Python service sends the document to a Claude model with instructions to extract a defined set of fields and return them in a fixed structure.
The agent then calls tools. It looks up the supplier in the company's records. It searches for the purchase order named on the invoice. It compares the invoice lines with the order lines and notes differences.
Finally, it prepares a draft entry with the extracted values, the matched supplier and order, and a plain-language list of items that need attention. The draft lands in a review queue. The accountant opens it, sees the flagged points at the top, resolves them, and approves. Only then is anything written to the accounting system.
The same pattern fits other documents: contracts matched to a client record, delivery notes matched to shipments, application forms matched to an existing case. The tools and the rules change, while the structure stays the same: read, check, draft, review.
Why the human stays in the loop
A draft for review is a deliberate design choice. The agent does the repetitive reading and cross-checking, and a person keeps responsibility for the decision. Review rules can also be tuned per process, for example routing documents with unmatched records to a person automatically while straightforward ones wait in a simple approval queue.
Equally important is how data is handled. Which documents the system sees, where they are processed, and what is stored all depend on the nature of the data and your obligations. For sensitive material, that is settled in the design, with self-hosted components where the process calls for it.
What it takes to build one
A working system needs a clear definition of the document types, access to the systems where your records live, explicit rules for what counts as a mismatch, and a review step people will actually use. We build and operate these systems at Pragma AI for Bulgarian small businesses, connecting n8n, Python/FastAPI, and the Claude API to the tools you already use.
Talk to us
If you have a document flow that eats someone's day, describe it to us: what arrives, where it comes from, and which systems need to know about it. We will tell you what an agent could realistically do with it, and where a person should stay in charge. Contact Pragma AI to discuss your process.