AI agents vs. plain automation: what actually needs an agent

Agent has become one of those words that means something different in every sales deck, which makes it a genuinely unhelpful word to build a project brief around until everyone in the room agrees what it actually means for the workflow in front of them. We use a narrower, more useful definition internally: an agent is a system that decides which of several possible actions to take next based on the current state of a task, calling tools and observing results along the way, rather than following one fixed sequence of steps someone wrote in advance. Most of what gets marketed as an agent today is actually the second thing, well-built automation, and that distinction changes how we scope and price the work.

If a workflow always executes the same sequence of steps in the same order regardless of what happens along the way, read a document, extract three fields, write them to a database, send a notification, that's automation, not an agent, even if a language model is doing the extraction step. There's nothing wrong with that; a well-built fixed pipeline is simpler to test, cheaper to run, and more predictable to debug than an agent would be, and a meaningful share of the workflows we're asked to make agentic don't actually need to be, because the sequence of steps genuinely doesn't vary case to case. We build these as straightforward pipelines and tell the client honestly that the word agent doesn't apply, even though a model is doing real work inside it.

A workflow needs an agent, in our narrower sense, when the right next action genuinely depends on what happened in the previous step and can't be predicted in advance. A customs documentation task where the system needs to look up a tariff code, decide based on the result whether additional documentation is required, and only then determine which form to fill out next, is a genuine agent use case, because the path branches based on real information gathered along the way, not a rule that was known upfront. A logistics project we shipped last year is a clean example: the agent decides which lookups to run and which forms apply based on what it finds, rather than following one fixed script regardless of the shipment.

Building an agent when a fixed pipeline would do adds real cost: more moving parts to test, a wider range of possible execution paths to evaluate, and more ways for the system to end up somewhere unexpected. Building a fixed pipeline when the task genuinely needs branching logic produces something that works for the common cases and breaks awkwardly on the ones that don't fit the assumed sequence, often silently, until someone downstream notices the output doesn't make sense. We've seen both mistakes in projects we've inherited from other teams, and both are expensive to unwind once a client's operations have already started depending on the system as built.

Early in any AI-flavored project, we sketch the actual decision tree of the workflow with the client, on a whiteboard if we're in the same room, over a shared document if we're not. If that tree has one path, it's automation, and we say so plainly. If it genuinely branches based on information the system only has once it's already started working, it's an agent, and we scope the extra testing and guardrail work that comes with that honestly rather than quietly absorbing it. Clients consistently tell us this framing is the most useful thing we do in the first week of an agentic project, mostly because it replaces a marketing word that means everything with a specific technical question that has a real, checkable answer.

Early in our own agentic work, we described a document-processing pipeline to a client as an agent because it used a language model at three different steps, when in fact every one of those steps ran in the same fixed order every single time regardless of what the model found along the way. It was well-built automation, genuinely useful automation, but calling it an agent set an expectation of adaptive, branching behavior that the system never actually had, and the client's own team built a mental model of the system's capabilities that didn't match what we'd actually shipped. When they later asked why the system couldn't handle a case that required branching logic, the honest answer was that nothing about the system had ever been able to branch, only the language may have implied it could.

We corrected our own internal language after that project, and we now default to describing a system by what it actually does, drafts, extracts, routes, decides, rather than reaching for the agent label unless the branching behavior is genuinely present and load-bearing to how the system works. It's a small discipline, but it's changed how accurately clients understand what they're actually getting, and it's prevented at least two follow-on scope conversations that would otherwise have started from a mismatched expectation about what the system was supposed to be capable of in the first place.

This same imprecision shows up constantly in vendor pitches we sit through on a client's behalf, evaluating a tool they're considering alongside our own recommendation. A pitch deck slide that says agentic workflow automation tells us almost nothing about whether the underlying system actually branches based on real-time information or just runs a fixed sequence with a model doing the language-heavy steps. We've started asking vendors directly, in front of the client, to describe one specific case where the system's next action differed from what a fixed script would have done, and the answer to that single question is usually more informative than the entire rest of the pitch. When a vendor can't answer that question concretely, we treat it as a signal worth flagging to the client directly, regardless of how polished the rest of the pitch was.