Agentic Workflow: What Actually Changes When Software Decides the Next Step

Agentic Workflow: What Actually Changes When Software Decides the Next Step

An agentic workflow is a workflow in which a model, given a goal and a set of tools, chooses which step to run next, rather than executing a fixed order of steps defined in advance. The distinguishing property is that the control flow is decided at run time. A conventional automation knows its route before it starts and follows it every time. An agentic workflow knows its destination, holds a set of things it is permitted to do, and works out the route as it goes.

The term exists because the older vocabulary stopped describing what people were building. "Automation" implies a defined path, and for thirty years that was accurate: someone drew the path and the software walked it. Once a model could read an intermediate result and decide what to do about it, the path stopped being a property of the system and became a property of each individual run. That is a real difference in kind, and it needed a word, because everything about how you specify, test, debug and supervise the thing changes when the route is not fixed.

How an agentic workflow actually works

Four parts, and a workflow missing any of them is something else wearing the name.

A goal. Stated as an outcome rather than as instructions. "Find the operations lead at this company and confirm the address" rather than "search here, then check there, then verify". The looser the goal, the more room the model has and the more variance you get between runs.

Tools the model may call. Search, a scraper, a database query, a verification API, a write to a record, a send. The tool list is the workflow's entire capability surface. Anything not on the list cannot happen, whatever the model decides.

Memory of what it already did. Results of previous calls, held so the model can avoid repeating work and can reason about what it has learned. Without this an agent loops, re-running the same failing call because nothing recorded that it failed.

A stopping condition. When the goal is met, when a budget is spent, when a step count is exceeded, or when the model reports it cannot proceed. This is the part most likely to be underspecified and the part whose absence is most expensive.

The ladder from automation to agency

The useful thing about the term is not the binary. It is that there is a ladder, and most working systems sit on the middle rungs rather than at the top.

1. Step 1Fixed automation

   Every step and its order defined in advance. No model involved anywhere

2. Step 2A model at one step

   The order is still fixed. A model classifies, extracts or drafts inside one box

3. Step 3A model chooses the branch

   The order varies within a set of routes somebody wrote down and approved

4. Step 4A model chooses the order

   Given a goal and tools, the route is constructed per run. This is the agentic case

Rung two is where most production value currently sits, and the marketing for rung four is usually describing something on rung two or three. That is not a criticism of the products. It is a reason to ask which rung you are buying, because the supervision each one needs is completely different.

The two decisions that matter most

The stopping condition. An agent without a hard stop will keep going, because continuing is always locally reasonable when the goal has not been met. Real stopping conditions are boring and mechanical: a maximum step count, a maximum spend, a wall-clock limit, an explicit surrender path the model can take when it cannot find what it was asked for. The surrender path matters more than it sounds. A model with no way to say "I could not do this" will produce something that resembles success, because producing something is the only move available to it.

Tool permissions. The tool list defines the blast radius. A workflow that can read anything and write nothing has a maximum bad outcome of wasted time. A workflow that can send email has a maximum bad outcome sitting in a stranger's inbox with your name on it. Deciding the permission set is the design decision, and it deserves more attention than the prompt does, because the prompt is advice to the model and the permission list is a wall.

Where the textbook definition breaks

The definitions describe autonomy as a capability. Budgets approve it as a labour saving. Those two framings diverge at exactly the point where a wrong step is expensive, and that point is much easier to locate than the general debate suggests.

Reversibility is the line. In outbound work, research, classification and drafting tolerate a wrong step, because the cost of being wrong is a discarded draft. Nobody outside the team ever sees it, and the correction is free. Anything that spends money or reaches a prospect does not tolerate a wrong step, because a wrong step there is already in someone's inbox. There is no version of "undo" for a message that was sent, and a bad one spends both the recipient's goodwill and the sending reputation the rest of your programme depends on.

Reversible stepsA wrong answer costs a discarded draft

• Researching what a company publicly says
• Classifying an inbound reply by intent
• Extracting fields from a messy page
• Drafting a first version against a tight brief
• Deciding which of several routes to try next

Irreversible stepsA wrong answer is already in someone's inbox

• Sending anything to a prospect
• Spending money on data or credits
• Writing to a shared system of record other people act on
• Committing to a time, a price or a claim
• Anything a recipient experiences as a person contacting them

The general rule we work to: give an agent the reversible steps and hold the irreversible one behind a person. In our own outbound that means research, enrichment, classification and drafting can be automated aggressively, and the send itself is a human decision made against the rendered output. The rule is simple to state and it survives contact with almost every system we have built, because it does not depend on how good the model is. It depends on whether a mistake can be taken back.

The second break: an agentic step that fails silently is worse than an automation that errors. A fixed pipeline that breaks stops. It throws, the job goes red, somebody looks at it. An agent that cannot complete its task will usually do something adjacent and report success, because it is optimising for producing an acceptable-looking result and an adjacent task produces one.

That failure mode has a specific shape worth recognising. Asked to find a named executive's address and unable to, the model returns a plausible address at the right domain. Asked to research a company with a thin public footprint, it writes a confident paragraph assembled from what it already believed about companies of that type. Neither output arrives flagged as uncertain. Both look exactly like the successful cases, which is why sampling the output catches this and monitoring the job status never will.

The metric trap this creates

Agentic workflows are frequently pointed at an optimisation goal, and the goal is usually a number pulled from a platform. That is worth examining before it is automated, because the platform numbers in cold email are known to be inflated.

1.38%Platform reply counter

What the sending platform reported across the dataset

0.48%Human reply rate

After every reply was classified by hand

2.86xOverstatement

The counter includes automated responses

Our own 2026 cold email benchmark report, built on 1,413,405 sends spanning 356 campaigns with every one of 19,544 replies classified by hand, separates the two: a platform reply counter read 1.38% where genuine human replies were 0.48%, an overstatement of 2.86 times, because the counter counts automated responses as replies. The same report found a platform bounce counter reading 3.04% where genuinely bad addresses were 1.27%.

Hand an agent a goal expressed as "raise the reply rate" and a tool that reads the platform counter, and it will optimise the inflated number. It has no way to know the number is inflated, and it will find the cheapest route to moving it, which may be a route that moves the real number in the opposite direction. This is the ordinary hazard of optimising a proxy, made worse by speed and by the absence of anyone reading the intermediate steps.

What to do with it

Start by locating your workflow on the ladder honestly, then decide the permission set before the prompt. Those two steps determine almost everything about how much supervision the thing needs, and both are cheap to do at the start and awkward to retrofit.

Then build the sample. Automated work needs somebody reading actual rendered output on a schedule, not job statuses, because the failure mode is confident wrong output that completes successfully. Reading twenty real outputs before anything goes anywhere finds problems that no amount of pipeline monitoring will surface.

Log the refusals. Every time the workflow could not do something and said so, record it. That log is the only honest measure of coverage: it tells you which share of your inputs the system genuinely serves, and it usually reveals that it works well on a minority of accounts with a strong public footprint and adds little on the rest. Knowing that split changes the plan, because the answer for the remainder is a different approach rather than a better prompt.

And keep the irreversible step where a person can see it. In our own work, each campaign carries one message built on one premise, and it goes out once, which means the decision to send is a single reviewable moment rather than a stream of automated actions nobody is watching. Whatever your own structure, the principle transfers: the more of the route the software decides, the more it matters that the last step is decided by somebody who can be asked why.

Related terms and guides

The category boundary, and how to tell a genuine agent from a workflow with a chat interface on it, is worked through in AI sales agents. Which parts of a lead generation workflow actually absorb autonomy well, stage by stage, is the subject of agent lead generation.

For concrete applications rather than definitions, eight GTM agent workflows covers patterns that are working now, and Clay agents and Claygent is a worked example of grounded enrichment, which is the reversible half of the split above. The personalisation question that sits immediately downstream of it is covered in advanced email personalisation with Clay.

If you would rather see a campaign built and run against your own market than assemble the workflow yourself, see what a first campaign looks like.