Most workflow automation stops exactly where the work gets hard. A PDF lands in an inbox, and a human still has to open it, read it, and decide what happens next. Moving rows between apps is easy. Reading the document and making a call is the part that stays manual. Putting a model inside the workflow is what closes that gap, and the interesting part is how you do it reliably rather than what it does.
How the pipeline is built
Six nodes in n8n, end to end. An email arrives, the model reads the attachments, and a reply goes back in the same thread within a couple of minutes.
PDF Reader Agent workflow: email trigger, guardrails, filter, Claude vision, extract, reply in thread
Email trigger (IMAP) polls for unseen mail.
Build request applies the guardrails and packs each PDF for the model.
Has PDFs? filters out anything not worth answering.
Claude vision reads the raw PDF bytes.
Extract pulls the model's HTML fragment out of the response.
Reply in thread posts it back into the same Gmail conversation.
The decisions that make it work
Vision instead of an OCR stage. Each PDF is sent to the model as a base64 document content block, not scraped text. The model reads scanned and photographed paperwork the same way it reads a typed file. That removes an entire OCR stage from the build, and with it the accuracy cliff that OCR hits on a poor scan. One fewer moving part to maintain, and better results on the messy inputs that matter most.
Guardrails first, because the mailbox is public. The VPS is a fixed cost. The model API is not, and a public address invites a stranger to send a 300 page PDF. So the build caps three things before anything reaches the model: at most three PDFs per email, ten megabytes per attachment, and three messages per sender per rolling day, tracked in n8n's own workflow static data. A spend ceiling sits on a dedicated API key so a runaway can never touch client work.
A strict output contract. The model is not asked to "summarise." It is asked to return only a Gmail-safe HTML fragment in a fixed shape: a one line overview, a set of bullets per attachment, an HTML table when there are line items, and a list of action items when it finds them. A predictable structure is what lets the reply drop straight into an email without post-processing or surprises.
It reads like a person answered. The response goes back into the same thread, formatted for the email client, so the sender gets a normal-looking reply rather than a raw dump.
Self-hostable by design. n8n runs on a small VPS behind a proper certificate, version-controllable, with no per-task pricing that punishes success as volume grows.
The same pattern, wider
The demo reads documents from an inbox, but the shape generalises to document-heavy back office work. Invoices, purchase orders, and contracts follow the same spine: intake, read, extract into structured data, route or approve with a human step where the decision warrants one, and reply. Only the endpoints change. The read-decide-act core stays the same.
Where the line is
If a workflow needs to run a genuinely open ended loop, plan its own steps, and recover from its own mistakes, that is an agent build rather than an automation, and it carries different guardrails. Part of the job is telling you which one you actually need before you buy, not after.
Like this project
Posted Aug 27, 2026
An n8n workflow with a model inside: an email arrives, Claude reads the PDF attachments by vision, and a structured reply goes back in the same thread. A look at how it is built, guardrails and all.