The question "should this be agentic?" is almost always answered at the wrong end of the process. Demos show the trigger and the result, and both look impressive. The decision actually lives in the middle: whether anything between those two points requires somebody to read something, weigh it, and choose what happens next. If nothing does, an agent adds cost and subtracts certainty. If something does, that middle is the one place agentic AI workflow automation earns its keep.
Call it the middle-of-the-process test. It costs nothing to run and it disqualifies most candidates in under a minute.
Almost every explanation of this technology skips it. The category pages define the term, the engineering blogs catalogue the patterns, and the enterprise vendors explain governance. None of that helps decide whether the invoice-matching process somebody owns on Tuesday belongs in this category at all.
So this piece does the definition quickly, then spends most of its length on the parts nobody covers: how to pick a candidate process, what it costs once it is running, and the specific ways these systems fail after the demo goes well.
What makes a workflow agentic
An agentic workflow is a business process where an AI model decides part of the control flow at runtime instead of following branches somebody wrote in advance.
That single property is the whole distinction, and everything else here follows from it. A conventional automation is a map drawn ahead of time. Every route through it exists because a person anticipated the situation and encoded a rule. An agentic workflow leaves some of the routing open, and a model picks the next step from what it just observed.
Anthropic's engineering team (2024) drew the same line and it has become the reference framing across this category: workflows orchestrate models through predefined code paths, while agents direct their own process and tool use. Most real systems land between those two ends, not at either one.
Four terms, pinned down before they get slippery:
- LLM - the large language model doing the reading, weighing, and deciding.
- RPA - robotic process automation, the rule-driven software robots that click through interfaces and move data.
- iPaaS - integration platform as a service, the connective layer between business systems.
- Human in the loop - a mandatory approval point where the process pauses until a person acts.
The practical version of the boundary: if you can draw the full flowchart before the process runs, you have an automation. If part of the flowchart can only be drawn after the model sees the input, you have an agentic workflow.
What counts as an agent, and what does not
An agent chooses. Nothing else in the definition carries as much weight, and almost every vendor claim sorts cleanly by that one property.
A chatbot that can call one tool is not an agent. A scheduled prompt that summarises yesterday's tickets is not an agent either. Both are useful. Both follow a path somebody fixed in advance.
An agent decides which tool to call, in what order, whether the result it got back is good enough, and when the job is finished. That last part matters more than it sounds. Deciding it is done is what turns a sequence of model calls into something that can run without a person watching each step.
Two questions cut through most vendor claims:
- Does the system choose its own next action, or does it walk a path somebody drew?
- Does it decide when to stop, or does the loop terminate because a counter ran out?
If both answers land on the second option, what you have is an automation with a language model inside it . That is often exactly the right thing to build. It just does not carry the risk profile described through the rest of this article.
How an agentic workflow runs, start to finish
The loop itself is simple enough to describe in one breath. Surviving production is the hard part, and that comes from everything wrapped around it.
One execution, end to end: a trigger fires and the system assembles context, meaning the input itself, whatever history is relevant, and the instructions that define the job. The model reads that and picks an action. A tool runs, returns a result, and the result goes back into the context. The model looks at the new state and either acts again or calls the work done. Output goes wherever it is supposed to go.
The components you cannot skip
- Tools with real boundaries. Every action the workflow can take is an explicit capability with defined inputs and permissions. An agent can only do what it has been handed.
- State that survives. The workflow needs to remember what it has already done inside a run, and that memory has to survive a crash. Mid-run state living only in process memory is a partial-completion incident waiting to happen.
- An exit condition. Something has to end the loop besides the model's own judgement. An iteration ceiling, a cost ceiling, or a time budget. Preferably all three.
- Guardrails on inputs and outputs. Checks that run before the model acts and after it produces a result, independent of the model itself.
- A trace of every run. What was in the context, which tools were called, what came back, what it cost. Skip this and you cannot debug the failures described later, because you cannot see them.
Where people sit in the loop
An approval gate is what makes a first project shippable. It buys back the certainty the loop gave away, and it does so at exactly the point where certainty is worth paying for.
The mechanic to insist on is durable pause and resume. The workflow stops at the checkpoint, holds its full state, waits however long the human takes, then continues from where it left off. Systems that cannot pause cleanly force a false choice between full autonomy and starting the run again from the top.
Place gates where an action becomes hard to undo. Sending an external message, moving money, changing a customer record, closing a ticket. Everything upstream of the irreversible step can usually run unattended.
Agentic workflows, deterministic automation, and single agents
Most comparisons on this topic stop at two options. There are three. The middle one is where nearly every successful project actually lives, which is the part the two-way framing hides.
Deterministic automation runs the same way every time. Same input, same path, same output, and the cost per run barely moves. Best for high-volume, low-variance work where the rules are stable and an exception is rare. Bad fit for processes where the exception queue keeps growing and someone keeps adding rules to catch up.
An agentic workflow fixes the overall shape of the process and leaves specific decisions to a model. The stages are yours. The judgement inside one or two of them is delegated. Best for processes with a stable skeleton and variable content, which describes most document handling, triage, and research work. Bad fit for anything needing identical behaviour on identical inputs.
A single autonomous agent is handed a goal and left to work out the route. Best for open-ended problems where the path cannot be specified in advance, and where a person reviews the output anyway. Bad fit for regulated processes, irreversible actions, or anything where you have to explain afterwards exactly why the system did what it did.
The trap here is picking the third option because it demos the best. The second one ships more often.
The patterns teams reach for first
Almost every working system turns out to be one of a small number of shapes, and they were catalogued early. Anthropic's engineering team (2024) named five that still cover most of what gets built:
- Prompt chaining - break a task into fixed steps, each model call handling one. Fits work with a natural sequence, like draft then check then format.
- Routing - classify the input first, then send it to the handler built for that class. Fits mixed inbound queues where different types need different treatment.
- Parallelisation - run several calls at once, either splitting subtasks or getting multiple opinions on the same one. Fits work where speed matters, or where a vote improves reliability.
- Orchestrator and workers - a coordinating model breaks the job into subtasks at runtime and delegates each. Fits work where the subtasks are not knowable in advance.
- Evaluator and optimiser - one model produces, another critiques against criteria, the first revises. Fits work with a quality bar you can articulate.
LangChain's plan-and-execute pattern is a close cousin of the orchestrator shape: plan the whole sequence up front, then execute the steps, replanning when reality diverges from the plan.
The deep versions of these are already documented well by the people who named them, and their write-ups beat any paraphrase. What none of them cover is which of your processes deserves one .
Which of your workflows should be agentic
Here is the middle-of-the-process test in full. Run a candidate through five questions before anybody writes a line of it.
1. Does the process need judgement in the middle, not just at the start? Judgement at the boundary is a classification problem and a classifier solves it. Judgement that recurs at several points, where each decision depends on what the previous step turned up, is the real signature of an agentic workflow.
2. Is the exception rate high and still climbing? A useful proxy: how often does somebody add a rule to handle a case the last rule missed? A rulebook that grows every month is describing a problem with no fixed shape. That is a candidate. A rulebook nobody has touched in a year is not.
3. Is a wrong step recoverable? Recoverable means you can detect the error and undo it before it reaches a customer, a ledger, or a regulator. If a mistake surfaces late and cannot be reversed, either the irreversible action moves behind an approval gate or the process stays deterministic. There is no third answer that survives contact with production.
4. Can you check success automatically? Not perfectly, but usefully. If the only way to know whether a run went well is a person reading the output, review cost scales with volume and the economics stop working. Something has to be checkable: a schema that validates, a total that reconciles, a downstream system that accepts or rejects.
5. Does the volume sit in the middle band? Too low and the engineering, evaluation, and monitoring never pay back. Too high and the per-run cost of model calls becomes a number your finance team will ask about. These workflows tend to earn their place on mid-volume, high-variance work, not at either extreme. (The exact crossover depends on your model choice, so treat this one as a direction rather than a threshold.)
A candidate that clears all five is worth building. Four out of five usually means fix the missing one first, most often by adding an approval gate or an automatic success check.
Workflows that should stay deterministic
Four categories are better left alone. Saying so costs us work we could otherwise sell, which is precisely why it is the most useful part of this article:
- High volume, low variance. Payment file processing, standard data syncs, scheduled reports. Rules already handle these at a fraction of the cost and none of the variance.
- Irreversible in a single step. Anything that moves money, sends external communication, or deletes records with no recovery path.
- Hard compliance requirements. Where you must reproduce the decision path exactly, a system that picks its own route at runtime is a liability, not a feature.
- Anything with a stable, small rulebook. If the rules have not changed in a year, the process lacks the variability that would justify the switch.
What an agentic workflow costs to run
The cost model differs from the automation you run today, and the difference is variance more than magnitude.
A deterministic automation costs roughly the same per run forever. An agentic workflow costs whatever its loop happened to need. The same input on a bad day can cost several times what it cost on a good one, because the model took more turns to get there.
Four cost drivers to name before a project starts:
- Iterations, not volume. The bill scales with how many times the loop goes round, and the loop count depends on input difficulty. Ten thousand easy runs can cost less than a thousand hard ones.
- The retry tail. Failures are rarely free. A tool that times out and gets retried three times has spent three times the tokens to produce nothing.
- Evaluation and observability. Traces, evaluation runs, and the harness that catches regressions are ongoing costs, not a one-off build. Almost nobody budgets for them at the start.
- Human review that does not go away. In year one, review time is part of the running cost. Planning for it to vanish at launch is how projects end up looking more expensive than promised.
No single credible per-run figure exists to quote here, because it depends entirely on your model choice, your loop depth, and your input mix. Your own number is measurable from day one, though. Instrument cost per run before you scale , and read a rising average as a design signal instead of a billing problem. OpenAI's own research on agentic work (2026) is one of the few published attempts to quantify the economics of delegated, long-horizon tasks, and it repays reading precisely because so little else is public.
Where agentic workflows break
The failures that hurt are the quiet ones. Every mode below shows up after the pilot succeeds, and each is named by the symptom an operator would actually notice.
- The loop that will not stop. The model keeps deciding there is one more thing to check. The symptom is a cost spike with no matching increase in output, or a run that never completes. The fix is boring and non-negotiable: hard ceilings on iterations, spend, and wall-clock time.
- Context drift on long runs. Turn after turn, the working context fills with intermediate results and the original instruction loses weight. The symptom is a run that starts on task and ends somewhere adjacent. Shorter runs, explicit state, and re-grounding at checkpoints all help.
- Silent tool failure. A tool returns an empty result or a stale value, the model treats it as fact, and it carries on. This is the dangerous one. The run completes successfully and the output is wrong. Validate tool results before they enter the context, not after.
- Partial state after a crash. The workflow died halfway through, with three of five actions already taken in external systems. Without durable state and idempotent actions, recovery becomes a manual reconstruction job.
- Confidently wrong output. Well-formed, plausible, incorrect. Shallow checks pass it. This is what sampling and human review are for, and it is why the automatic success check in the selection test carries so much weight.
What to instrument before you ship
- A full trace for every run, kept long enough to debug a complaint from last month.
- Cost per run as a distribution, not an average, so the tail stays visible.
- An alarm on runs that hit the iteration or spend ceiling. That ceiling is your early warning system.
- A sampled human review with a written quality bar, running continuously and not only during the pilot.
If you are weighing whether a process on your backlog clears the five questions above, and what it would take to run it properly, our Fractional Agentic Team does exactly that work as an embedded engagement rather than a hire.
Two examples worth copying
Both keep the skeleton deterministic and delegate only the judgement, which is the whole pattern in miniature.
Inbound document triage. A document arrives by email or upload. Extraction and filing stay rule-based, because those steps are identical every time. The agentic part is classification and routing: reading the document, working out what it is and which case it belongs to, and pulling whatever additional context it needs to be sure. Anything ambiguous or above a value threshold goes to a person. Success is checkable because the downstream system either accepts the filing or rejects it, which hands you an automatic quality signal from day one.
Internal research and draft. A request comes in for a piece of analysis. The agentic part is deciding which sources to consult and in what order, which is not knowable in advance. The output is always a draft, never a send. A person approves before anything leaves the building. The measurable outcome is time from request to approved draft, compared against the same process before.
Two things hold in both. The irreversible action sits behind a human. Success is measurable without somebody reading every output. That combination is what makes a first project defensible when it does not go perfectly. And it will not go perfectly.
Key takeaways
- An agentic workflow is one where a model decides part of the control flow at runtime. Everything else is an automation with a model inside it, which is often the better build.
- Apply the middle-of-the-process test: judgement in the middle, a growing exception rate, recoverable errors, automatic success checks, and mid-band volume. Five questions, one minute, most candidates disqualified.
- Cost scales with loop iterations more than volume, and the variance is the part that surprises people. Measure your own cost per run early.
- The dangerous failures are quiet. Silent tool errors and confidently wrong output complete successfully and look fine.
- Most processes should stay deterministic. For work that already has a stable shape, that is simply the correct answer.
