Start with a workflow, not an agent
Agents are the most exciting pattern in AI products, and often the wrong first one. Why we begin with the simplest system that could work, and when we graduate.
Almost every AI brief now mentions agents: software that plans its own steps, calls tools and works toward a goal with little supervision. Some products genuinely need that. Many would be faster, cheaper and more reliable as something simpler, and the people who build these systems at scale say so plainly.
In “Building effective agents,” Anthropic summarised what it learned from working with dozens of teams building agents: the most successful implementations were not using complex frameworks or specialised libraries. They were built from simple, composable patterns. Its advice is to find the simplest solution possible and add complexity only when it demonstrably helps, which “might mean not building agentic systems at all.”
Two different kinds of system
The same article draws a useful line. Workflows are “systems where LLMs and tools are orchestrated through predefined code paths.” Agents are “systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.” A workflow’s steps are decided by the product team. An agent’s steps are decided by the model, at run time.
That difference shapes everything a user experiences. Workflows are predictable: the same input takes the same path, takes roughly the same time and costs roughly the same. Agents trade some of that predictability, and usually some latency and cost, for flexibility on open-ended tasks.
Five workflows cover most products
- Prompt chaining: a fixed sequence of steps, each checked before the next. Draft, then check against a style guide, then format.
- Routing: classify the request, then send it down a specialised path. Billing questions and bug reports deserve different handling.
- Parallelisation: run independent parts at once, or run the same task several times and compare. Faster, and a cheap way to gain confidence.
- Orchestrator and workers: one model breaks a task into parts and delegates them, for work whose pieces cannot be known in advance.
- Evaluator and optimiser: one model drafts, another critiques against clear criteria, and the draft improves in a loop.
Most AI features startups ask for fit one of these, or two combined. They are easier to test, because each step can be evaluated on its own. They are easier to explain to users, because the product can show which step it is on. And they are easier to change when a better model arrives.
When an agent earns its place
Agents make sense for open-ended problems where, in Anthropic’s words, it is “difficult or impossible to predict the required number of steps.” Research across many sources, changes that span a whole codebase, or support cases that need investigation before an answer are good examples. Even then, an agent should work in a trusted environment, with clear stopping conditions, limits on what it can touch and a person approving anything that cannot be undone.
Design both interfaces
An agent has two interfaces, and both need design. The first faces the model: its tools. Anthropic suggests investing as much in this agent-computer interface as in a human one, with clear tool descriptions, examples of use, and tools shaped so mistakes are hard to make. The second faces the person: show the plan before acting, show progress in plain words, and make every step reviewable. One of Anthropic’s three closing principles is exactly this: prioritise transparency by explicitly showing the agent’s planning steps.
Complexity is not a feature. Start with the simplest system that could work, and let real usage tell you when to add more.
How we decide
- Can we write the steps down in advance? Then it is a workflow.
- Do the steps genuinely depend on what the system discovers along the way? Consider an agent.
- What does a wrong step cost, and can it be undone? The higher the cost, the more human review.
- Can we evaluate each step on its own? If not, it is not ready to ship.
- Would a person understand what the system is doing while it works? If not, the interface is not done.
Starting simple is not caution for its own sake. It gets a useful product in front of people sooner, produces the real usage data that shows where autonomy would help, and leaves room to add it deliberately.
