"Just use an agent" and "just use Zapier" are both bad advice, given confidently, about half the time each.
They are different tools for different shapes of problem, and the failure modes of using the wrong one are not symmetrical — one wastes money and the other loses trust.
The actual difference
A workflow automation tool runs a fixed graph. When this trigger fires, do step one, then step two, then step three. You drew the graph; it runs the graph. Same input, same path, every time.
An agent with tools runs a decision loop. Here is a goal and here are some tools; work out what to do. It might call three tools or eleven, in an order nobody specified, and next Tuesday on similar input it might choose differently.
Everything else follows from that.
| Workflow automation | Agent with MCP tools | |
|---|---|---|
| Path | Fixed, drawn by you | Chosen at runtime |
| Same input twice | Same result | Probably the same result |
| Cost per run | Predictable, small | Model tokens, variable |
| Latency | Milliseconds to seconds | Seconds to minutes |
| Handles the unexpected | Fails or ignores it | Often copes |
| Debugging | Read the run log | Read the reasoning and the tool calls |
| Unstructured input | Poorly | Very well |
| Auditability | The graph is the spec | Trace after the fact |
When the workflow wins
The path is genuinely fixed. "New Stripe payment → create Xero invoice → notify #finance." There is no judgement in that. An agent adds cost, latency and variance to a problem that has none of those, and you will be paying model tokens forever to re-derive a decision you already made.
It runs constantly. A thousand times a day, a workflow's per-run cost is a rounding error and an agent's is a line item somebody will ask about.
Determinism is the requirement. Anything financial, anything regulated, anything where "it usually does the right thing" is not an acceptable description. A drawn graph is a specification you can hand to an auditor. A trace is evidence about one run.
Failure must be loud. Workflows fail visibly at a named step. Agents are disconcertingly good at routing around a broken tool and producing something plausible instead.
When the agent wins
The input is unstructured. "Read this support email and do the right thing" is not a graph. There is no branch count that covers what people write to you. This is the case agents were made for.
The path depends on what you find. "Investigate why this customer churned" means looking at the CRM, then maybe the support history, then maybe the usage data — where you go next depends on what the last step said. Drawing that graph means drawing every branch, and you will miss some.
The long tail is the point. A hundred one-off tasks, each worth doing and none worth building a workflow for. Nobody is going to draw a graph for "summarise last week's Slack in #design" — but an agent that can already reach Slack does it on request.
Requirements move faster than you can rewire. Editing a prompt is cheaper than editing a graph, and there are situations where that alone decides it.
The mistake in each direction
Reaching for an agent when a workflow would do is the expensive mistake. You pay per run, forever, for variance you did not want, on a task whose answer was already known.
Reaching for a workflow when you needed an agent is the frustrating one. It shows
up as a graph that grows a branch every week, a switch node with fourteen
cases, and eventually a step that calls a model anyway — at which point you have
built a worse agent inside a workflow engine.
They compose better than they compete
The arrangement that works in practice is not either/or.
A workflow handles the trigger, the routing and the parts that must be deterministic — and calls an agent for the one step that needs judgement. New support ticket arrives (workflow), agent reads it and decides the category and severity (agent), route and notify accordingly (workflow).
You get determinism where it matters and judgement where it is needed, and you are only paying for inference on the step that actually required it.
MCP is what makes that composition practical, because the same connected accounts are reachable from both sides. The agent is not a separate integration project with its own credentials — it reaches the same apps, under the same permission rules, and every call it makes lands in the same activity log as everything else.
That is the part a workflow tool cannot give you, and it is what Spinrun is for. Your flows keep doing the deterministic work. The agent step reaches the same apps through a gateway that classifies every tool read, write or destructive, enforces your rules before the call leaves, and records who it acted as. You do not have to choose between "auditable" and "can handle an email nobody anticipated".
Next
- Managed MCP gateway vs running your own MCP servers
- What the Model Context Protocol actually is
- Use cases — jobs that genuinely need the agent side