Every vendor deck now promises "agents." Before your team commits to building one, it is worth pinning down what the word means, because the alternative — a plain workflow — is cheaper, more predictable, and the right answer for most business problems. The good news is that this is not a philosophical debate. It is an architecture choice with a clear test.
The distinction in one paragraph
In a workflow, your code defines the steps and their order; Claude performs individual steps within them. Receive invoice, extract fields, validate against the PO, draft an approval email, route to a human — the sequence is fixed, and the model is called at the two steps that need language understanding. In an agent, you give Claude a goal and a set of tools, and the model decides which tools to call, in what order, and when it is done. The loop runs until the model declares the goal met. Autonomy is the whole difference: workflows put the model inside your control flow; agents put your control flow inside the model.
Why workflows win most of the time
Enterprise processes are mostly known in advance. Invoice handling, ticket triage, report drafting, translation review — you can write the steps on a whiteboard, which means you can encode them in code. When you do, you get properties businesses care about: every run takes the same path, so you can test it; cost per run is bounded, because the number of model calls is fixed; failures are localized to a step you can name; and auditors can be shown a flowchart that is actually true.
Agents give up those properties in exchange for flexibility. An agent may take three tool calls or thirty to finish, so latency and cost vary per run. Two identical requests can take different paths. Testing shifts from "does each step work" to evaluating open-ended behavior. None of this is fatal — it is the right trade for genuinely open-ended tasks, such as investigating why a shipment is stuck across five systems, or research questions where the next step depends on what the last one found. But it is a cost you should pay only when the task truly cannot be scripted.
A worked example
Consider supplier-invoice processing. Version one is a workflow: Claude extracts fields from the PDF (a vision plus structured-output call), code matches them against the purchase order, mismatches go to a human queue, matches generate a posting file. Two model calls, fixed cost, fully testable. Now consider the exceptions queue: an invoice references a PO from a different subsidiary, the vendor name almost matches an existing record, prices moved mid-contract. Resolving one exception means querying several systems in an order that depends on what each query reveals. That bounded investigation is a reasonable agent: give Claude read-only lookup tools and require that its output be a recommendation a clerk approves. The routine 95% stays a workflow; autonomy is spent only where variance lives.
Practical guidance for choosing
Start as a workflow, promote later. A workflow teaches you where the model is reliable. If humans keep overriding one scripted branch because reality is messier than the flowchart, that branch is a candidate for agent-style handling.
Bound any agent you do build. Cap the number of tool calls, restrict tools to least privilege (read-only wherever possible), and define what happens when the cap is hit — escalate to a person, don't loop forever. Both patterns are built from the same primitives — tool use works on all four platforms (Bedrock, Vertex AI, Foundry, and Claude Platform on AWS) — so nothing about your platform choice forces either design. One availability note: Anthropic's Managed Agents offering exists only on the first-party API and Claude Platform on AWS, so on Bedrock, Vertex AI, or Foundry you would run the agent loop in your own code.
Judge by the outcome metric, not the demo. Agents demo brilliantly. Workflows ship. Measure resolution rate, error rate, and cost per case, and let those numbers decide how much autonomy the process earns.
Where to go next
Both designs rest on tool use, so start there if the request/execute loop is new to you. Human-in-the-loop design covers the review gates that make either pattern safe to deploy, and the feature matrix shows what each platform supports.