Workflow or AI agent? Choose the control loop before building

The practical difference is who chooses the next step. In a fixed workflow, the designer specifies the sequence and branches; a model may still classify, extract, draft, or judge inside a step. In an agent, the model uses observations to choose subsequent actions, often including tools, until a completion or stop condition is reached. More autonomy is useful only when the next useful action cannot be specified well enough in advance and the environment can return evidence that guides the choice.

This is an architecture decision for one task, not a label for an entire product. A customer-support system may use a fixed route for category assignment and a bounded investigation loop for unusual technical reports. Decide at the action level, then connect the pieces.

Start with a trace of real work

Choose five recent instances of the same task. Write the operator’s action sequence, the observation after each action, and the reason for any detour. Mark which branch a team could have written down before seeing the case. If most paths are known, build those paths explicitly. A model can handle variable language without controlling the whole process.

Ask four questions before adding a loop:

Question	Evidence favoring a fixed route	Evidence favoring a bounded agent
Can the next step be described ahead of time?	The same few decisions recur	The next step depends on new findings
Can the environment report progress?	Completion is checked once at the end	Tool results expose what remains unknown
What can an exploratory action change?	Actions are predictable and limited	Exploration is useful, but each action needs a permission limit
Can the run stop safely?	A failed branch goes to a named queue	There is a step or time budget, stop signal, saved trace, and owner

An agent without useful feedback can only keep guessing. A workflow with dozens of hidden exceptions may be pretending that its route is fixed. In either case, improve the task trace before choosing a framework.

Design the smallest control loop that fits

First define the outcome and its acceptance test. Next list the tools that may supply new observations. For each possible tool call, record whether it reads data, changes a draft, or changes external state. Add a maximum number of steps, a time or cost ceiling, and a condition that returns the case to a person. Save enough context for that person to continue.

For a fixed workflow, specify the branches and who maintains them. For an agent, specify the allowed search space: which tools, records, domains, and actions it may use. A person must authorize consequential actions such as sending messages, publishing changes, or moving money at the point where approval can still change the outcome. The agent may propose an action, but a tool permission must enforce the boundary.

This yields a useful middle ground: fixed orchestration around a narrow agent loop. The outer route can validate input, obtain approval, and record the result; the inner loop can investigate within a read-only scope. There is no need to grant the whole workflow a single autonomy level.

Example: invoice intake should use a fixed route

An operations team receives emailed invoices. The repeated steps are known: validate the sender, extract fields, match the purchase order, flag discrepancies, and ask a person to approve payment. Invoice formats vary, but the next action does not depend on an open-ended search. A model may extract line items and explain an exception. A fixed branch sends a mismatched amount to review; no model should invent a new payment route.

The team records ten historical invoices, including a duplicate, a missing order, and a currency mismatch. Acceptance means every required field has a source location, every exception is visible, and no payment occurs without approval. The workflow owns the sequence; the model owns one bounded interpretation step. If a new invoice format breaks extraction, the case exits to a reviewer rather than starting an uncontrolled tool loop.

Example: dependency investigation can justify a bounded agent

A software team investigates why a service deploy fails. The first observation may point to a configuration change, a missing dependency, or a failing upstream service. The next useful read depends on the previous tool result. A read-only agent can inspect allowed logs and configuration, compare a known-good deploy, and produce a diagnosis with cited evidence. The surrounding workflow still chooses the repository, masks secrets, imposes a six-call budget, and ends at a human review of the proposed fix.

The evaluation set includes a straightforward missing variable, a misleading error message, an unrelated secret in a log, and a case where the available evidence is insufficient. A pass requires a trace of inspected material, a supported hypothesis, and an explicit “unknown” when needed. Writing a production configuration is outside this loop. The team may later add a separate, approved change path after evidence from repeated runs supports it.

Turn the decision into a test

Run the same cases through the simplest viable design first. Record task completion, human corrections, tool calls, elapsed time, and serious failures. If a fixed route handles the cases and exceptions cleanly, more freedom has not earned its operating cost. If operators keep inventing legitimate branches and those branches can be guided by safe tool feedback, test a constrained agent against the same cases. The decision is reversible: move repeated successful agent paths into explicit steps, and reserve exploration for cases that genuinely need it. For a repeated path with a stable trigger and inputs, the skill decision card tests whether its instructions merit a reusable package.

Before release, have someone who did not design the flow explain the stop rule from its trace. They should be able to say what the system observed, why it took the next action, when it must hand off, and what an unauthorized tool call would be blocked from doing. If they cannot, the design is not yet reviewable.

Common questions

Is a model call inside a workflow already an agent?

No. Classification, extraction, and drafting can be model steps inside a predetermined route. The distinction is whether the model decides subsequent actions from observations.

Is a multi-step workflow automatically safer?

Only if its branches, permissions, and failure states are explicit. A hard-coded path can still expose data or execute an irreversible action without review.

When should a team increase autonomy?

When real cases show valuable unplanned branches, tool observations reliably guide the next step, and a bounded run beats the fixed alternative on acceptance and cost. Raise permissions separately from the choice of control loop.

Boundary

This canvas does not grant authority or prove that an agent is safe. Do not use it to approve actions involving regulated decisions, payments, production writes, or personal data without the responsible owners and concrete controls. If neither the output nor the stopping condition can be checked, return to task definition before choosing workflow or agent.