Agents vs workflows: what actually belongs in a runtime loop?

TL;DR: Most systems marketed as agents are really workflows with one LLM call, according to Archestra, and the practical divider is whether control flow is fixed up front or chosen at runtime. The distinction matters because workflows are cheaper, easier to audit, and less exposed to unbounded loop failure modes.

Editorial analysis by NHI Mgmt Group, based on content published by Archestra: “Most "agents" are workflows with a trigger”.

Key questions

Q: What is the difference between an AI agent and an agentic workflow?

A: An AI agent is the autonomous software entity that decides and acts.

Q: When should a team choose an agent instead of a workflow?

A: Choose an agent only when the number of steps is not known in advance, each result changes the next question, or tool selection depends on runtime state.

Q: What are the security risks of allowing an AI model to choose its next action?

A: The main risk is that the system stops behaving like bounded software and starts behaving like a runtime decision-maker.

Practitioner guidance

• Classify systems by control-flow shape Document whether the path is fixed in advance or selected at runtime by the model, then use that classification to decide whether the build is a workflow or an agent.
• Limit runtime authority for adaptive loops If the model can choose the next step, scope its tool access, constrain the action set, and define a hard stop condition before deployment.
• Audit LLM use inside deterministic pipelines Treat embedded LLM calls as bounded functions when the surrounding graph is fixed, and review them for data handling, output shape, and failure recovery rather than autonomy.

Bottom line: Most systems sold as agents are still deterministic workflows with one model call embedded in the middle.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →