An agentic workflow is a process in which some or all steps are carried out by AI agents, with the model deciding at least part of the sequence at run time rather than following a fixed script. The degree of model control ranges from one decision point inside a scripted pipeline to a fully open-ended loop.
The phrase spread through 2024, when Andrew Ng argued that wrapping a model in an iterative workflow could matter more than upgrading the model: in his example, GPT-3.5 inside an agent loop outperformed GPT-4 answering in one shot on a coding benchmark. Since then the word “agentic” has been applied to almost anything that calls a model. The useful question is not whether a workflow is agentic, but how much of its sequence the model decides, and what changes as that share grows.
A spectrum, not a category
Anthropic draws the line between workflows, where models and tools are orchestrated through predefined code paths, and agents, where models direct their own process and tool use. Harrison Chase of LangChain describes the same ground as a ladder of increasing model control: plain code, a single model call, a fixed chain of calls, a router where the model picks the next step, a state machine that adds a loop, and a fully autonomous agent.
| Who decides the next step | Example | What a run is |
|---|---|---|
| The code, always | A fixed chain: extract, summarize, format | The same path every time |
| The model, at one point | A router sends each ticket to billing, refunds or technical support | One of a few known paths |
| The model, repeatedly | A state machine or agent loop that continues until done | One of many possible paths, some never seen before |
| The model, including its own tools or plan | An autonomous agent that writes its own subtasks | A path that may not resemble any earlier run |
By the approved definition, a workflow becomes agentic at the second row: the first point where the model, not the code, decides what happens next.
Every run is an execution and a sample
Moving down the table changes what a single run tells you. Every run is an execution: it happened, step by step, and can be recorded and examined. Below the router, it is also the whole story, because the path is known in advance: a run can be tested once, replayed and reasoned about. Above it, a run is also a sample: one path out of a space of possible paths, and the next run may take a different one. Anthropic’s account of its multi-agent research system says it directly: runs are non-deterministic, even with identical prompts.
Three practices change when runs become samples as well as executions.
- Testing. A test that passed proves that one path worked. Confidence comes from many runs and from judging outcomes. Anthropic recommends evaluating whether a run reached the correct final state rather than whether it followed a prescribed process.
- Cost. Cost tracks tokens, and token use varies by path. In Anthropic’s research, token usage alone explained 80 percent of the variance in performance on its evaluation. A workflow’s cost is a distribution with a tail, not a price per transaction.
- Approval. An organization approves a workflow once, at design time. For a scripted pipeline, that approval covers every run. For an agentic workflow, it covers the space of paths the designers had in mind. The run that actually happens may be a path no one reviewed.
That last point is where judging only by outcomes stops being enough. For quality, the final state is the right test. For accountability, the route matters: which tools touched which data, and whether a step was within what the workflow was for.
Every decision handed to the model has to be stated
In a scripted pipeline, intent lives in the code. The sequence says what the process is for and what it may touch, and a reviewer can read it. Each step handed to the model removes a piece of that built-in statement. A router no longer encodes which path is right for this ticket; the model decides. A loop no longer encodes when to stop; the model decides that too.
The intent does not disappear. It has to be stated somewhere else: the objective, the systems the workflow may reach, the operations that are in bounds, the budget. That statement is declared intent together with its scope. The more of the sequence the model controls, the more of this has to be declared, because less of it can be read from the code. When a run’s path leaves what was declared while still reaching a plausible answer, that is agent drift: not a crash, but a valid run that wandered.
An example
A team automates vendor onboarding. Version one is scripted: collect documents, run a sanctions check, create the vendor record, email procurement. Version two is agentic: a model reads each submission and decides which checks it needs, asks for missing documents, and decides when the vendor is ready.
Version two handles edge cases that used to wait for a person, and the team is right to adopt it. But the approval that covered version one now covers far more. On one run, the model decides a long-standing supplier can skip the sanctions check because a check from last year is on file. The run completes and the vendor record is correct. Whether that path was acceptable is a question about the workflow’s intent.
It is also a particular kind of problem: a required step is missing. A missing step leaves nothing to observe at the moment it is skipped, so it cannot be found by watching the actions a run attempts. Required steps have to be checked by the workflow itself, for example as a completion condition the run cannot pass without, or by an evaluation that compares runs against the steps they were required to include.
On another run, the model emails the vendor’s bank details to an external address to confirm them. That is the opposite kind of problem: an action the workflow should not have taken. Unlike the skipped check, it is visible at the moment it is attempted.
Where Sentience fits
Sentience Governor, the free, open-source runtime governance library, records the path. Each run declares its objective and scope; each action the model chooses is recorded at the execution boundary and evaluated against the declared scope and the operator’s policy, with the objective kept as context. Steps outside the declared scope are flagged, so a review can look at the routes runs actually took, not only their results. Governor sees the actions a run attempts, such as the email in the example. It does not detect a required step that was never taken; that belongs to the workflow’s own completion checks or to evaluation. Governor records and flags; it does not change the run.
Agentic workflows are also where the question “is this ready for production?” is hardest to answer from a design document. Sentience Secure Runtime is built for that step: teams run a workflow in an isolated environment with policy enforcement and controlled egress, validate how it behaves across real runs, and keep what works as a reusable deployment template for production. The approval then rests on observed behavior, not only on the design.
Often confused with
An agent loop. The loop is a mechanism inside an agent. An agentic workflow is a process, which may contain loops, fixed steps and human checkpoints.
Agent orchestration. Orchestration is how the parts of a system are coordinated. A workflow can be orchestrated by code, by a model, or by both; how agentic it is depends on how much the model decides.
Agentic AI. Agentic AI describes the general capability of systems that pursue goals with autonomy. An agentic workflow is one concrete process built with that capability.
Where the concept stops
Calling a workflow agentic says who chooses the steps. It does not say whether the steps chosen were right, whether a given run stayed within what the workflow was approved for, or how much of the workflow’s intent was ever written down. Those depend on declaring the intent the code no longer carries, and on comparing each run’s path against it.