Put a language model inside a fixed workflow so it reads, sorts and drafts for you, without giving up predictability.
Module 06 ~45 min read + lab No codePrerequisites: Module 5: Automation Basics with n8n. You need a working n8n account with Gmail and Google Sheets credentials connected.
Almost every useful AI step in an office workflow is one of four jobs. Naming the job first keeps the prompt short and the output predictable.
| Step type | Input | Output | Typical use |
|---|---|---|---|
| Classify | A text | One label from a fixed list | Route emails, tag tickets, flag urgency |
| Summarise | A long text or several texts | A short text | Weekly report from five trackers, meeting notes to actions |
| Extract | A text | Named fields (order number, date, amount) | Invoices to a sheet, CVs to a table, forms to a CRM |
| Draft | Facts plus a tone | A text for a person to review | Replies, reminders, announcements |
Classify and extract are the safest because their output is small and checkable. Draft is the riskiest because the output goes to a reader, so a draft step should almost always end in a human review rather than a send. Module 10 turns that rule into a formal control.
Real workflows chain the four: extract the fields from an invoice, classify it as within or above the approval limit, draft the reply, and summarise the day's invoices for finance. Each step is small, and each one can be tested on its own.
Take the map you drew in Module 4. An AI step replaces exactly one box, usually one of the boxes you marked AI-judged. Around it the workflow stays as it was: a trigger before it, a router or a data node after it.
Two placement mistakes are common. Putting the AI step first, before any filtering, means paying for the model on every message including newsletters. Putting it last, after an action such as sending, means the model's judgement can no longer stop anything. Keep the AI step in the middle, after cheap filters and before consequential actions.
A step prompt is different from a chat prompt. Nobody reads the answer; the next node does. So the prompt must pin down the exact shape of the output, and the allowed values.
Notice the pattern: a one-line role, a closed list of allowed answers, a short definition of each, an explicit instruction to output nothing else, and the input at the end. The double curly braces are how n8n inserts fields from the previous node; you pick them from the left-hand panel, you do not type them.
For extract steps you want several fields, not one word. Ask for them in a fixed key: value form, one per line, and tell the model to write none when a value is missing. Most no-code AI nodes also offer a "structured output" or "JSON output" option that turns the answer into separate fields automatically; in n8n it is the Structured Output Parser attached to a Basic LLM Chain. Use it whenever a later node needs to read the values.
If the list is billing, technical, sales, the model will sometimes answer "support" or "billing question". A Switch node will not match, and the item vanishes. Always include a catch-all value and a fallback branch.
A model is never certain; it is fluent, which is different. Your design has to make room for doubt. The simplest tool is a fourth label, unsure, that routes to a person. Three ways to fill it:
The human queue is not a failure. It is where the interesting cases live, and it is the sample you review weekly to improve the prompt (Module 12). A healthy triage workflow sends 5 to 15 percent of items to a person; zero means the model is guessing.
Every AI step costs tokens, roughly words in plus words out. A classification prompt with a 300-word email is about 500 tokens in and 1 token out. At typical small-model prices that is a fraction of a cent; at large-model prices it is a few cents. Multiply by volume before you decide.
| Step | Model size | Why |
|---|---|---|
| Classify with a short label list | Small (mini / haiku / flash class) | Easy task, huge volume, milliseconds matter |
| Extract a few fields from a clean form | Small | Same |
| Summarise a long, messy thread | Large | Needs to follow references across pages |
| Draft a reply a customer will read | Large | Tone and accuracy are visible |
| Extract from scanned, low-quality documents | Large, with vision | Small models miss fields |
Two habits keep costs sane: trim the input (subject and body, not the whole thread) and set a monthly budget alert in the model provider's dashboard on day one. Module 12 adds proper cost tracking per workflow.
You will build an inbox triage workflow in n8n: a new email arrives, an AI step classifies it as billing, technical, sales or unsure, a Switch node routes it, the three known classes get a Gmail label, and unsure items are written to a Google Sheet that a person reviews. Use a test mailbox, not your live one.
In n8n create a new workflow called Inbox triage. Add a Gmail Trigger node, choose your test Gmail credential, set the event to Message received and the poll interval to every minute. Click Fetch test event after sending yourself a test email so the fields appear.
Add a Basic LLM Chain node (or the OpenAI or Anthropic node in text mode) and connect a chat model credential. Paste the prompt from Section 3 into the prompt field, then replace the two placeholders by dragging subject and text from the input panel. Run the node on your test email; the output should be a single word.
Add a Set (Edit Fields) node after the AI step. Create a field called label and set it to the AI output, trimmed and lower-cased using the expression editor's trim and toLowerCase helpers. This protects the router from stray spaces or capitals.
Add a Switch node with four rules on the label field: equals billing, equals technical, equals sales, and a fallback output for everything else. Rename the outputs so the canvas is readable.
On the billing, technical and sales outputs add a Gmail node, operation Add label, using the message ID from the trigger and a label you have pre-created in Gmail. Three small nodes, one per branch.
On the fallback output add a Google Sheets node, operation Append row, into a sheet called Triage review with columns date, from, subject, snippet, link. This is the queue a person opens each morning.
Send yourself ten test emails: three clearly billing, three technical, two sales, and two deliberately ambiguous. Check that eight get labels and two land in the sheet. If an obvious email goes to the sheet, tighten the definitions in the prompt; if an ambiguous one gets a label, add an example of it under unsure.
Switch the workflow to Active. Then open your model provider's usage page and set a monthly spending alert. Note the estimated cost per run from the execution log for your Module 12 tracker.
A screenshot of the activated workflow, the Triage review sheet with your two ambiguous test emails in it, and a note of the per-run cost. Save as M6-inbox-triage.
Pick one answer per question, then check your score. These mirror the style of the final exam.
Answer in your own words first, then open the model answer.
Any concrete answer with a closed list of labels or a fixed set of fields. A draft step must end in a review, not a send.
Allow an explicit unsure label; ask for a 0 to 100 confidence and route below a threshold; or run two prompts and route disagreements.
No. It means the model never expresses doubt, so wrong labels are going straight into branches. Aim for 5 to 15 percent in review.
Further reading: n8n for intelligence workflows · A Visual Guide to LLM Agents
