Most teams who ask me for "an AI agent" actually need a deterministic workflow with one or two LLM calls inside. The reverse is also true. The cost of getting this decision wrong is anywhere from a flaky demo to a runaway API bill. Here is the framework I use after a couple of years of shipping both kinds of systems in production.
Start with the shape of the problem, not the buzzword
An automation workflow is a graph of steps you already know how to execute. An AI agent is a loop that reasons, picks a tool, observes the result, and decides what to do next. Those are very different runtime profiles, and they fail in very different ways.
If you can write the if/else logic for the happy path on a napkin, you are looking at a workflow. If the if/else branches depend on understanding unstructured input or open-ended judgement, you are starting to drift into agent territory.
Workflow territory: deterministic, repeatable, auditable
For most internal automation, n8n with embedded OpenAI nodes is the right call. You get observable logs, retries, scheduled triggers, and clean handoffs between SaaS APIs without ever letting an LLM control the flow.
A typical pattern: a webhook fires, the workflow enriches the payload, an LLM node classifies or summarises a single field, the result feeds a SQL update and a Slack notification.
- Lead routing from inbound forms
- Invoice/receipt extraction and bookkeeping handoff
- Daily ops digests aggregating multiple SaaS sources
- Triage of support tickets before a human picks them up
Agent territory: open-ended tool use under guardrails
Agents earn their keep when the next step legitimately cannot be enumerated up front. Research, multi-step browser automation, multi-source reasoning, or any case where the LLM has to plan over a tool catalogue.
The risk profile is also different. An agent can spin in a loop, double-call expensive tools, or hallucinate a function name. Production agents need iteration limits, tool-result truncation, and ideally a separate validator pass before any write action.
A simple decision rule that holds up in practice
Ask a colleague to write the steps on a whiteboard. If they finish in five minutes, build the workflow. If they keep saying "well, it depends on what the data looks like," you have an agent problem, and you should start by listing the tools the agent will be allowed to call.
Either way, instrument from day one. Token usage, step durations, and failure modes are what tell you whether the system is actually solving the business problem or just demoing well.
Takeaway
Default to workflows. Promote a step to an agent only when the branching genuinely cannot be enumerated. Most teams skip workflows entirely and end up paying for an over-engineered agent that does the work of a five-node n8n flow.
