Agents vs workflows: choosing the right amount of autonomy

Identify who chooses the next step

An AI project can begin with a small question: which decisions should the system make for itself? Before choosing a framework, write down the job, the available information, and the result someone will inspect. That makes the choice between a workflow and an agent easier to discuss and easier to test.

Anthropic draws a useful distinction: workflows follow paths defined in code, while agents let a model direct the process and use of tools. It also recommends starting with simple approaches and adding complexity when it improves results. Those definitions describe control, rather than whether a product has a conversational interface.

A workflow can still contain uncertain model outputs. For example, code can always send a draft through translation and review, even though the wording changes each time. An agent might decide that it needs another source, a different search, or a second attempt before producing a result. Name the decision you need before treating autonomy as a requirement.

Map one representative task

For a first design exercise, choose a real task you expect to repeat. Suppose you want a weekly brief from a fixed set of approved documents. Draw the steps: collect the documents, extract changes, prepare a draft, and submit it for review. Beside each step, mark what can be checked automatically and what needs judgment.

Then write down the awkward cases. What happens when a document is missing? When two sources disagree? When a claim lacks support? If your response to each case is already clear, you have a strong candidate for a workflow. If the next useful action genuinely depends on what the system discovers, a bounded agent may deserve a comparison.

Keep a list of decisions outside the task. Publishing, changing permissions, or contacting someone should appear explicitly, even when the system never needs those capabilities.

Compare a small baseline

Build the most direct version you can evaluate: one model call, retrieval followed by a response, or a short sequence of calls. Give it the same examples you would use to test a more autonomous design. Compare the finished work, the time it takes, the number of corrections, and the resources consumed.

Our suggested decision rule is straightforward: add autonomy to solve an observed limitation. If the baseline regularly misses relevant documents because the needed search varies, test a controlled search loop. If the output simply needs a consistent format, improve the template and validation first.

OpenAI’s Agents SDK documentation describes both model-directed and code-directed orchestration and says they can be combined. A mixed design can reserve flexible searching for one stage while keeping later actions explicit.

Define the boundaries before expanding

For a pilot, specify allowed tools, writable locations, spending limits, and stopping conditions. Write a concrete completion check: the brief contains supported changes from the approved documents and has been saved to the review folder. Also describe a useful incomplete result, such as a draft accompanied by a list of missing sources.

Review failures by the decision that caused them. Did the system choose an unsuitable search, misread evidence, or continue after it had enough information? Change that boundary and rerun the same tasks. An architecture becomes easier to defend when you can point to a specific decision it handles better, rather than a longer list of capabilities.