Everything is called an “agent” today. But there are two very different ways to solve the same process, and choosing the wrong one doesn't show at first: it shows once the system has grown and going back is expensive.
Every so often a word comes along that gets used for everything and ends up meaning nothing. Right now that word is agent.
Someone builds a simple automation and calls it an agent. Someone plugs a model into a task flow and calls it an agent. The term has been stretched so far that it no longer helps you decide anything. And deciding is exactly what matters, because behind that word live two ways of solving a problem that have little in common and get confused all the time.
Two ways to solve the same thing
The first is automation as we've always known it: fixed rules. If A happens, do B. A trigger, a few steps, an action. It does exactly what you told it to, no more and no less. It's predictable, it's cheap and, when it breaks, you know why. Its limit is old and well known: it doesn't understand context. The day the input stops being tidy—an email written by a person instead of a form with fields—the rules start falling short.
The second is the agent. Instead of following a fixed path, it receives a goal, interprets what's in front of it and decides what to do. It understands language, adapts, handles what rules can't anticipate. But all of that comes at a price: it's more expensive, slower and, above all, less predictable. The same input twice may not take the same path.
Neither one is better. They're for different things. And the most common mistake isn't technical: it's putting them in the wrong place.
The right question
Almost everyone asks "should I use AI or not?" That's the question that leads to putting an agent where a rule would have done—expensive and unpredictable for nothing—or forcing rules where judgment was needed.
The question that actually helps is a different one:
Which part of this process requires judgment, and which part is pure execution?
Most processes are almost entirely execution with a pinch of judgment. Moving data, validating, routing, notifying: that's execution, and it doesn't need to think. Interpreting an ambiguous message, choosing between two paths based on context, understanding an intent: that's judgment, and that's where a model makes sense.
Separating those two things inside a process is the real work. The tool comes after.
Where it shows
This stops being theory the moment you sit down to build it. In a tool like n8n, both approaches live on the same canvas: a node that validates a value can sit right next to one that calls a model, and from the outside they look the same. They aren't.
Think of a common process: inquiries come in by email, and you need to understand them, classify them and route them to the right team. The temptation is to build "an agent" that does it all—reads, decides, routes and replies. It works in the demo and becomes impossible to maintain.
The version that survives production splits the work. Fixed rules do their part: they receive the email, move the data, route based on the result. The model is reserved for the one point that truly needs judgment: understanding what that person is asking for. One agent, one job.
That's the rule, and it's almost boring: the agent solves one single hard decision, and everything before and after it is classic automation. The tool is the engine; the model isn't the brain of the whole thing, it's the judgment for a single step.
What you don't delegate
There's a line worth not crossing: nothing with consequences to the outside world should run on its own. An email to a customer, a charge, a publication, a change that can't be undone. The agent prepares; a person confirms.
This isn't distrust of AI. It's understanding that its job is to propose good judgment, and that the responsibility for pressing the button still belongs to someone. Your first version will get some case wrong. Designing for that—instead of hoping it won't happen—is what separates an experiment from a system.
Automating well isn't about choosing between automations and agents. It's about knowing where execution ends and judgment begins, and designing the process before touching the tool.
When that line is clear, the system is cheap where it can be, intelligent where it needs to be, and auditable always. No hype, just judgment.
So before choosing the tool, look at the process. The tool is the last thing that matters. The first—and the one almost nobody looks at—is which part actually has to think.
Marcos Reynoso Founder – The41 https://the41.io