Foundations

What is an Agentic Workflow?

Also called: agent workflow

Updated June 24, 2026
Quick Definition

An agentic workflow is a multi-step process whose control flow is partly decided by AI agents at runtime rather than fully specified in advance. It mixes defined structure — the overall stages, the available tools, the stopping conditions — with model-driven choices about which action to take next, producing a path through the work that can differ from one run to the next.

Why agentic workflows matter

Conventional workflow engines run deterministic graphs: every step and branch is written by a developer, and the same inputs follow the same path. That model is reliable but rigid. It cannot handle work where the right next step depends on facts discovered along the way — classifying an ambiguous request, deciding which system to query, or recovering from an unexpected response.

Agentic workflows relax that constraint by letting a model make some of the decisions while the surrounding structure stays fixed. The benefit is adaptability: a single workflow can handle inputs whose exact handling was not foreseen. The cost is that part of the control flow is now non-deterministic, which makes the run harder to predict, reproduce, and debug. The engineering work in agentic workflows is largely about regaining that predictability — through durability, tracing, and constraints — without giving up the flexibility that motivated them.

How it works

An agentic workflow typically interleaves two kinds of steps:

  1. Defined steps — fixed stages, sequencing, and stop conditions that the author specifies, such as run a retrieval step, then a drafting step, then a review step.
  2. Agentic steps — points where a model decides what happens, such as which tool to call, which branch to follow, or whether the task is complete.
  3. Tool calls and handoffs — the actions an agentic step can take, including passing control to another agent for a sub-task.
  4. Checkpoints — the recorded outcome of each completed step, so the workflow can resume in place rather than restart after an interruption.

Because some steps are model-driven, two runs with the same input may take different paths. The defined structure keeps that variation bounded, and checkpointing keeps each run recoverable.

Agentic workflow vs. deterministic workflow

A deterministic workflow encodes every decision at design time; given the same input it always does the same thing, which makes it predictable but unable to handle the unforeseen. An agentic workflow defers some decisions to a model at runtime, trading guaranteed reproducibility for the ability to adapt. The two are not exclusive: a robust system usually wraps agentic steps inside a deterministic skeleton, so the unpredictable parts are isolated and the overall shape of the run stays under control.

In practice

Reliability for an agentic workflow comes from running it on a durable execution layer. A durable, observable runtime persists every step server-side, so a crash, redeploy, or pause resumes from the last completed step instead of re-running model calls and tool side effects. This combines durable execution with orchestration of the steps and, when several agents are involved, a multi-agent structure. For the broader case, see why durable agents.

Frequently asked questions

What is the difference between an agentic workflow and a fixed workflow?

A fixed workflow runs the same predefined steps every time. An agentic workflow lets a model decide some steps at runtime — which tool to call, which branch to take — so the path can vary with the input.

How is an agentic workflow different from RPA?

RPA replays scripted UI or API actions and breaks when the environment changes. An agentic workflow reasons about the current state and chooses its actions, so it can adapt to situations its author did not anticipate.

How do you make agentic workflows reliable?

Run them on a durable execution layer that persists each step, so a crash or redeploy resumes from the last completed step, and add observability and guardrails so non-deterministic decisions stay inspectable and bounded.

See also in the docs

Related terms