Workflows Before Agents

Use the simplest LLM design that works; add agent autonomy only when a problem truly needs it.

“…we recommend finding the simplest solution possible, and only increasing complexity when needed.”
— Anthropic, “Building effective agents” (2024)

Start with one call, and move to a workflow or an agent only when the simpler design measurably falls short.

To an executive

Autonomous AI costs more, is harder to test and can compound its own mistakes. Starting with simple, predictable designs delivers reliable results sooner and shows what extra complexity is worth.

To an engineer

Start with one well-tuned model call, then fixed workflows you can test step by step. Add agents only for open-ended problems where steps cannot be predicted, and measure the gain.

The idea

In a widely read 2024 engineering post, Anthropic distinguished two kinds of LLM system. Workflows run models and tools through paths defined in code: chain one call into the next, route inputs to specialists, run calls in parallel, have one model orchestrate others, or have one model evaluate another's output. Agents let the model decide its own steps and tool use as it goes.

Their advice was to start with the simplest thing — often a single well-optimised model call — and add complexity only when it measurably improves results. Agents suit open-ended problems where the number of steps cannot be predicted, but they cost more, are harder to test and can compound their own errors.

Why it works

Predictable paths are testable. A workflow can be evaluated step by step; an agent's path changes every run.

Errors compound. Each autonomous decision is another chance to go wrong, and later steps build on earlier mistakes.

Simple designs show what really helps. Starting small reveals which extra complexity actually improves results.

Where it applies

Designing any LLM feature, from summarisation to customer support.
Reviewing proposals for "an agent" that may really be a three-step workflow.
Choosing frameworks. Abstractions can hide prompts and make problems harder to debug.

How to apply

Start with one call. Add good instructions, examples and retrieval, and measure it on an evaluation set.
Add structure only for a reason. Chain, route or parallelise when one call cannot do the job well.
Use an agent for open-ended work where steps truly cannot be known in advance.
Fence agents in. Give them few, well-described tools, clear stopping conditions, sandboxes and human checkpoints for risky actions.

Example scenario

A team proposed an autonomous agent to answer customer questions about orders, with access to a dozen tools. A design review asked for a baseline first. A fixed workflow — classify the question, fetch the order, answer with a template — handled most questions correctly.

They kept that workflow and added a narrow agent only for the remaining multi-step cases, with read-only tools and handover to a person.

Questions to ask

Could a single, well-crafted model call solve this before we build anything bigger?
Are the steps predictable enough to write as a fixed workflow?
If we use an agent, what stops it, how do we test it, and what can it break?

When not to use it

Truly open-ended tasks, such as investigating an unfamiliar codebase, where a fixed path would be too rigid.
When a workflow keeps growing branches to handle every case; that is a sign the problem needs a model to plan.

How it misleads you

Simplicity can become an excuse to under-invest. A single call with a weak prompt and no evaluation is not a baseline. The point is to measure, then add only the complexity that pays for itself.