AI agents vs. workflows: choosing the right control model

The decision is who chooses the next step

In a workflow, application code defines the permitted sequence and branches. A model can still classify a document, extract fields or draft a response inside that sequence. In an agent loop, the model selects intermediate steps or tools in response to what it finds. Using an LLM does not, by itself, make the surrounding process an agent. This distinction is also used in Anthropic’s discussion of workflows and agents.[1]

Start by drawing the current process without model names. Mark the steps with incomplete information, changing paths or ambiguous evidence. If every exception can be expressed as a small, maintainable branch, an agent may add little. If a useful answer requires searching different sources and choosing the next investigation, the uncertain portion deserves an experiment.

Compare control, not marketing labels

These are not exclusive product categories. A workflow can route a hard case to an agent and then resume with a typed result. A model-directed investigation can call a deterministic tool. The boundary matters because it tells the engineering team what can be replayed, where policy is enforced and who handles a case that cannot be completed.

Worked scenario: an invoice exception

Consider a synthetic accounts-payable workflow. Most invoices match a purchase order and a receipt. A smaller set has discrepancies in quantities, delivery dates or supplier descriptions. The task is to assemble a defensible exception recommendation; payment authorization remains a separate business decision.

1. Validate the invoice schema, supplier identity and duplicate-invoice key in ordinary application code.
2. Attempt deterministic matching against purchase orders and receipts.
3. For an unresolved exception, let an agent inspect a small set of authorized records and return a proposed explanation with source identifiers.
4. Validate that the cited records exist, belong to the correct account and support the claimed discrepancy.
5. Route the resulting proposal through the established approval process. A model-generated recommendation does not release payment.

The agent earns its place only in the investigation. If it cannot resolve the discrepancy within its task budget, it returns an explicit unresolved state and the collected evidence. It should not invent a new supplier, modify the purchase order or retry payment as a way to complete the task.

Run a comparison that can disprove the idea

Build a held-out set from the same kinds of exceptions the product will face, using material the team is permitted to evaluate. Include straightforward mismatches, genuinely ambiguous cases, missing records and adversarial document text. Compare a rules-based baseline, a fixed model workflow and the bounded agent on the same task definition.

Do not select the agent because its best demonstration looks more capable. Select it if the distribution of outcomes improves enough to justify the new moving parts. Preserve failed examples in the evaluation set so a prompt revision cannot silently reintroduce them.

Write the handoff between workflow and agent

A useful contract specifies the objective, trusted caller context, accessible records, allowed tools, resource budget and allowed terminal states. The response should identify the proposed result, evidence and unresolved conditions. It should not depend on reading hidden model reasoning to establish whether the task succeeded.

Keep the commit step outside open-ended investigation. If the task involves a write, the application checks current permissions, validates the final payload and records the outcome. Microsoft’s orchestration guidance describes several patterns; the engineering choice is which pattern gives this task a clear owner and an understandable failure path.[2]

When to keep the simpler system

Keep the workflow when the agent mostly repeats a known sequence, when the task cannot tolerate variable latency, or when review costs erase the improvement. Add an agent only to the step that benefits from it. Revisit the choice as real exceptions accumulate: a once-variable task may become a predictable workflow after the team learns its structure.

The useful deliverable is a decision record: the task boundary, baseline, measured differences, limits and reason for selecting a control model. That record is more durable than a framework choice and gives a future engineering team something concrete to challenge.