A trigger starts a run
A new email, a webhook, a schedule or a form starts one execution. It carries an item, plain JSON, that each node reads, adds to and passes on.
A trigger starts it, a JSON item moves from node to node, and one node asks a model to turn free text into fields. Everything after that is ordinary branching. Tools like n8n and Flowise draw exactly this.
One fixed workflow, one email per execution. The AI's replies are fixed per email so every run is repeatable.
An email arrives and starts an execution. The AI node reads free text and returns fields as JSON. The switch routes on them like any other data: log the order, reply to the customer.
Ready. The workflow is active. Send it an email.
| # | message | path |
|---|
A new email, a webhook, a schedule or a form starts one execution. It carries an item, plain JSON, that each node reads, adds to and passes on.
The model's job is narrow: read something messy and return named fields in a fixed schema. That turns language into data a switch can route on.
What each category does is a branch someone drew and anyone can read. Unlike an agent, the model never picks the next step: the workflow does.
Live: the node running now
Email trigger on new message → { from, subject, body }AI: classify model + JSON schema → { category, orderId, urgent }Switch {{ $json.category }} order → Sheet: append row → Reply: “We're on it” complaint → Team chat: alert a person spam → (end)Live: the item as JSON
$ execution --item
(no execution yet)n8n is a general automation tool: hundreds of integrations, with AI as one kind of node among many. Flowise starts from the other end, a visual builder for LLM chains, agents and RAG flows, often called from another system. Underneath, both are this: nodes joined by wires, with data flowing along them.
Watch the item. The trigger adds the email's fields, the AI node adds category, orderId and urgent, and later nodes refer to them with expressions like {{ $json.orderId }}.
Nodes that write, such as a sheet or a reply, are side effects. A workflow is only as reliable as its handling of the run that fails halfway, and of the one that runs twice.
Models sometimes add a friendly sentence or stop mid-object. Ask for a schema, parse strictly, and decide in advance what a failure does.
Polling windows overlap and webhooks are retried. Without a check on the message id, one email becomes two rows and two replies.
A failed execution is logged and then forgotten. Give the workflow an error branch that tells a person, or failures turn into customers who were silently ignored.
The email trigger fires twice for the same order email, and the workflow has no dedupe. What does the customer see?
The AI node returns “Sure! Here's the JSON: {category: order…”. The workflow is set to stop on error. What happens to the customer's email?
In n8n a node can receive many items at once, for example every new email since the last poll, and runs once per item. Here each execution carries one, to keep the path readable.
Both tools also have agent nodes, where the model chooses tools in a loop. That trades the readable branches here for flexibility, with the risks the AI agents topic shows.
Each integration needs credentials, stored by the tool and scoped as tightly as possible. Real AI and email APIs also have rate limits, so busy workflows queue, batch or back off.
A common middle ground is drafting instead of sending: the workflow writes the reply, and a person approves it with one click. It keeps most of the time saved and removes most of the risk.