This is an opinion piece. The facts come from the linked Anthropic post. The argument is mine.
The term AI agent now gets attached to a wide range of products that call a language model, and my impression is that the word is stretched thin. My view is that this is a problem for the people building these systems, not only for the people reading about them. A team that decides to build an agent can skip the earlier question of whether the task needs one. In many cases a fixed workflow is the better first build: easier to test, cheaper to run, and easier to explain when it fails.
The best argument for this comes from a company that makes its own agent tooling. Anthropic's post, Building effective AI agents, was published in December 2024. It carries a note at the top saying that "Much of the tooling landscape described in this post has changed since December 2024." So I am using it for its reasoning about when to use each pattern, not for its tool list.
Two things with one name
The post draws a line that most product pages blur. In its words, "Workflows are systems where LLMs and tools are orchestrated through predefined code paths." Agents, "on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks."
The practical difference is who decides the next step. In a workflow, the developer wrote the path in advance, and the model fills in each step. In an agent, the model chooses the path as it goes. The post says agents are "typically just LLMs using tools based on environmental feedback in a loop." Anthropic groups both under one heading, "agentic systems," but says it draws "an important architectural distinction" between them.
In my view, that distinction matters because the two are likely to fail differently. A workflow that breaks should break at a step you can name and inspect. An agent that breaks may have taken a route nobody planned for.
What the post says it costs
The post is direct about the price of autonomy. It says "Agentic systems often trade latency and cost for better task performance," and that "The autonomous nature of agents means higher costs, and the potential for compounding errors." It recommends "extensive testing in sandboxed environments, along with the appropriate guardrails."
Its advice follows from that: "we recommend finding the simplest solution possible, and only increasing complexity when needed." It adds that this "might mean not building agentic systems at all," and that "For many applications, however, optimizing single LLM calls with retrieval and in-context examples is usually enough."
Read that last sentence again. The company behind the Claude Agent SDK says a single, well-prompted call is often enough. I think builders should take that at face value. The post's closing advice is to "Start with simple prompts, optimize them with comprehensive evaluation, and add multi-step agentic systems only when simpler solutions fall short."
When an agent is the right call
None of this is an argument against agents. The post says agents fit "open-ended problems" where it is "difficult or impossible to predict the required number of steps," and where a fixed path cannot be hardcoded. Its examples are a coding agent resolving software issues and a computer-use setup where the model operates a computer.
Coding is a good fit for a reason the post gives: code solutions "are verifiable through automated tests," so the agent gets a real signal after each attempt. Our guide to coding agents explains how they work.
A test I would use
Here is my own checklist. It is not from Anthropic, and I have not tested it against a set of real projects.
- Can you write the steps down before the task starts? If yes, build a workflow.
- Does each step have a check you can run, such as a test, a rule or a human glance? If not, an agent's extra freedom is mostly extra risk.
- Is a wrong step easy to undo? The post warns about compounding errors, and in my view that risk is larger when actions are hard to reverse.
- Can the task afford the extra latency and cost the post describes? If not, stay with a workflow or a single call.
If you answer yes to the first question, you probably do not need an agent. If you answer no to the first and yes to the second, an agent may earn its place.
Tools do not settle it
A tool layer does not change this choice. A workflow and an agent can both call the same tools, and a standard like the one in our Model Context Protocol guide only gives either of them a common way to reach those tools. The post lists that protocol as one approach to giving a model access to outside tools. It does not say the protocol makes an agent the right architecture.
The post also warns that frameworks "often create extra layers of abstraction that can obscure the underlying prompts and responses, making them harder to debug." Its suggestion is to "start by using LLM APIs directly." I would add that this is easier to do when you have chosen a workflow, because there is less machinery to hide.
Where I could be wrong
The post reflects one company's experience with its customers, and it is dated December 2024. It is possible that better models have shifted the balance toward agents for more tasks than the post expected. I have not tested that, and the post does not claim it either. Its own note says the tooling has changed.
I also do not know how many products sold as agents are really workflows. My suspicion is that it is a lot, but that is a suspicion. What I am confident about is narrower: the choice between the two patterns deserves an explicit decision, made with the costs in view, and the default should be the simpler one. If you need a way to judge whether a model is good enough for a step, our guide to reading AI benchmarks is a place to start, with the caveat that a benchmark score is not a test of your own task.
Sources
- Building effective AI agents, Anthropic, published December 19, 2024
