When to Use a Workflow vs. an Agent

Use a workflow when your code can name the sequence of steps before anything runs, and an agent when only the model can name it after seeing the situation.

Both designs call language models, so the presence of an LLM tells you nothing about which one you have. The question is who holds authority over the next action.

That answer sets your testing model, your operating cost, your failure modes, and your approval process. Getting it wrong in either direction is expensive.

A workflow forced onto genuinely open-ended work becomes a decision tree nobody can test. An agent handed a settled process adds latency and non-determinism to something that used to be a switch statement.

In this guide you will learn:

• Where the boundary between a predefined path and a runtime decision actually sits
• Why an LLM call inside a fixed process is still a workflow
• Which signals in your inputs and exceptions push you toward each design
• How risk, latency, cost, and explainability change the answer
• How production systems put a bounded agent inside a deterministic workflow
• What to add, in order, when moving a prototype into production

Key insights

• A workflow is the default whenever your code can name the sequence of steps before execution.
• An LLM call adds language flexibility to a process without moving authority over the next step to the model.
• Agents earn their place when planning, tool selection, or exception handling cannot be settled in advance.
• Most production designs put a bounded agent inside a workflow that owns state, permissions, and approvals.
• Autonomy should expand only after you can trace decisions, cap spending, and measure failures.

What are AI agents vs workflows?

Both designs execute steps and both can call a model. What separates them is where the execution graph comes from.

In a workflow, that graph exists in your codebase before the first request arrives. You can draw it, review it in a pull request, and point at the branch that ran.

In an agent, part of the graph gets produced during execution. That single property is what forces the extra engineering: tools, data access, retries, and permissions all need boundaries the workflow got for free from its own structure.

The difference between predefined paths and dynamic decision-making

A workflow can represent a support process as a fixed sequence:

1. Receive the request.
2. Classify it.
3. Retrieve the account record.
4. Apply a routing rule.
5. Ask for approval above a threshold.
6. Send the response.

Every branch is testable against known inputs. When an execution fails, the trace points at one condition, one integration, or one defect.

An agent starts from an objective instead. It might read the request, decide which records are relevant, ask a clarifying question, then pick its next tool based on what the last one returned.

The sequence changes between runs. That flexibility is the point, and it is also why you end up evaluating decisions rather than only outputs.

Why an LLM step is not automatically an agent

Plenty of systems call a model inside a fixed process. The model extracts fields, classifies text, drafts a message, or picks one of several known branches.

All of that is still a workflow. The model returned an answer, and your code decided what to do with it.

Authority moves when the model's output becomes the action rather than an input to your routing logic. Signs that you have crossed the line:

• It picks which tool to call at runtime, from a set you allowed but did not order.
• Plans get created and revised mid-execution.
• Completion becomes the model's judgment instead of a terminal state in your graph.
• Tool errors and empty results change what happens next.
• Repeat attempts run against a budget rather than a fixed retry count.

Treating every model call as an agent buys you weaker tests and harder operations for no return. Ask whether the model produces an output your code acts on, or acts directly.

When should you use a workflow?

Workflows fit processes whose shape is already settled, where a mistake has a clear owner, and where behavior must not drift between releases.

You can still use a model for the language-heavy parts. The surrounding execution stays explicit.

Stable paths, structured inputs, and repeatable outcomes

Structured inputs are the strongest signal: form submissions, database events, API payloads, scheduled jobs. Anything that arrives with a shape you can validate at the boundary.

Repeatable outcomes are the second signal. Generating a document from known fields, synchronizing records between systems, validating a request, routing a ticket, running a nightly transformation.

Invoice processing is the clean case. Extract the fields, validate the totals, compare against the purchase order, route the exceptions to the people who handle them.

A model can normalize supplier language or interpret an ambiguous line item inside that process. It does not get to decide whether the invoice gets paid.

Stable paths also make ownership legible. Engineering reviews the process as code while operations inspects state and transitions in the same run history.

Auditability, retries, and predictable cost

A workflow hands you an execution record that answers questions directly: which branch ran, which service failed, which input triggered a hold, where the process stopped.

That matters once the process touches money, customer records, regulated data, or production infrastructure. You retry the failed integration on its own instead of asking a model to reconstruct the whole task from scratch.

Cost is predictable for the same reason. You know which steps execute and how often, so timeouts, retry caps, and cached lookups become ordinary engineering rather than guesswork.

Approvals belong to this layer too, and they get their own section further down.

When should you use an agent?

The case for an agent is rarely that the task sounds intelligent. It is that enumerating the paths has stopped paying.

Once the number of possible sequences keeps growing, a workflow turns into a decision tree that imitates judgment and resists testing. An agent collapses that tree by deciding at runtime, and moves your work to defining boundaries and evaluating behavior.

None of that means unrestricted access. A useful agent has a narrow mission, a small toolset, and explicit stopping conditions.

Ambiguous goals and unstructured inputs

Agents fit work like this:

• Investigate why a deployment is failing.
• Compare vendors against a set of business requirements.
• Research a product issue across internal documentation.
• Review a code change and identify likely regression paths.

Take the deployment case. The first useful action depends on the symptom, so the agent reads the build log, finds a permission error, checks whether the service account changed recently, then discovers the change came from an unrelated infrastructure pull request.

No fixed sequence would have found that, because the third step only exists once the second one returns. Each of these requests carries a clear goal and an open method.

The support example from earlier shows where the line falls. Routing a request by category is a workflow.

Resolving a case that might involve billing, entitlements, and a third-party provider is not, because you cannot know which systems matter until you have read it.

Dynamic planning, tool selection, and exception handling

An agent earns its autonomy by choosing the next tool from the last tool's result, which is a different thing from calling several tools in a fixed order.

That only works when each tool has a narrow contract. Return structured results, expose clear error states, and document side effects for anything that writes.

Designing those contracts is its own problem, and multi-step API workflows for agents covers it at the integration layer.

Exception handling needs the same discipline. Retrying a transient request, switching sources, asking for clarification, and escalating to a person should all be options your system defined in advance.

How do you choose between an AI agent and a workflow?

Start with the process, not the model. Write down the outcome you want, the inputs you have, the actions available, the failure states, and the decisions that require authority.

Then find where the uncertainty actually lives. Uncertainty about language means keep the path deterministic and let a model read the text.

Uncertainty about the next action is the only kind that argues for an agent.

Path stability and evaluation criteria

Score the step, not the system. Most real products contain steps that land on opposite sides of this table, which is exactly why the combined pattern in the next section is so common.

A step whose answers sit mostly in the left column does not get better by having autonomy added to it.

Risk, latency, cost, and explainability

Autonomy has an operating price. Model calls add latency, tool loops multiply spend, and non-deterministic decisions are harder to reproduce when something goes wrong.

Reproduction is the part teams underestimate. A workflow failure replays from its inputs, while an agent failure needs the full trajectory captured at the time, because running the same prompt again may not produce the same path.

Permissions should follow the impact of the action, never the model's confidence. Reading documentation needs far less control than changing infrastructure, issuing a refund, or updating a customer record.

Explainability works in layers. A workflow shows the branch and the condition that selected it.

An agent has to show its objective, the tools it chose, the inputs and outputs of each call, and why it stopped.

Two variables decide the implementation: whether the action is reversible, and whether the path is known ahead of time.

• Reversible action, known path: use a workflow.
• Reversible action, discovered path: use a bounded agent.
• Material action, known path: use a workflow with an approval step.
• Material action, discovered path: let an agent produce the proposal, and let the workflow execute it after approval.

When a wrong action costs more than a slow one, cut autonomy before you cut latency.

Where should you combine workflows and agents?

Most production systems that work look like a deterministic outer process with an agent inside one contained part of it.

The workflow owns state, permissions, retries, deadlines, and approvals. The agent handles interpretation, planning, or investigation within those limits.

Deterministic outer controls with bounded agent steps

The pattern runs like this:

1. A workflow receives an event and opens an execution record.
2. It hands the agent a narrow objective and the relevant context.
3. The agent works against approved read-only tools.
4. The workflow validates the result against a schema and rejects malformed output before it reaches anything downstream.
5. The result routes to a person or to a predefined action.
6. The workflow records the decision and closes the execution.

Step four does more work than it looks like. Schema validation catches the agent that returns a confident, well-written answer in the wrong shape, which is the failure that quietly corrupts downstream systems.

The agent never owns the process, only the part where fixed branches would have become unmanageable.

This also gives you a migration path that does not require faith. Keep the deterministic process, replace one difficult branch with an agent, and compare the two behaviors on the same inputs before you delete the old path.

Human approval for high-risk actions

A person should approve anything with material financial, legal, security, or customer consequences.

The agent gathers evidence and prepares a proposal. The workflow holds execution until the approval arrives.

A generated summary is not an approval screen. Show the requested action, the source data behind it, the tool calls that produced it, the proposed change, and whatever the agent could not determine.

Keep the action reversible where the process allows it. A draft beats an automatic send, and the same logic applies to a proposed database write or a staged deployment.

Approvals should also expire. If the underlying data has moved since the proposal, make the agent regenerate it rather than executing a decision that was true an hour ago.

How do you move from prototype to production?

A prototype shows the model can finish the task. Production asks three harder questions: can it finish inside defined limits, are its failures recoverable, and can your team operate it on a normal Tuesday.

Shipping a production estimation agent put all three in front of us before the first real run.

Move in increments. Each increase in autonomy should follow a measurable improvement in evaluation, tracing, or control.

Start with a single call and add autonomy gradually

Begin with one model call doing one narrow operation: extracting fields, classifying a request, summarizing evidence, proposing a next step.

Then add complexity in this order:

1. Define an output schema and reject invalid responses.
2. Add evaluation cases, including the inputs you expect to be hard.
3. Introduce one read-only tool with a narrow contract.
4. Capture the model input, the model output, the tool call, and the result.
5. Add a second tool once the first path is understood.
6. Permit planning and retries after you can inspect failure patterns.
7. Add write actions behind an approval or a deterministic policy.

Ordering it this way separates model quality from orchestration defects, so a failure points at interpretation, tool design, state handling, or permissions rather than at all four at once.

Set budgets, permissions, observability, and escalation paths

Write the boundaries down before autonomy expands. Define:

• Maximum execution time
• Maximum model and tool calls
• Allowed tools and data sources
• Read and write permissions
• Retry rules per dependency
• Conditions that require human review
• Fallback behavior when the agent cannot proceed
• Log and trace retention for diagnosis

Budgets protect cost and system stability at the same time, while permissions limit the damage a wrong decision can do. Observability is what lets you inspect the whole trajectory instead of inferring it from the final answer.

Escalation is part of the design, not a patch you add after the first incident. Give the agent a defined route to report missing information, conflicting evidence, an unavailable tool, or an objective it cannot complete safely.

A production agent should know how to stop.

Where to start with workflows and agents

Workflows remain the default for settled processes, structured inputs, and outcomes that have to repeat. Agents earn their place where the goal is clear but the path depends on what execution reveals.

In most serious systems the answer is not one or the other. It is a bounded agent doing the interpretive work inside a workflow that still owns state, permissions, and the decision to act.

If you want help drawing that boundary in your own system, including tool access, approval gates, and the operating model around a running agent, talk to us about AI Agents Development.

FAQ on when to use a workflow vs agent

Four questions that come up after the architecture decision is made, when someone has to run the thing.

Are agents suitable for customer-facing automation?

Yes, once the tools, scope, and escalation paths are tightly bounded. Keep sensitive actions behind approval or a deterministic policy, and give the agent an obvious route to hand the conversation to a person.

Does an agent cost more to run than a workflow?

Usually, and the variance matters more than the average. A workflow executes a known number of steps, while an agent decides how many calls it needs, which is why iteration caps carry real weight.

Who owns an agent after it ships?

Whoever owns the process the agent runs should also own its evaluation suite. Traces without an owner turn into storage, and an eval suite nobody updates stops describing production within a release or two.

Should the agent and the surrounding workflow use the same model?

There is no reason they have to. Classification steps usually run fine on a smaller model, while planning and tool selection are where a stronger one pays for itself.

Sources

• Building effective agents – Anthropic, December 19, 2024.
• A practical guide to building agents – OpenAI.
• Process to build agents across your organization – Microsoft Learn, published December 1, 2025, updated June 26, 2026.