A fixed automation does the same steps in the same order every time: when a form arrives, copy these fields, send that email. An agentic workflow gives an AI agent a goal and lets it choose the steps, the tools and the order, within limits someone has set. That flexibility is the point, and it is also the risk. This page explains what makes a workflow agentic, how it differs from the automation most teams already run, and where human decisions belong so the agent can do real work without anyone losing control of it.
What makes a workflow agentic
A workflow is agentic when at least one step is decided at run time by a model rather than written in advance by a person. In practice that means the agent:
- reads the situation, such as an email, a document or a ticket, and decides what kind of work it is;
- chooses which tools to call and in what order;
- handles cases nobody wrote a rule for, by reasoning about the goal;
- checks its own intermediate results and tries again when something looks off.
The agent itself is the model plus its tools and instructions, covered in what an AI agent is. The workflow is everything around it: the goal it receives, the limits it runs inside, the points where it must stop and ask, and the record of what it did.
Fixed automation and agentic workflows compared
| Question | Fixed automation | Agentic workflow |
|---|---|---|
| Who decides the next step | A rule written in advance | The agent, at run time |
| Unexpected input | Fails or takes a default path | The agent reasons about it, sometimes wrongly |
| Predictability | Same input, same steps | Same input may lead to different steps |
| How failure looks | An error, usually loud | A plausible but wrong result, often quiet |
| How you test it | Test the rules | Test outcomes against acceptance criteria, repeatedly |
| What you review | Logs, when something breaks | Results and the trail of steps, routinely |
The row that matters most is how failure looks. Scripted automation tends to break loudly. An agent tends to produce something that looks finished. That is why agentic workflows need written acceptance criteria and a readable record, not just error alerts.
A spectrum, not a switch
Few useful workflows are fully agentic. Most sit somewhere along a range:
- Scripted, with an agent in one step. A fixed pipeline where one step, such as classifying an incoming document or drafting a summary, is handed to a model. Easy to control; the agent cannot change the route.
- Agent-planned, within a fixed toolset. The agent picks steps from a small set of approved tools to reach a defined goal. This is where most of the business value sits today.
- Agent-planned, with delegation. The agent can start other agents or schedule follow-up work. Powerful, and the place where limits matter most.
Choose the lowest level that does the job. If you can write the rule, write the rule: a scripted step is cheaper, faster and easier to audit than a model making the same choice every time. Agents earn their place where the input varies too much for rules, as in agentic search, where the next query depends on what the last one found.
Anatomy of a well-defined agentic workflow
Whatever tool you use, a workflow an agent can run safely has the same parts:
- A goal, stated as an outcome rather than a list of steps.
- A scope: which data, systems and folders the work may touch.
- Acceptance criteria: how anyone can tell the work is done and correct. See write acceptance criteria before the agent starts.
- Bounds: limits on time, tool calls and spend, so a confused agent stops instead of looping.
- Decision points: the actions that wait for a person.
- A record: every step, source and decision, kept where reviewers can read it.
GoCux bundles these parts into a work order. Each piece of work gets one order holding its goal, the scope it may touch and its acceptance criteria, together with a project, a data classification and limits on wall time and tool calls; set the tool-call limit to zero and the agent may call no tools at all. An order passes through four states, queued, running, awaiting decision and done, and nothing downstream begins while it waits on a person. Each step is written to the order's record the moment it happens, so the result, its sources and the decisions stay together. More on the Task page.
Where human decisions belong
The common mistake is to ask for approval everywhere or nowhere. Approve every step and people click through without reading; approve nothing and the first bad action is also the first time anyone looks. Put decisions where an action has consequences that are hard to undo or that leave the organization:
- sending something to people outside the team;
- deleting or overwriting data;
- exporting files or records;
- scheduling work that will run later with nobody watching;
- acting inside a live session on someone's behalf;
- changing the agent's own instructions;
- putting another agent to work.
This is the list GoCux uses: these seven classes of consequential action wait for someone on the team to decide, while all other work proceeds within the limits you have set, without a pause. The reasoning behind each class is in the seven action classes that pause for a person, and the wider policy is on the governance page.
How a decision is presented matters as much as where it sits. A good decision point shows the exact action the agent wants to take, word for word, not a summary of it. It applies to that one attempt and is checked again when the action actually runs. A rejection is recorded and keeps the work held, rather than letting the agent find another route to the same result. Decide in advance who may approve agent work, because the person who wrote the request is not always the right one.
Two further human decisions sit outside individual steps: accepting the result against the criteria at the end, and being able to stop everything at once. In GoCux, work draws on visible credits under a daily cap and halts, saying so, when it reaches the ceiling. A single stop control halts new work and anything with external effects, and restarting is a deliberate act recorded against a person. These features look dull until the day an agent misbehaves.
Designing your first agentic workflow
A worked example: a weekly review of changes to supplier contracts kept in a shared folder.
| Step | Done by | Why |
|---|---|---|
| Find contracts changed since last week | Script | A rule can do it; no judgement needed |
| Compare each change with the previous version and summarize it | Agent | Wording varies; it needs reading |
| Flag changes to payment, liability or termination clauses | Agent, quoting the clause | Judgement, but checkable against the quote |
| Draft a note to the contract owner | Agent | Low risk while it stays a draft |
| Send the note | Person approves | It leaves the team and is hard to take back |
| Accept the weekly summary | Person | Checks it against the acceptance criteria |
Before you build, check:
- Could a fixed rule do any of the agent's steps? Move those to a script.
- Is the goal written as an outcome, with acceptance criteria someone else could apply?
- Are the scope and the limits on time, tool calls and spend written down?
- Does every consequential action pause, and does the pause show the exact action?
- Is a rejection recorded and final for that attempt?
- Can a reviewer read every step, source and decision in one place?
- Does someone know how to stop the whole thing, and who is allowed to restart it?
Bring this workflow into your workspace.
Set the scope. Review the evidence. Approve the steps that need it.