Start with workflows, not agents

Most AI roadmaps I review skip a step. They go straight from "we should use AI here" to "we should deploy an agent," as if agent were a feature you toggle on. It is not a feature. It is a decision about who controls the sequence of work: your code, or the model.

That decision deserves more care than it usually gets, because it determines how the system fails, how you test it, and who gets paged when it misbehaves.

Two kinds of system

Anthropic's Building effective agents draws the line clearly. In a workflow, models and tools are orchestrated through predefined code paths. In an agent, the model directs its own process and decides which tools to use and when it is done. The blog post does not argue against agents. It argues for the simplest design that works, and for adding autonomy only when it demonstrably improves results.

It also names the workflow patterns that cover a surprising share of real use cases:

• Prompt chaining: break a task into fixed steps, each model call consuming the previous output, with programmatic checks in between.
• Routing: classify an input and send it to a specialized path, prompt, or model.
• Parallelization: run independent subtasks at once, or run the same task several times and vote.
• Orchestrator-workers: a central model breaks down a task and delegates the pieces.
• Evaluator-optimizer: one call generates, another critiques against explicit criteria, and the loop repeats.

Each of these lets the model do real cognitive work while your code keeps ownership of order, retries, and stopping.

What the field data says

The early production evidence leans the same way. Measuring Agents in Production, a study led by UC Berkeley researchers covering 86 deployed systems, found that 80% of its detailed case studies used structured control flow, and that reliability was the challenge teams raised most. Sixty-eight percent of the production agents it examined execute ten or fewer steps before a human gets involved.

LangChain's State of Agent Engineering survey (1,340 respondents, November–December 2025) found quality to be the most common barrier to getting agents into production, named by about a third of respondents. Teams are not short on ambition. They are short on systems that behave the same way twice.

Neither source says autonomy is bad. Both suggest that the teams succeeding today put a lot of structure around a little autonomy.

A worked example: support triage

Picture a hypothetical support queue that receives a few hundred tickets a day. The tempting design is a single agent with access to the ticket system, the knowledge base, and email, told to "resolve tickets."

A workflow version looks like this:

1. Classify the ticket into one of eight categories with a small, fast model call. Code rejects any label outside the list.
2. Route billing, outage, and account-security tickets to separate paths with their own instructions.
3. Retrieve the two or three policy passages relevant to that category.
4. Draft a reply grounded in those passages, with citations.
5. Check the draft programmatically: are citations present, is a refund amount mentioned, does it promise anything the policy forbids?
6. Queue the draft for a person to approve, edit, or reject.
7. Send only after approval, and log the outcome.

Every step uses a model where judgment helps. None of them lets the model decide what happens next. When something goes wrong you can point at the step, inspect its input and output, and add a test for it.

Now ask where autonomy would actually help. Perhaps the outage path needs to check a status page, query recent deploys, and see whether the customer sits in an affected region before drafting. The number of lookups varies by ticket, and the order depends on what the first lookup returns. That one branch is a reasonable candidate for a bounded agent loop. The other seven categories are not.

A ladder, not a leap

Rather than "workflow or agent," think of autonomy as a ladder you climb one rung at a time:

Most valuable systems live on rungs two through four. Moving up a rung should be a deliberate decision, backed by evidence that the lower rung is failing on cases that matter.

Three answers that decide the rung

Before calling something an agent, write down answers to three questions:

• What is the irreversible action? Sending an email, issuing a refund, merging code, deleting a record. Whatever it is, the design must say what happens before it occurs.
• What is the maximum useful number of steps? If you cannot name a number, you cannot test for runaway behavior.
• What happens when a tool errors or retrieval comes back empty? A system that fails closed declines and asks. A system that fails open improvises.

If those answers are fuzzy, what you have is a prompt and an aspiration, not a design.

When the loop earns its place

Open the loop when branching is genuinely unpredictable and you already have the controls that make autonomy safe: a step cap, an allowlist of tools, approval on writes, golden test cases that run before every change, and a named person who owns the system. Start with the workflow, measure where it breaks, and promote only that piece. Autonomy you added because the evidence asked for it is far easier to defend than autonomy you started with.

Sources cited

• Anthropic, Building effective agents (published December 19, 2024)
• Pan et al., Measuring Agents in Production (arXiv 2512.04123, submitted December 2025)
• LangChain, State of Agent Engineering (survey of 1,340 respondents, November 18–December 2, 2025; report published February 2026)