Automation vs. Agents: The Difference Nobody's Being Honest About

Every product I look at right now has an "agent" somewhere in the pitch. Half the time, what's actually running is a cron job with an if-statement, relabeled because "agent" sounds like the future and "scheduled script" doesn't. I don't say that to be dismissive. I say it because I built one of these things myself, and building it forced me to figure out where the real line actually sits.

The line I actually use

Automation follows a fixed path. Give it the same input twice, it does the same steps twice. No judgment involved, just rules: if this, then that. An agent is different because it decides its next step based on context. It looks at something, forms a read on what that thing means, and can choose an action you didn't explicitly write into a script, inside limits you set ahead of time.

The Ops Agent I built is a useful example of both living in the same system. The part that checks RDS, S3, and billing every morning and posts a status table to Slack is pure automation. Same steps every time, no interpretation required. The part that looks at an idle server and decides whether it's safe to stop is the agent part, because that decision depends on context a fixed rule can't fully capture: is it tagged non-prod, has it been idle how long, is anyone likely to need it in the next hour. That's a judgment call, made narrow and bounded, not a lookup.

Why this distinction is more than semantics

Calling automation an agent isn't just marketing fluff, it's a design mistake with a real cost. If the job only ever needs to follow the same steps, wrapping it in a model adds latency, adds a new way for it to fail, and adds a bill for reasoning you never needed. You don't need an agent to restart a service when a health check fails three times in a row. You need a rule.

The opposite mistake costs just as much, in the other direction. When a job genuinely depends on judgment, forcing it into pure automation means writing an if-statement for every situation you can imagine, and then getting surprised by the one you didn't. I hit exactly this while building the Ops Agent: I could write a rule for "stop anything tagged non-prod that's been idle 24 hours," but a forgotten SFTP server billing me for days wasn't tagged anything. No rule caught it because no one had written that rule yet. That's not a gap you close by adding more rules. It's a gap that needs something capable of noticing "this doesn't look right" without being told in advance exactly what "not right" looks like.

A simple test before building either

Before reaching for either one, I ask a single question: does the next action depend only on data I already have, or does it depend on interpreting what that data means? If it's the first, that's automation, and adding a model on top makes it slower and less predictable for no benefit. If it's the second, that's a job for something closer to an agent, but scoped the way I scoped the Ops Agent's permissions: a tight set of things it's allowed to decide, a tighter set it can act on without asking, and a hard boundary around anything it should never touch regardless of how confident it sounds.

Where this is actually going

The systems that hold up aren't going to be all agent or all automation. They're going to be mostly automation, cheap and predictable, doing the boring eighty percent that never needed judgment in the first place, with a narrow, tightly scoped layer of actual agent behavior handling the twenty percent that does. The mistake to avoid isn't picking the wrong one. It's assuming the word "agent" makes something better just by being on the label, when most of the time what you actually needed was a rule you hadn't gotten around to writing yet.