Start with a practical question: can the next steps be specified in advance, or must the system choose between tools and actions as the work unfolds? Both designs need explicit boundaries and a safe response to unfamiliar inputs.
What is a workflow, and where does it stop?
A workflow follows a predefined control structure. It can branch, apply rules and use a model inside a step. What is specified in advance is how those steps connect, not necessarily every result they produce.
That structure can make the process easier to test and inspect. It does not automatically make it cheap or correct: faulty mappings, integrations and missing checks can still create quiet errors.
A well-designed workflow includes exception paths. An unfamiliar message can go to a review queue with a reason rather than being lost. Unexpected input does not, by itself, establish a need for an agent.
What makes something an agent?
In an agentic design, the model chooses some next steps or tools at runtime within defined permissions. The goal, available actions and stopping conditions still need to be designed by people.
An agent may inspect a result and choose another action. Limit that loop by time, cost and allowed tools, and require approval where the consequences justify it. The system should not continue indefinitely merely because the goal is unfinished.
Anthropic’s engineering guidance distinguishes predefined workflows from agents that direct more of their own tool use. It is a useful working definition, not a guarantee that every product using the word follows it.
Why is the word used for almost anything?
Because it sells. A chat window with three canned replies gets called an agent, and so does a system that files a hundred documents a day without supervision.
Ask who chooses the next step and what constrains that choice. A workflow can handle varied messages; an agent can still stop on an exception. The meaningful difference is the control structure, not whether a demo handles a surprise.
How does an agent actually run?
An agent receives an input, selects an allowed action, observes the result and decides whether another action is needed. The surrounding system validates actions and enforces limits. Planning several steps ahead is one possible pattern, not a requirement for every agent.
An illustrative task might need two tool calls or ten. That variation is a reason to budget and monitor the run, with a clear limit and a useful handover when it cannot continue.
Which of the two does a business actually need?
Start with the simplest design that meets the need in testing. If the process has clear paths, a workflow is a strong candidate. Use a model within a step when interpretation helps, without handing it control over the whole process.
An agent becomes interesting when selecting the next action genuinely depends on what was discovered. Research across several sources can fit that pattern. Classifying email or extracting a field may still fit a predefined workflow.
What should you learn before adding autonomy?
Collect representative cases, identify permitted actions and define success. A simple workflow or a manually supervised prototype can expose exceptions, but neither is a compulsory first stage for every project.
Both workflows and agents need an owner for failures. Log what happened, make retry and rollback behaviour explicit and separate preparing an action from authorising a consequential one.
What changes over the next few years?
Expect product labels to keep changing. Evaluate the actual permissions, control structure and tested results rather than assuming that a newer label means a more capable or appropriate system.
What will not change is the question underneath: how much of the deciding is being handed over, and what happens on the day it decides something a person would not have.
