Agents vs workflows: where runtime choice really starts

At a glance

What this is: This article says the real line between agents and workflows is runtime control flow, not marketing language or whether an LLM appears in the system.

Why it matters: That matters because IAM, NHI, and AI security teams need to govern deterministic automation differently from adaptive loops that choose tools and next actions at runtime.

Context

The core issue is not whether a system uses an LLM, but whether the next step is predetermined or selected after observing the previous result. In identity and security programmes, that distinction changes how you assign trust, scope tools, and review execution paths.

Once a model can decide the next action during runtime, the system stops behaving like conventional automation and starts behaving like a policy-bearing runtime actor. That is where governance questions shift from code review to delegation, authorization, and containment.

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. An agentic workflow is the broader process that coordinates one or more agents through planning, execution, reflection, and reporting to reach a goal. The agent is the actor, while the workflow is the system that governs how work gets done.

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. If the task can be described as a fixed sequence of actions, a workflow is usually safer, cheaper, and easier to test. The default should be deterministic orchestration, not adaptive autonomy.

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. That makes it harder to predict, audit, and contain, especially when tool access is broad or the loop can continue until the model decides it is finished. Governance has to move from static review to runtime authorization and logging.

Q: How should security teams govern agent workflows at runtime?

A: Security teams should govern agent workflows with controls that evaluate prompts, tool calls, and outputs during execution, not only after deployment. Runtime checks matter because risk can appear at each stage of the workflow. The goal is to stop unsafe behavior before it becomes an executed action or a leaked response.

Technical breakdown

Deterministic workflows vs adaptive loops

A workflow is a directed set of steps where the path is known before execution starts. An LLM may appear inside that path, but it behaves like a bounded function call with a fixed input and output shape. An agent is different because the model chooses the next step after seeing the previous outcome, which means the control flow is not fully known in advance. That runtime choice is what creates ambiguity around testing, rollback, and authorization boundaries. In practice, the more freedom the model has to decide the next move, the less the system resembles ordinary software and the more it resembles a decision-making runtime. Read AI Agents vs Agentic AI.

Practical implication: Treat runtime decision authority as a governance boundary, not just a code pattern.

Why most so-called agents are still workflows

Most production systems labelled as agents are really small DAGs with one LLM step embedded in them. The trigger, branching logic, and downstream API calls are still deterministic, so the model is only doing local work such as classification, extraction, or drafting. That structure is materially different from an adaptive loop that can continue deciding until it believes the task is complete. The security implication is that many teams are carrying agent-language while operating workflow-risk, which leads to overcomplicating controls or underestimating where the actual failure modes sit. The design should follow the real control shape, not the product label. See the AI Agent Identity Security Buyer's Guide.

Practical implication: Classify the system by execution shape before deciding how much autonomy it really needs.

When runtime choice justifies an agent design

A loop becomes defensible when the number of steps is not known in advance, when each result changes the next question, or when tool selection cannot be enumerated ahead of time. That includes open-ended research, multi-system recovery, negotiated execution, and very large tool surfaces where the correct tool depends on runtime state. In those cases, forcing a workflow often produces brittle branching, while the adaptive loop is the cleaner model. The trade-off is that the security and governance burden rises sharply because you are delegating sequencing decisions to the model itself, not just the content of a single call. See the AI Agent Authorisation Guide.

Practical implication: Use agent logic only when dynamic sequencing is essential, not because the task sounds advanced.

Threat narrative

Attacker objective: To exploit the gap between assumed workflow determinism and actual runtime autonomy, creating unsafe or unreviewed actions.

1. Entry occurs when a model is allowed to choose the next action at runtime instead of following a fixed plan.
2. Escalation happens when that runtime choice extends from a single LLM call into repeated tool use, expanding the decision surface and the blast radius of error.
3. Impact is a system that is harder to audit, harder to bound, and more likely to execute unintended actions if the loop is trusted as if it were deterministic.

Breaches seen in the wild

• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Most agent branding is really governance debt in disguise: when organisations call a bounded workflow an agent, they often overstate autonomy and understate the controls needed around delegation, logging, and rollback. The operational risk is not the label itself but the false assumption that a model has earned decision rights it does not actually need. Practitioners should classify systems by control flow first and by branding last.

The important security question is not whether an LLM is present, but whether it can choose the next step: that is the point at which execution becomes policy-sensitive. A fixed-shape workflow can be tested like software, but an adaptive loop changes the control problem into one of runtime authorisation and containment. Security teams should treat that transition as a governance threshold, not a feature upgrade.

AI agents vs agentic AI helps separate terminology from operating model: the article's distinction maps cleanly to the difference between a system that executes a known graph and one that keeps selecting actions as it learns from outcomes. That matters because autonomy is not binary, and governance fails when teams collapse all model-driven systems into one risk bucket. Practitioners should map each system to its real execution pattern before assigning controls.

The right control lens changes with the architecture: workflows call for predictable auditing, bounded retries, and deterministic approvals, while agents require runtime decision logging, tool scoping, and kill-switch thinking. The governance mistake is to apply one control model to both. Security teams should align review depth to how much of the execution path is being decided by the model at runtime.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Control-flow clarity should become a design requirement: teams will keep calling everything an agent until architecture reviews force a sharper distinction between fixed graphs and runtime decision loops. That distinction matters because governance, logging, and privilege controls differ once the model starts choosing the next step.

The next maturity step is to align autonomy with evidence. If a system cannot justify why it needs runtime sequencing, it should remain a workflow with bounded LLM use rather than a broader decision loop.

A useful programme pattern is to map every AI system to the point at which control shifts from code to model, then apply AI agent authorisation only where that shift is real.

For practitioners

• 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. See the AI Agent Authorisation Guide.
• 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.
• Reserve agent architecture for genuinely open-ended tasks Use an adaptive loop only where the next step cannot be written down upfront, such as multi-system recovery or large runtime tool selection.

Key takeaways

• Most systems sold as agents are still deterministic workflows with one model call embedded in the middle.
• The practical divider is whether the next step is preplanned or selected at runtime after observing an outcome.
• Governance should follow execution shape, because workflow controls and adaptive-loop controls are not the same thing.

Related NHI Mgmt Group resources: AI Agents vs Agentic AI · AI Agent Authorisation Guide · AI Agent Observability, Audit and Incident Response Guide · Agentic AI Identity Risk Board Briefing

Key terms

• Agentic Loop: The execution cycle where an AI agent interprets a goal, chooses actions, calls tools, observes results, and continues until the task is complete. In governance terms, the loop matters because authority is exercised repeatedly at runtime, not just at initial approval.
• Deterministic Workflow: A deterministic workflow is a fixed sequence of investigation steps that produces the same output when given the same inputs. In SOC automation, it reduces variability, improves auditability, and creates a stable evidence trail before any AI reasoning is applied.
• Runtime decision authority: The ability of a system to choose actions, timing, or tool use during execution rather than following a fixed script. In an autonomous SOC, this changes governance because the system is no longer just executing instructions, it is determining what work enters the human workflow.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and workload identity. It helps security and identity teams apply the same discipline to autonomous systems, service accounts, and other governed identities.