Agentic workflows: when software should decide the next step
How to decide when a workflow should be agentic, deterministic, or a hybrid of both.
Do not make everything agentic
A workflow becomes agentic when the model observes state, chooses an action, sees the result, and decides what to do next. That flexibility is useful for triage, research, code review, support, and messy operational work.
It is wasteful when the process is already known. If step two always follows step one, a model does not need to decide it. Deterministic software will be cheaper, faster, and easier to test.
The easiest mistake is asking the model to enforce rules the application already knows. It should not decide whether an invoice over a fixed threshold needs approval if that threshold is a policy. It should not decide whether a user has access if the application already has permissions. Let the agent handle interpretation and prioritization. Let code handle invariants.
Use agents for ambiguity
Good agentic work has ambiguity at the center. Which issue matters? Which query answers the question? Which source is credible? Which tool should run next? These are judgment calls where a model can add value.
Bad agentic work asks the model to enforce fixed policy. Business rules, permissions, idempotency, and irreversible writes should live in code.
This split is not just about reliability. It also makes the user experience better. A user should feel that the agent is making thoughtful choices where humans normally spend time, not that it is randomly deciding things software should know already.
Hybrid workflows are the default
The practical pattern is a hybrid: a deterministic trigger starts the run, the model makes a bounded decision, tools execute narrow actions, and the workflow records state. Human approval appears only where risk justifies it.
Eve fits this pattern because channels, schedules, tools, skills, and durable sessions can sit around model judgment instead of replacing application structure.
A scheduled digest is a good example. A cron-like schedule can start the run. The model can decide which changes matter. A Slack tool can post the final summary. Durable state can prevent duplicate delivery. Each layer does one job, and the agent is used where judgment actually matters.
Design for the second run
The first run is usually easy. The second run reveals whether the workflow is real. What if the same event arrives twice? What if the user rejects the draft? What if the tool succeeds but the response stream fails? What if the model has no useful action to take?
A strong agentic workflow has answers to those questions. It can no-op, ask for clarification, retry safely, or stop with a useful explanation. If every failure path becomes "ask the model again", the workflow is not designed yet.
Decision table
Deterministic workflow
Use when
The steps and branches are known before the run starts.
Avoid when
The workflow depends on interpreting messy context or choosing among uncertain actions.
Agentic workflow
Use when
The model must choose the next action based on observations.
Avoid when
The model is being asked to enforce rules that code can enforce exactly.
Hybrid workflow
Use when
You need model judgment inside clear runtime boundaries.
Avoid when
The boundaries are so vague that no one can explain who controls the next step.
FAQ
Are agentic workflows the same as automations?
No. Automations follow predefined steps. Agentic workflows let the model choose some steps based on context.
Where do tools fit?
Tools are the bounded actions an agentic workflow can request. They should stay narrow and observable.
What is the first thing to test?
Test the failure path: bad input, missing context, duplicate trigger, and rejected approval.