Workflows vs agents: where rigid code actually runs out

«Agent» has become a word people use for any system with a model in it. That is a shame, because there is a real distinction underneath, it has consequences for what you can debug at 3am, and someone already wrote it down clearly.

1. Two models of control

Anthropic's Building Effective Agents draws the line at a single question: who decides the path. 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».

That test reclassifies a lot of things people call agents. It also reclassifies our own system, and it is worth saying so plainly: by this definition Bentho's conversational orchestrator is a workflow. The model extracts at temperature 0; the code decides.

2. The framework, and what it actually recommends

The article names six patterns: prompt chaining, routing, parallelisation, orchestrator-workers, evaluator-optimizer, and the autonomous agent. Five of the six are workflows. That ratio is the recommendation, stated as a taxonomy.

Start with simple prompts, optimize them with comprehensive evaluation, and add multi-step agentic systems only when simpler solutions fall short.

Anthropic — Building Effective Agents

Coming from a company that sells the models, that is advice against its own short-term interest, which is roughly the only kind worth quoting.

3. Where a canvas actually runs out

The usual claim here is that visual builders break past some number of nodes. There isn't one — not a documented threshold in n8n, Make or Zapier, and not a research result. So here is the mechanism instead, which is checkable against your own screen.

A canvas holds the happy path beautifully. What it holds badly is everything that is not a path: an invariant («this figure must always come from the quote»), a contract («this field is a string of at most 4000 characters»), a policy («never answer a price you cannot source»). None of those are steps, so none of them have a place to live on a diagram.

So they get encoded as more branches, and the diagram grows in the one direction it reads worst. The real tell is not the node count: it is the moment the team starts adding sub-workflows and code nodes. That is the canvas admitting it stopped being the representation.

4. Bounded autonomy: contracts, not trust

If you do give a model room to decide, the useful question is not how much freedom it has but what it cannot do regardless. Three boundaries do most of the work, and all three are ordinary engineering:

1. Validate the input before anything decides. Typed commands extracted from the turn, checked at the boundary. What reaches the decision code already has a known shape.
2. Give every capability a contract. What it takes, what it gives back, and for which customer — checked before it runs. A capability that verifies who is asking cannot be talked into answering for someone else.
3. Verify the output before it leaves. Every figure in the final message must come from an authority. One that doesn't is discarded, and a deterministic template answers.

With those three in place, autonomy stops being a risk you accept and becomes a region you drew. Bentho also isolates genuinely open-ended work into sub-agents — with a deterministic interrupt for human approval on handoffs and disputes — which is the hybrid shape in practice: a workflow that delegates, not an agent that is supervised.

5. A decision matrix you can actually apply

6. Hybrid patterns

The two are not exclusive, and the useful shape is usually neither pure. A deterministic spine handles the turn, the money and the contracts; a bounded agent handles the one sub-task whose length nobody can predict — research, reconciliation, a messy document — and hands back a typed result that the spine verifies like any other input.

The discipline is that the spine never delegates the decision it is accountable for. Delegating work is an optimisation; delegating judgement is a change of architecture.

The framework, and where to read it

The framework is not ours. It is Anthropic's, quoted word for word above, and worth reading in full — it is short, and it disagrees with plenty of what gets sold as agentic.

• building-effective-agents — It defines workflows as «systems where LLMs and tools are orchestrated through predefined code paths» and agents as «systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks». The difference is WHO decides the path, not how much AI is inside.
• building-effective-agents — «Workflows offer predictability and consistency for well-defined tasks, whereas agents are the better option when flexibility and model-driven decision-making are needed at scale». Agents suit «open-ended problems where it's difficult or impossible to predict the required number of steps».
• building-effective-agents — «Start with simple prompts, optimize them with comprehensive evaluation, and add multi-step agentic systems only when simpler solutions fall short». The advice argues against complexity for its own sake: build the RIGHT system, not the biggest one.
• building-effective-agents — The patterns it names: prompt chaining, routing, parallelisation (sectioning and voting), orchestrator-workers, evaluator-optimizer, and the autonomous agent. Five of the six are WORKFLOWS.

Checked in Anthropic's article on 2026-09-25. It may have changed since: if you are about to make a decision on one of these, check your own.