AI Agents vs Automation
Working notes on when fixed automation is enough and when agentic workflows are worth it.
The split I keep coming back to is simple:
- If the path is known, use automation.
- If the path is uncertain but the outcome is clear, consider an agent.
This keeps me honest. A workflow can use an LLM and still be normal automation. If every step is fixed, it is still a workflow. It becomes more agentic when the system chooses what to inspect, which tool to call, or whether to change the plan.
I do not treat this as a formal definition. It is a practical filter for product and engineering decisions.
Quick decision table
| Situation | Default choice |
|---|---|
| Repetitive, stable process | Automation |
| Many edge cases, shifting context | Agent |
| High-risk action | Automation with an approval gate |
| Need strict determinism | Automation |
| Need adaptive tool selection | Agent |
Simple model
Automation: do these steps.
Agent: get this result, then work out the next step as you go.
That second line is where most of the cost comes from. Planning, tool choice, state tracking, retries, and stopping rules all need design.
Concrete examples
| Job | Better starting point | Why |
|---|---|---|
| Send a weekly report from known dashboards | Automation | source, format, and schedule are stable |
| Investigate why a metric moved | Agent | path depends on data, logs, docs, and context |
| Resize uploaded images | Automation | deterministic transform with clear success criteria |
| Triage a support ticket across multiple systems | Agent with approval gates | context gathering is variable, final action may be risky |
| Reconcile invoices against known rules | Automation first | rules are explicit; exceptions can escalate |
Most teams should start with the boring option. Agents are useful when the workflow has meaningful uncertainty, not when the team simply wants a modern label.
The mistake I see
The common mistake is using an agent for a checklist problem.
That usually adds latency, cost, and debugging work without adding much value. If a finite workflow solves the problem cleanly, I start there.
The opposite mistake also happens: forcing automation onto a problem where the exception paths dominate. If humans keep adding "one more if statement" for every customer, vendor, or system variant, the workflow may need an agentic planner or at least an LLM-assisted triage layer.
Starter architecture
Start with one planner, two or three tools, an explicit stop condition, human approval for risky actions, and logs for each step.
Only add more agents after one-agent reliability has become boring.
When I would upgrade automation to an agent
I look for three signals:
- The workflow needs context from more than one source.
- The right next step depends on what was just discovered.
- Humans can describe success, but cannot list every path upfront.
If all three are true, an agent may be worth the extra operational burden. If only one is true, I usually keep the automation and add a small human-review or classification step.
Operating cost
Agents need traces, tool permissions, evals, fallback behavior, and monitoring. They also create product questions: when should the system ask for help, when should it stop, and who owns a bad action?
That cost is worth paying only when adaptability creates enough value. Otherwise deterministic automation is faster, cheaper, and easier to debug.
The question I now ask is not "can we make this agentic?" It is "what part of this problem actually needs judgment while it runs?"