Stop Calling Every Workflow an Agent
Autonomy, recovery, and access boundaries matter. Without them, it is automation wearing new language.
Position
A sharper argument against a common default assumption.
Autonomy, recovery, and access boundaries matter. Without them, it is automation wearing new language.
Language models alone do not make a workflow agentic.
State, recovery, and constrained action are part of the definition.
Loose language leads to weak architecture and weak controls.
The word agent is becoming a way to make ordinary automation sound more advanced than it is. That may be useful for demos. It is not useful for architecture.
Use stricter language
If a system has no state, no recovery pattern, no scoped access model, and no meaningful decision latitude, it is probably not an agent. It is a workflow with a language model attached.
That distinction matters because the operating burden is different. Real agents need runtime controls, observability, approval boundaries, and clear definitions of what counts as success or failure.
Loose language creates bad design. Teams under-invest in orchestration and governance because they assume any tool-calling flow is already agentic.
A simpler test
I prefer a simpler test: can the system interpret context, choose a path, use tools under constraints, recover from failure, and produce auditable action? If not, call it what it is.
Naming matters because architecture follows language. If the label is sloppy, the implementation usually will be too.
Discussion
Responses, reactions, and open questions.
The article stays static. The conversation sits underneath it. Sign in with your email, react to the argument, and join the discussion.
Join the discussion
Use your email to get a one-time sign-in code. First comments may wait in moderation before they appear publicly.
Continue reading