Most automation requests I get arrive framed as "we want an AI agent that handles X." Most of them, once you map the process, are a workflow with one or two steps that genuinely need a language model. The rest of the steps are known in advance and should be built that way.
That is not an anti-AI position. It is where AI actually earns its keep. The 2026 assessments I have read land in the same place: agents are dependable for structured jobs like classification and extraction, and still risky when asked to make long chains of decisions on their own. Workflows that combine a fixed spine with a few model steps are where the payoff is clearest.
Here is how I decide where the model goes.
Three questions for every step
- Is the path known? If you can draw the branches on a whiteboard, it is a workflow step: an IF node, a Switch, a lookup.
- Is the input unstructured language? If a person wrote it in their own words, a model step is often the right tool to turn it into fields.
- Does the next action depend on judgment across many options and tools? Only then do you need an agent, and even then it should be bounded.
Most steps fail question three. That is fine.
What this looks like in my templates
I publish n8n templates as a Verified Creator, all of them in my workflow library, and looking back at them, the pattern is consistent.
The Gmail auto-organizer has no AI at all. Rules live in a Google Sheet: sender patterns and an action for each (delete, promotions, or a label). The workflow matches and applies them. A language model would be slower, cost money on every email, and occasionally get it wrong. Pattern matching never has a creative day.
Lead routing is deterministic too. The demo scheduling template enriches a lead, scores it from 0 to 100 on company size, seniority, and revenue, and sends anything above 60 down a fast track with live Calendly slots and a Slack alert. If sales does not respond within ten minutes, a fallback email goes out. Every rule there is a business decision someone can read and change. None of it should be hidden inside a prompt.
The WHMCS ticket bot uses the model for the one thing it is good at. A customer describes their problem in a chat. The model pulls out the name, the email, the subject, the description, and a priority. The workflow, not the model, fetches the list of valid support departments from WHMCS and creates the ticket through the API. The model fills in a form. The workflow owns the system of record.
The news digest uses the model only for reading. A form takes the topic, the GNews API returns the articles, and Slack receives the result, all as plain steps. The model's job is the part that needs language: picking the most relevant articles and summarizing them.
The shape that works
A deterministic spine, with models at the edges where language enters or leaves the system:
- On the way in: turning free text into structured fields, classifying intent, extracting values from documents.
- On the way out: drafting a reply, a summary, or a ticket description for a person to read.
- In the middle: fixed logic, real lookups, API calls with known inputs, and validation.
When the middle is fixed, failures are easy to find. When the middle is a model, every failure is an investigation.
Our own products follow the same rule. In LaunchLancer, our store builder for Pakistani merchants, the WhatsApp order confirmation we are adding to cut cash-on-delivery returns needs no AI at all: an order arrives, the customer gets Confirm and Cancel buttons, and the order moves on their answer. The AI we are adding to LaunchLancer sits at the edge instead, drafting a product listing from a few words or a photo for the merchant to review.
When an agent does earn its place
A real agent makes sense when the user can ask about many different things and each needs a different lookup. The hosting support template is a fair example. I wrote about it in detail in An AI Support Agent for a Hosting Business. A customer might ask about plan pricing, then whether a domain is free, then which payment methods are accepted. The agent chooses between narrow tools: Google Sheets knowledge bases for plans, prices, features, FAQs, and payment methods, plus a WHMCS domain lookup.
Even there, each tool is deterministic. The agent decides which question to ask. It never decides what the answer is. Domain availability comes from the WHMCS API, never from the model's memory.
Practical rules in n8n
- Validate model output before acting on it. Use a structured output parser where you can, then an IF or Code node that checks required fields. Route anything malformed to a fallback branch instead of passing it on.
- Keep business rules out of the prompt. Thresholds, prices, and routing belong in nodes or a sheet that someone can audit.
- Keep the tool list short. Every extra tool is another way for the agent to pick the wrong one.
- Use the cheapest model that does the job. Classification and extraction rarely need the largest model. My article discovery template runs on GPT-5 mini, because deciding which links on a page are articles is a sorting job, not a reasoning one.
- Log inputs and outputs of every model step, so when something goes wrong you can see what the model was given and what it said.
- Give every model step a "could not decide" path that ends with a person, not a guess.
My take
"Agentic" has become a label people want on the box. The systems that hold up in production are mostly workflows: fixed, readable, testable, with a model placed exactly where human language has to become data or data has to become human language. Start with the workflow. Add the model where the workflow cannot cope. Reach for a full agent only when the user's question really cannot be predicted, and keep its tools narrow even then. If you want a second opinion on where AI belongs in your own process, that is a conversation I have often in consulting.