AI agents vs workflows: choose the right kind of control.

A workflow is an execution plan. The application knows the sequence or the permitted transitions and moves the work through them. An AI agent is a decision-making system inside a workflow: it interprets the goal and current state, chooses among tools or actions, observes results, and continues, stops, or hands off. The difference is who decides what happens next.

OpenAI's agent guide makes a similar distinction between conventional software and agents. Agents are useful when workflows include complex decisions, difficult-to-maintain rules, or heavy reliance on unstructured data. That is a narrower and more useful test than asking whether an agent can perform the task. Many tasks can be performed by an agent; fewer need one.

A fixed workflow is not primitive. It is often the responsible design for payroll, compliance checks, financial calculations, permissions, and any process where the acceptable sequence is known. An agent is not automatically advanced. Unbounded tool choice can make a system harder to debug, more expensive to run, and more difficult to explain to the person affected by its decision.

The practical answer is frequently hybrid. Keep the boundaries deterministic and let a model handle the parts where language and judgment add value. For example, the model can classify an email or summarize evidence while code controls identity, calculations, data access, approval, and the final state change.

Workflows are strong when you can draw the process before building it. A trigger creates a record, a validation step checks required fields, a lookup retrieves data, a calculation applies a rule, an approval is requested, and a notification is sent. The same path can run thousands of times with predictable cost and timing.

Use a workflow for actions that must be explainable as a sequence. A reviewer can ask which rule failed, which approval was missing, or which field caused the process to stop. Developers can write deterministic tests for each branch. Operators can replay a run from a known state instead of reconstructing a model's choices.

A workflow can still use a language model. The model might extract a purchase order number from a PDF, classify an issue, summarize a verified dataset, or propose a response. The surrounding workflow should validate the result and decide whether it is allowed to continue. Treat the model output as an input with uncertainty, not as a trusted command.

The weakness appears when the workflow is held together by hundreds of brittle rules. If every new exception requires another branch and the input arrives in many unstructured forms, maintenance cost may exceed the value of determinism. That is a signal to test an agent or a narrower language-model step, not a reason to replace the entire process at once.

Agents earn their complexity when the task starts with a goal rather than a known sequence. A research agent may need to decide which approved sources to consult, whether the evidence is sufficient, and how to reconcile conflicting documents. A support agent may need to ask a clarifying question, retrieve an account record, inspect policy, and decide whether to draft, escalate, or offer a safe next step.

The agent's flexibility should be bounded by a tool and permission design. OpenAI identifies model, tools, and instructions as core components. The model manages decisions; tools expose data or actions; instructions define the job and guardrails. In production, authentication, authorization, validation, budgets, monitoring, and human intervention must sit around these components.

An agent is a good fit when rules are hard to maintain but the outcome can still be observed. 'Investigate this vendor against our checklist and produce evidence for a reviewer' is more suitable than 'make any procurement decision you think is best.' Keep the final decision with the right human or deterministic system when the consequence is high.

Agents need a stopping condition. They should stop when the outcome is complete, when a tool fails beyond the retry limit, when the evidence is insufficient, when the action exceeds a permission, or when a human must decide. A model that keeps trying is not necessarily making progress.

A hybrid system lets each component do the job it is best suited for. Code owns state transitions, identity, access, arithmetic, transactions, rate limits, and irreversible actions. The model handles language interpretation, document understanding, draft generation, or bounded selection among read tools. A reviewer resolves ambiguity and high-impact exceptions.

Consider customer support. The model can understand a message, classify the issue, retrieve an approved policy, and draft a response. A deterministic service verifies the customer, checks the account, calculates an eligible credit, and records an approval. The send action is a separate permission. This division is more robust than asking one prompt to perform the entire workflow.

A hybrid design also gives you a gradual autonomy ladder. Begin with suggestions only. Then allow the agent to perform read-only retrieval. Add low-risk writes after evaluation. Keep sensitive or irreversible actions behind approval. Expand one boundary at a time, with a new test set and an explicit owner.

Use the agent where it reduces friction, not where it makes the architecture harder to see. A small agent inside a clear workflow can create meaningful value. A workflow around an unconstrained agent can create the appearance of control without the actual ability to predict or stop behavior.

First, describe the desired end state and the cost of a wrong result. If the outcome cannot be observed, neither architecture can be evaluated well. If the cost is high, keep the final action deterministic or supervised while you learn.

Second, list the exceptions and input forms that defeat the current process. If there are few and stable exceptions, add workflow branches. If interpretation and route selection are the central difficulty, prototype a bounded agent. Do not confuse a large number of simple rules with a need for autonomy.

Third, list the tools and permissions. A workflow may need five fixed integrations. An agent may need to choose among them, but the list should still be narrow and well-described. If you cannot state what the agent is allowed to do, it is not ready to operate.

Fourth, define the evidence and human handoff. Decide what a reviewer will see, how a user can correct an error, how the system pauses, and which traces are retained. If the agent cannot explain its result with sources or observable actions, restrict it to drafting or research.

Finally, compare a baseline workflow, a bounded agent, and a hybrid if the decision is uncertain. Use the same representative cases and measure quality, correction, cost, latency, failure severity, and maintenance work. The most impressive demo is not the winner; the architecture that produces acceptable outcomes in the real operating environment is.

Invoice intake is usually hybrid. A parser or workflow handles file intake, storage, duplicate detection, and posting. A model extracts fields from varied layouts and flags unclear values. Code validates totals and vendor identity, and a human handles exceptions. An autonomous agent with write access would create unnecessary risk.

Refund approval needs supervision. A model can understand the request and retrieve the applicable policy, but account access, eligibility calculation, approval limits, and the transaction should be controlled. The more money or ambiguity involved, the more the final action belongs behind an approval gate.

Vendor research can justify a bounded agent. The agent may search a list of approved sources, collect citations, compare evidence against a checklist, and prepare a report. It should not silently approve a supplier, invent a risk score, or use private sources without authorization. The report is an input to procurement judgment.

A weekly metrics report is a workflow. Schedule the queries, validate the date range, calculate metrics in code, and store the result. Use a model to make a readable narrative only after the numbers are fixed. An agent deciding which data to use for an executive report without a controlled scope is a poor trade.

Customer troubleshooting can be agentic within boundaries. The conversation is ambiguous and the next question depends on the answer. Tools can retrieve account and product information, while code controls permissions, credits, dispatch, and account changes. A human handoff should be easy when symptoms are novel or the user is frustrated.

Run both candidates on the same task set. Include ordinary cases, ambiguous inputs, missing data, conflicting instructions, tool outages, adversarial content, and cases where the correct behavior is to ask or stop. A workflow may fail because a branch is missing; an agent may fail because it chooses the wrong tool or keeps acting after a failure.

Measure outcome success and trajectory. Check the final record, not just the response. Check tool calls, arguments, sources, permissions, retries, escalation, cost, and latency. An agent can produce the right answer through an unsafe path, and a workflow can produce a predictable answer that solves the wrong problem.

Use the [AI evaluation guide](/ai-evaluation) to separate capability tests from regression tests and to combine deterministic checks with model-based and human review. Use [AI governance](/ai-governance) to document ownership, risk, controls, monitoring, and the conditions for pausing or retiring the system.

Prefer the simplest architecture that meets the measured requirement. Complexity is justified by value and evidence, not by the number of agents, tools, or prompts in a diagram. Revisit the decision when the workflow, data, model, user group, or risk changes.