AI Agent: The Definition Most Articles Get Wrong

An AI agent is a system that decides for itself which steps to take to reach a goal, choosing its tools as it goes, unlike an automated workflow where each step is fixed in advance by a human. The distinction seems obvious on paper. Yet it explains half the misunderstandings we've run into around this term over the past two years.

The term "AI agent" is now slapped onto just about everything: a chatbot with a few function calls, an n8n pipeline with an LLM call in the middle, a genuine autonomous decision loop. This blur is far from harmless. It pushes teams to build (or buy) the wrong tool for the wrong problem. This article takes a stance on where to draw the line, with a concrete example and the mistakes we keep seeing in production.

The problem: nobody has the same definition

There is no single, consensual definition of the word "agent" in the industry. A study conducted by Simon Willison, a respected developer in the tech community, surveyed AI practitioners and found a multitude of different and sometimes contradictory definitions of the term. Some use it to describe any system that calls a tool, others reserve the word for systems capable of planning multiple steps without human oversight.

Result: two companies can sell exactly the same product. One calls it an "automated assistant." The other calls it a "next-generation autonomous AI agent." The price differs threefold.

This lack of a standard isn't just a marketing problem. It has real technical consequences when it comes time to choose an architecture.

Agent vs workflow: the distinction that actually matters

Here's the most useful line of demarcation in practice: in a workflow, the execution path is written in advance by a developer, conditions, branches, a fixed order. The LLM, if it intervenes, merely executes a specific task within a predefined step.

In an agent, the model itself decides the next action: which tool to call, in what order, when to stop. The loop is open. Nobody wrote down the exact sequence of steps beforehand.

This difference changes everything in terms of predictability, cost, and debugging.

We detailed the mechanics of connecting an agent to its tools in the article on how to create an MCP server for Claude. The MCP protocol standardizes how an agent discovers and calls external tools, but it doesn't make a system an "agent" in itself. You can just as easily wire MCP onto a simple workflow.

A concrete example: the agentic SOC

A well-documented case illustrates the difference: the agentic security operations centers (SOCs) described by Harvey. The system operates through a continuous cycle, threat hunting, detection engineering, alert tuning, where each step informs the next autonomously, without a pre-established script for each attack scenario.

That's a real agent, not a disguised workflow. The model adjusts its detection strategy based on what it discovers in the previous step. A classic script would have had to anticipate each case beforehand.

But here's the honest limit: this autonomy has a price. The longer the loop, the higher the token bill climbs and the greater the risk of drift. We quantified it in the article on the real cost of the Claude API, an agent that loops 15 times on a problem can cost ten times more than a workflow that handles the same case in three fixed calls.

Anthropic itself is pushing a vision where work increasingly looks like a "multiplayer" collaboration between humans and autonomous systems rather than simple task automation. But this vision assumes use cases where the unpredictability of reasoning brings real value, not just any form to fill out.

Why this confusion costs in production

We see three mistakes come back regularly with teams getting started.

The first: building a complete agentic loop for a need that would have been fine with a three-step pipeline. The result is slower, more expensive, and harder to debug, for a gain in flexibility that nobody actually uses.

The second mistake is the reverse. Some teams call their product an "agent" as pure marketing argument, when it's really a chatbot with basic function calling. The customer expects autonomy they never get.

The third, more insidious: underestimating the cost of supervising a real agent in production. Without fine-grained observability on every decision the model makes, a behavior drift can go unnoticed for weeks. We touched on this already when diving into free and open source options for building an AI agent without blowing your budget, the model's free cost says nothing about the cost of supervision.

If your team has fewer than five developers and the use case is repetitive, a well-structured workflow will often do better than a poorly supervised agent.

Conclusion

Three points to take away. An agent decides its action sequence in real time, a workflow executes it according to a plan fixed beforehand, the difference isn't cosmetic, it changes the system's cost and predictability. The word "agent" has no consensual definition in the industry, which makes it as much a marketing argument as a technical term. And autonomy has a real price in tokens and supervision effort, which makes the workflow preferable in the majority of concrete cases.

Before you set out to build an AI agent, ask yourself one simple question: does your problem really need a model that improvises, or just a reliable chain of steps? If you'd like us to look at your specific case together, the fstck.co team is available to discuss it.