Agentic workflows vs autonomous agents: which should you build?

The difference: who chooses the next step#

In an agentic workflow, you decide the sequence of steps in advance. Some steps call a model, such as extracting fields or writing a draft, but the order is fixed in code or configuration. Step two always follows step one.

In an autonomous agent, the model runs in a loop: it looks at the goal and the state so far, picks a tool, observes the result and repeats until it decides it is done. The path is not known in advance and may differ every time.

Neither is better in general. A workflow trades flexibility for predictability. An agent trades predictability for the ability to handle situations you did not anticipate. Most real systems sit somewhere on the spectrum between them, and the skill is putting each task in the right place.

When a fixed chain beats an open loop#

If you can write down the steps on a whiteboard, build the workflow. It will usually be cheaper, faster and easier to debug. Signs a workflow is the right fit:

• The steps rarely change. Every Monday: pull open issues, group them, post a summary.
• The inputs are structured. A webhook delivers a known payload; you need to classify it and route it.
• Mistakes are expensive. Fewer decisions for the model means fewer chances for it to go off script.
• You need to explain what happened. A fixed sequence produces a clear trace: step three failed, here is why.
• Cost must be predictable. Each run makes a known number of model calls.

A useful habit is to start with a workflow, and only give the model more freedom at the specific steps where a fixed rule keeps failing. It is much easier to loosen a strict design than to tighten a loose one after an incident.

When you actually need an autonomous agent#

An open loop earns its cost when the work is exploratory. Debugging a failing build, researching a question across several sources, or untangling a messy inbox request can require different actions depending on each result. Writing a rule for every branch would be endless.

Choose an agent when:

• The number and order of steps depends on what is discovered.
• The task is requested ad hoc by a person, who can watch and steer.
• A wrong step is cheap to undo, or sits behind an approval.
• You are willing to accept variable cost and time.

Be honest about the price. Each loop iteration is another model call, and context grows as the transcript grows. Without limits, a confused agent can wander. If you choose an agent, bound it with caps on steps, tool calls, time and spend, and expect to invest in the harness around it.

Triggers: schedules, webhooks and people#

How a run starts shapes which design fits. There are three common triggers:

• Schedule. "Every weekday at 8:00" is a natural workflow. The same job, the same shape, no one watching, so predictability matters most.
• Webhook. An event arrives from another system, like a new support ticket or a merged pull request. Event-driven runs are usually triage, enrichment or routing, which are classic workflow jobs.
• A person asking. A live request in chat is the best fit for an agent, since the person can clarify and correct.

Unattended triggers deserve extra care. Nobody is there to notice a bad run, so you need logs, notifications on failure and a hard stop on writes that need a human decision. A webhook can also be called repeatedly or with unexpected payloads, so make handlers idempotent and validate input before any model sees it.

Hybrid designs: a fixed outer flow with a bounded agent inside#

The most practical systems combine both. The outer structure is a workflow, so triggers, ordering, approvals and budgets are explicit. One or two inner steps are small agents with a narrow job and strict limits.

{
  "trigger": { "type": "schedule", "cron": "0 8 * * 1-5" },
  "steps": [
    { "id": "fetch",  "tool": "issues.list", "args": { "state": "open" } },
    { "id": "triage", "llm": "Group by theme and flag urgent ones", "input": "fetch" },
    { "id": "post",   "tool": "chat.post_message", "risk": "write", "input": "triage" }
  ]
}

Here the fetch and post steps are deterministic, the triage step uses the model, and the write at the end is flagged so it can wait for approval. If triage needs more freedom, say to look up related documents, you can replace that one step with a capped agent loop, and the rest of the flow stays predictable.

This also tells you where to invest. Put your evaluation effort on the model steps, and your reliability effort on the plumbing between them.

Failure handling, approvals and cost control#

Whichever design you pick, build these in at the structural level:

• Failure handling. Decide per step what happens on error: retry with backoff, skip, or stop the run. Record which step failed and why. In a workflow this is a property of each step; in an agent, the harness must enforce it.
• Approvals. Mark risky steps so a person confirms them. In a workflow you can see exactly where approval sits. Make sure the run can pause, resume after approval and not repeat steps that already succeeded.
• Cost control. Count model calls per run, set a ceiling, and alert when a run approaches it. Use smaller models for simple steps such as classification, and reserve the capable one for hard steps. Cache results that do not change between runs.
• Observability. Log every step's input, output and duration in a form a non-engineer can follow.

The common theme is that safety belongs in structure you can inspect, not in an instruction the model may or may not follow.

A quick way to decide#

Ask five questions about the task:

1. Can I list the steps today? If yes, lean workflow.
2. Does it run unattended on a schedule or event? If yes, lean workflow.
3. Does the path depend on what it finds? If yes, consider an agent for that step.
4. What is the worst thing one wrong step could do? If it is serious, add an approval or remove the freedom.
5. Do I need predictable cost? If yes, bound the loops or avoid them.

Then start at the simplest design that could work and add autonomy only where evidence says you need it. Evidence means real runs that failed because the path was too rigid, not a hunch that agents are more impressive.

How Setu approaches this#

Setu supports both styles. Your agent can work interactively through a private MCP endpoint, and you can also build workflows that run on schedules or webhooks, or start from ready-made recipes. In workflows, writes still wait for approval, so an unattended run cannot quietly change things. Per-app rules (go ahead, ask, never) apply by risk level, and the activity log records what ran in plain language.

Workflows can use apps such as GitHub, Slack, Notion, Linear, Gmail, Google Calendar and Google Sheets. Browse the workflow templates, see common solutions or read the concepts to get started.

Frequently asked questions#