Agents, Automations, and Knowing Which One You Need

Every tool I use rebranded itself around agents this year. The email platform has agents. The project manager has agents. I half expect the label maker to announce agent capabilities by spring. Meanwhile, half the teams I talk with really just need a good automation, and a few need the opposite. The words matter because they cost differently and fail differently, and buying the wrong one is how organizations end up concluding that AI does not work, when what actually happened is that they hired a jazz musician to run a metronome.

I spend a good part of my consulting work now untangling exactly this confusion, so here is the field guide I wish I could hand out at the start of every one of those conversations.

The distinction that matters

An automation is deterministic. When X happens, do Y. Same input, same output, every time. A form submission posts to a channel. A recording lands in a folder and a transcript comes back. A calendar event triggers a reminder email with the same wording it used last week and will use next week. It never has a creative day. That is not a limitation. That is the entire product.

An agent exercises judgment. It reads a situation, decides among options, and takes multi-step action. Summarize what came in overnight, draft responses for the routine items, flag the two that need me. You did not tell it which two. Deciding which two is the job.

A simple test separates them: can you write the complete rule on an index card? "When a form comes in, post it to the channel and add a row to the sheet" fits on the card. "Read these fifteen messages and figure out which ones are urgent" does not, because the rule is not really a rule. It is a judgment call you are delegating. Index card, automation. No index card, agent.

The reason this distinction gets blurred is that vendors have every incentive to blur it. Agent is the exciting word this year, so everything gets called one. But when you are deciding what to build, the marketing labels are noise. What matters is the question underneath: does this task have one right answer, or does it require an opinion?

They fail in opposite directions

Here is the part that the sales pages skip, and it is the part that should actually drive your decision.

Automations fail loudly and stupidly. When something breaks, it breaks the same way every time, usually because an input changed shape or a connection expired. The failure is obvious, findable, and fixable, and once fixed it stays fixed. An automation will also happily do the wrong thing forever with total confidence: if the rule is wrong, you get the wrong result a thousand times in a row. But you will get it consistently, which means you will catch it.

Agents fail quietly and plausibly. An agent having a bad day produces output that looks fine. A summary that subtly misses the most important item. A draft that is well-written and slightly wrong about a fact. A triage decision that filed the urgent thing under routine. The failure does not announce itself, which means the review step is not optional. It is the load-bearing wall.

This is why pointing an agent at index-card work is worse than wasteful. You take a task that could have been perfectly reliable and introduce a small percentage of plausible-looking variance into it, then you pay someone to check output that a dumb rule would have gotten right unattended. I have watched a team use an agent to copy data between two systems, a pure X-to-Y move, and then spend part of every week investigating why a few records came out creative. An automation would have done it flawlessly and invisibly, forever.

Use an automation when being boring is the goal

Scheduled publishing, file routing, notifications, data syncs, backup checks. If you can write the rule on an index card, you want an automation. It is cheaper, faster, and auditable. When the auditor, or the board, or just your own future self asks why the system did what it did, the answer is the rule, printed on one line.

My own stack is mostly this, and I say that as someone who builds agents for a living. Recordings route themselves to the right folders. Form submissions notify the right people. Posts publish on schedule. Backups verify themselves and complain if something is missing. None of it is impressive in a demo, and all of it has run for months without my attention, which is the actual definition of success.

The mistake I see most is pointing an agent at index-card work and accepting occasional weirdness in something that should never vary. The second most common mistake is the inverse and sneakier: building a brittle automation for judgment work. That is the two-hundred-rule filter tree that tries to encode "is this message important" as keyword matches. It misclassifies constantly, someone adds three more rules every month, and eventually nobody understands the tree at all. If you find yourself endlessly patching rules to approximate an opinion, stop. The task was agent-shaped all along.

Use an agent when the input is messy

Triage, summarizing, drafting, research, first-pass editing. Anywhere the input is unstructured and a junior teammate would have needed to think for a minute. The agent produces a draft or a recommendation, and a human owns the decision.

The junior teammate framing is the most useful management tool I have found here, because it imports all the right instincts. You would not hand a new hire the company credit card and the send button in their first week. You would give them clearly scoped work, review everything at first, then loosen the review as they earn it. You would also not hire someone for a job you could not describe. If you cannot tell a human what good output looks like for a task, an agent will not figure it out either. Every failed agent project I have been called in to look at died from one of those two: no review structure, or no definition of good.

Scope discipline matters more than capability. The agents earning their keep in my work are narrow: summarize what accumulated overnight into one brief, draft community posts from this source material in this documented voice, do a first research pass and return sources. Each one has a lane, a defined output shape, and a human at the end. The impressive general-purpose agent that handles anything is the one I have never seen survive contact with a real organization's real week.

The hybrid is usually the answer

My best pipelines are automations with an agent in the middle. The automation moves the material reliably. The agent does the judgment step. Then the pipeline stops at a human review gate before anything public happens. Deterministic rails, intelligent middle, human final say.

Here is a real one, generalized. A recording finishes and an automation moves it to the right folder and requests a transcript. Nothing clever, pure plumbing. The transcript lands, and an agent reads it against a voice document and drafts the derivative pieces: a summary for the team, a couple of community posts, an email draft. That is the judgment step, and it is the only place in the pipeline where judgment happens. Then everything stages in a review queue, a human reads, edits, approves or kills each piece, and only after that does another dumb automation publish the approved items on schedule.

Notice where the reliability lives and where the intelligence lives. The agent never touches the send button. The automations never make a decision. Each part does the thing it is structurally good at, and the seams between them are explicit. When something goes wrong, I know immediately which kind of problem I have: a plumbing problem, which is loud, or a judgment problem, which the review gate catches. That diagnosability is worth more than any single capability in the pipeline.

Questions to ask before you build anything

When someone brings me a task they want to hand to AI, we walk through the same four questions, in order.

First, does the task have one correct output? If yes, stop. Build the automation, spend the savings elsewhere. Second, what happens when the output is wrong? If a wrong result is embarrassing or public or expensive, the review gate is mandatory, and you should design the review step before you design the agent. Third, can you describe good output to a human in a paragraph? If you cannot, no tool can rescue the task from your own fuzziness. Write the paragraph first. It usually turns out to be the hard part, and it improves the human process even if you never automate anything. Fourth, how often does this actually happen? A messy task that occurs twice a year does not justify a pipeline. Do it by hand and go home.

It is remarkable how often the answers route someone away from the exciting thing they walked in wanting and toward a boring thing that will actually work. Nobody has ever come back later to complain that their system was too reliable.

Earn your way up

Start with the boring automation. Get the deterministic rails working and trusted, because they are the foundation everything else stands on, and because the discipline of mapping your own process is where most of the value hides anyway. Organizations regularly discover, halfway through automating a workflow, that the workflow itself never made sense. The index card was blank because nobody actually knew the rule.

Then add the agent where the mess genuinely lives, one narrow lane at a time, with a human review gate that treats every output as a draft. Watch it for weeks, not days. Loosen the review only where it has earned the loosening, the same way you would with any new team member.

And never give either one the send button on day one. The automation does not deserve it yet because your rule might be wrong. The agent does not deserve it yet because its judgment might be. Trust in systems is built exactly the way it is built in people: gradually, with receipts. The teams that get this right are not the ones with the most impressive technology. They are the ones who knew which tool they were holding, and why.