# Agentic workflows: when software should decide the next step

How to decide when a workflow should be agentic, deterministic, or a hybrid of both.

An agentic workflow is useful when the next step depends on judgment. If the path is fixed, ordinary workflow code is clearer. The best production systems usually mix both: deterministic rails around model decisions, with tools and approvals controlling the moments where the agent can affect the outside world.

## 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

| Choice | Use when | Avoid when |
| --- | --- | --- |
| Deterministic workflow | The steps and branches are known before the run starts. | The workflow depends on interpreting messy context or choosing among uncertain actions. |
| Agentic workflow | The model must choose the next action based on observations. | The model is being asked to enforce rules that code can enforce exactly. |
| Hybrid workflow | You need model judgment inside clear runtime boundaries. | The boundaries are so vague that no one can explain who controls the next step. |

## Examples

### Good fit

A Linear triage agent reads new issues, decides which ones need clarification, and drafts updates while code enforces allowed project fields.

### Poor fit

A billing workflow asks a model whether a fixed refund threshold applies. That should be a rule, not a judgment call.

## 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.

---

- Published: 2026-07-01
- Updated: 2026-07-01
- Web page: https://www.evex.sh/learn/agentic-workflows
- This document: https://www.evex.sh/learn/agentic-workflows.md
- All guides: https://www.evex.sh/learn
