Tyler Lucas

Defining an "Agentic Workflow"

Why the term agentic workflow is too imprecise on its own, and how to describe LLM-enabled workflows more clearly.

Overview

You can’t. There, I said it. But let’s take a step back, first.

To start – probably obvious – before LLMs came around, all automated workflows were “deterministic”. Meaning: an engineer defined the workflow steps, inputs and outputs, conditionals, and all other structure in advance.

But the term “agentic workflow” has become too fuzzy to be useful on its own. This post describes:

  1. Deterministic Workflows Defined
  2. Agentic Workflows Defined
  3. Problematic Language
  4. Takeaways

TLDR: Always describe workflow functionality at the step level, and clearly define orchestration patterns. “Agentic workflow” could describe a workflow that is fully orchestrated and executed by an LLM, or it could describe a deterministic workflow with a single LLM call – it creates confusion. Workflow systems need to be iterated to support LLM use-cases and clearly present relevant metadata.

Deterministic Workflows Defined

A quick definition of “workflow” (what we now might call a “deterministic workflow”) is “a repeatable, observable process that coordinates one or more activities to turn a defined trigger or input into a defined outcome.”

That definition makes sense. Ansible is a simple example of a workflow orchestration system, with an Ansible playbook being an example of a deterministic workflow.

Agentic Workflows Defined

A common definition of an “agentic workflow” is “a process in which an LLM makes bounded decisions during execution.” A looser definition, which I hear more often, is “a workflow that has at least one LLM step.”

At first glance, these definitions seem fine. We’re essentially saying that a workflow is agentic if an LLM is invoked or makes decisions. But when you dig into the details, things get murky quickly. Consider three scenarios:

  1. A workflow where an LLM is responsible for all orchestration and decision-making: it decides what information to gather, which actions to take, what to do next based on the results, and when the work is complete.
  2. A workflow with a predefined beginning and end, but where an LLM controls a defined phase in the middle. During that phase, it makes several decisions about which steps to take within established guardrails.
  3. A workflow where all orchestration and steps are predefined except for one LLM decision at the end, when it selects between two final, preapproved steps.

The first example feels agentic without a doubt. The second feels somewhat agentic because the LLM makes meaningful decisions, despite being wrapped in a deterministic workflow. The third does not feel agentic because the LLM function is minimally meaningful.

But all three meet the common definition of an agentic workflow! In each case, an LLM makes bounded decisions during execution. These examples differ in the scope of the LLM’s control: most of the workflow, one phase, or one branch.

That is why workflow agenticness – yes, creating one term to advocate retiring another – is a spectrum. It is not as simple as deterministic versus agentic.

Problematic Language

Ambiguous terminology in engineering organizations can range from a minor inconvenience to a source of serious structural problems. In my experience, AI-agent terminology is prolific – easily the most confusing and frequently misunderstood that I’ve ever observed.

Since late-2025 I’ve frequently heard phrases like:

  • “We will add an intelligence layer to …”
  • “We will train the agent to …”
  • “Replace our current workflows with agentic …”

Unless you’ve nailed down definitions upfront, this phrasing – in the best case – leads to wasted effort: a meeting stops while people clarify terminology: “You mean agentic, like an LLM is orchestrating? Or agentic, like an LLM is called to execute X step?”.

Or worse, it creates meaningful misalignment between teams and in strategic planning. Imagine that a senior leader funds an “agentic workflow system.” Engineers extend an existing deterministic workflow framework to support an LLM step that can select a tool. Leadership expected a system that could broadly plan and orchestrate work. Both sides reasonably believe they delivered or requested an agentic workflow system, but they mean fundamentally different things.

Takeaways

Because it is not possible to easily set thresholds for how much agenticness a workflow needs to be agentic (e.g., full-blown orchestration vs. selection between two tools vs. execution of a single step), the term “agentic workflow” is too imprecise to stand on its own.

Instead, we should do the following:

  1. Agentic steps, not agentic workflows. Describe behavior at the step level, as opposed to generalizing the entire workflow. Modern workflows will commonly combine deterministic steps with LLM-assisted or LLM-directed steps. Describing behavior at the step level is simpler and will lead to less confusion.
  2. Clarify the orchestration pattern. Articulate if a workflow contains deterministic code for orchestration, or if an LLM is selecting steps. If an LLM is involved, describe the part of the workflow it controls and the guardrails that constrain it. Misunderstandings here can have high blast radius/impact.
  3. Workflow systems need to present LLM information. Ensure that your workflow systems clearly present step metadata so that operators understand if a workflow is using deterministic or LLM-driven steps – this is important for troubleshooting. If unable to iterate workflow systems for this functionality, then centrally document workflows, underlying steps, and step-types as a fallback.

The line between deterministic and agentic workflows will keep blurring. As we build systems to support these use-cases, our success is often dependent on how effectively we communicate.