Run the same task twice with the same input. Does your AI agent take the same path both times? If you are not sure, you have met the trade-off this post is about.
Every product with an AI feature is now "building agents". AWFlow has agents too: you can create them, give them skills, chat with them and let them run things for you. But underneath, they run on workflows. This post explains why we made that choice and how it shows up in the code. It is the first in a series on how AWFlow works inside.
The trouble with pure agents
A pure agent is a loop: the model looks at the state, picks the next action, observes the result and repeats. It decides every step at run time.
It stops when it thinks it is done. Next run, the path may differ.
That flexibility is the point, and also the problem:
- Different path every run. Same task, same input, a new plan each time.
- Hard to debug. When something goes wrong, you read a transcript instead of pointing at a step.
- Scary unattended. Would you schedule it for 3am with nobody watching?
- Every step costs a model call, including the steps that never needed any thinking ("open the page", "append a row").
What a workflow gives you
A workflow is a graph you can read: a trigger, some steps, an output. (If the term is new, what is an agentic workflow covers the basics.)
- Same input, same path. It is deterministic by construction.
- Every run is recorded with each step's inputs and outputs, so a failure points at one box.
- Safe to schedule, because it only does what is drawn.
Put the two side by side and the workflow wins on predictability, debuggability, cost and running unattended. The agent wins on one thing: handling the case nobody drew a box for.
| Workflow | Autonomous agent | |
|---|---|---|
| Same path every run | Yes | No |
| When it breaks | Point at one step | Read the transcript |
| Cost per run | Fixed | Grows with each step |
| Handles the unexpected | Only what you drew | Yes |
| Safe unattended | Yes | Only with guardrails |
It is less a choice between two things than a dial. At one end, the graph decides everything. At the other, the model does.
All agent: handles surprises, but a new plan and a model call at every step.
So the useful question isn't "workflow or agent?" It is where each one belongs.
A deterministic skeleton, with AI in the slots
Our answer fits in one line.
The graph decides what happens next. The model never picks the path.
In AWFlow, the workflow is the skeleton. Here is a small one that checks a page every morning and tells you only when something is urgent.
You get a message only when it matters. The run ends in one place, recorded step by step. If it goes wrong, you point at a box.
It starts on a schedule
The trigger is drawn, so you know exactly when it runs. Nothing wakes up because a model felt like it.
It reads the page
Opening a page and reading its text needs no judgement. A plain node does it, the same way every time, and costs no model call.
The AI step decides a value
This is the slot where judgement is needed. The model reads messy text and returns one value: "urgent" or not.
The graph decides what happens next
An If node looks at that value and picks the path. The model never chooses which box comes next.
You get a message only when it matters
The run ends in one place, recorded step by step. If it goes wrong, you point at a box.
You get a model's judgement where it is needed, the predictability of a flowchart everywhere else, and you only pay for model calls in the steps that need judgement. The same idea runs through the engine. When our assistant generates workflows with small local models and the model gets the graph structure wrong (a missing trigger, a dangling edge), we fix it in code instead of asking the model to try again. Our post on LangChain and LangGraph in the browser shows that build graph and its repair loop.
Even our agents are workflows
When you give an agent a routine ("check this page every morning and tell me what changed"), AWFlow doesn't spin up a hidden agent loop with its own scheduler. It builds an ordinary workflow: one of the existing triggers, followed by a "Run agent" node.
The answer is saved as a chat you can open and continue.
The "Run agent" node hands the task to one of your agents (or to Aria, the built-in assistant). The agent uses its own model, instructions, memory, skills and rules.
Out comes the reply, ready for the next step.
Because a routine is just a workflow, it gets everything the engine already does:
- scheduling, including catch-up runs
- run history, like any other workflow
- editing on the canvas: no hidden agent loop, nothing you can't open and change
We didn't build a second runtime for agents. We reused the deterministic one.
When nobody is watching, the agent doesn't improvise
Agents have rules: each kind of action is allowed, asked first, or blocked. In a chat, "ask" shows an approval card and you click. In a background routine there is nobody to click.
It shows up in Activity for you to deal with later.
So in a background run, an action marked "ask" is declined, not guessed, and listed in the agent's Activity for you to deal with later. Predictable even when it is intelligent.
A rule of thumb
The result must be the same every time.
Use an AI step when:
- the step needs judgement
- the input is messy text or a web page
- a wrong guess is cheap, or a human reviews it
In our experience, most real automations are mostly the first kind, with one or two judgement calls in the middle. Model the first kind as a graph and put AI in exactly those one or two slots.
No guessing when nobody is there.
The smallest version of this idea is a workflow with exactly one AI slot: read the page, let a local model summarise it, show the result. Everything around the AI step is drawn.
Try it. A drawn workflow with one AI step in the middle.
Interactive version with animations: https://awflow.io/blog/our-ai-agents-run-on-workflows
Try it
Agentic Workflow (AWFlow) runs in your browser, on the model you choose, free and with no account needed to start. Intall it from the chrome store here.
Top comments (0)