Chatbots, Workflows, Automation and Agents: Choose the Simplest System

Open any technology news site and you will find the claim that "agents" will soon do your job, your shopping and your homework. Underneath the excitement lies a real engineering question: for a given task, how much should you let the AI decide?

If you let it decide everything, you may get flexibility and also unpredictability. If you let it decide nothing, you get reliability and also rigidity. Most good designs sit in between. This article gives you the vocabulary and a method for picking the right point.

• Clear definitions of five kinds of system.
• One task solved five ways, with the trade-offs.
• A decision method and when ordinary automation wins.
• Why reliability falls as steps and autonomy rise.
• How to apply the rule "simplest system that works".

The categories overlap in practice, and products blur them. But the question "who decides what happens next?" cuts through the marketing.

Anthropic's engineering article on building effective agents draws a similar line. It describes workflows as systems where language models and tools are orchestrated through predefined code paths, and agents as systems where models dynamically direct their own processes and tool usage, keeping control over how they accomplish tasks. It adds that for many applications, optimising single model calls with retrieval and in-context examples is usually enough, a point we will return to.

Think of it as a ladder. Each step up gives the AI more say, and gives you less predictability and more to check.

Chatbot            you decide each step, AI answers  |Workflow           code decides the steps, fixed order  |Automation         software runs the steps on a trigger, no AI needed  |AI-assisted        code decides the steps; AI handles some of themworkflow           (summarise, classify, extract, draft)  |Agent              AI decides the steps and picks tools toward a goal

(Automation and workflow are not strictly "above" or "below" each other. A workflow can be run by hand or by a trigger. The ladder shows autonomy of the AI, and the box for plain automation sits at the "no AI decisions" end.)

Task: every Friday, send the team a short update on how many support tickets were opened and closed, and what the main themes were.

1. Chatbot. On Friday you export the tickets, paste them into an assistant, ask for a summary and counts, check them, and send the update yourself. Flexible, and entirely manual. The counts may be wrong, so you should check them.

2. Workflow (manual). You follow a written checklist: export the file, paste the counts into a template, write three sentences, send. Predictable and boring. Nothing here needs AI.

3. Automation. A script runs every Friday: it queries the ticket system, counts opened and closed tickets, fills a template and emails it. Reliable and cheap. It cannot summarise themes, because that needs judgment about language.

4. AI-assisted workflow. The same script does the counting (exactly, without AI). It then sends the ticket titles to a language model with a fixed prompt to propose three themes, validates that the output has the right shape, puts it in the template and holds the email for a human to approve. Counts are exact. Language work is done by AI. A person checks the text before it goes out.

5. Agent. You give an agent the goal "keep the team informed about support trends", plus access to the ticket system, the team chat and email. It decides what to query, whom to message and what to say. Powerful, flexible, open-ended. Also the hardest to predict and to test: it may choose different actions each week, misread a ticket, or send something to the wrong channel.

In this case, option 4 is likely the best fit: the task is repeated, the steps are known, only one step needs language skill, and the cost of an error (a wrong summary sent to the team) is moderate and can be caught with a review step. An agent adds flexibility the task does not need.

Anthropic's article puts it directly: start with simple prompts, optimise them with evaluation, and add multi-step agentic systems only when simpler solutions fall short. It also notes that agentic systems often trade latency and cost for better task performance, so you should consider whether that trade is worth it.

Four reasons simplicity wins:

If a process has several steps and each step works with some probability, the chance that all of them work falls quickly. The figures below are illustrative assumptions, not measurements of any real system, but the arithmetic is real:

A system that makes ten decisions, each right 95 percent of the time, gets the whole job right only about 60 percent of the time, assuming errors are independent and that any one error ruins the result. Real systems can recover from some errors and not from others, but the lesson holds: every extra step and every extra decision by the AI is another place to fail.

A fixed workflow does the same thing every time, so you can test it. An agent may take a different path on each run. You can still test and monitor it, but you need more evidence and more care to be confident.

Each model call takes time and money. An agent may make many calls in a loop. A script that counts rows costs almost nothing and finishes in a second.

When something goes wrong, you need to know why. With a fixed pipeline, you can look at the step where it failed. With an agent, you may have to read a long trace of its choices.

Use a normal program, spreadsheet formula, scheduled task or rule-based tool when:

• A precise rule exists. GST on an invoice, a date difference, a sum, a lookup, a format check, a threshold. These need exactness, which code gives and models do not guarantee.
• The input is structured (a database, a form, a spreadsheet) and the output is too.
• The task is high-volume, where cost and speed matter.
• A wrong answer is costly and you need to be able to prove why the system did what it did.
• There are regulatory or audit demands for exact, repeatable behaviour.

Many "AI automation" proposals are actually problems for a spreadsheet and a scheduled script.

Add AI to one step when that step involves messy language or judgment that rules cannot express:

• Classifying free-text messages (complaint, query, praise).
• Extracting fields from unstructured documents (dates, amounts, names from emails).
• Summarising long text.
• Drafting replies or reports from structured facts.
• Translating or rephrasing.
• Routing a request to the right team.

Wrap those steps with the safeguards you learned: a precise prompt, a defined output format, validation in code (see article 8), a safe fallback ("send to a person") and a human check where a mistake matters.

An agent may be worth considering when all or most of the following hold:

• The path cannot be known in advance. The number and order of steps depend on what is found along the way.
• The task is valuable enough to justify cost and complexity.
• Results can be verified automatically (tests pass, a checklist is satisfied) or by a person before they matter.
• Actions are reversible or contained, such as working on a branch, in a sandbox, or on drafts.
• Permissions are narrow, with approval for risky actions.
• You can monitor and stop it.

Coding agents working in a repository with tests are a common example: the steps vary, results can be checked by tests and version control lets you undo changes. Even there, humans review the changes before they ship. Article 31 explains how agents work, and article 32 covers how to make them and workflows reliable.

Ask these questions in order. Stop at the first "yes".

And these cross-checks:

• What is the cost of an error? The higher it is, the more you want determinism and human review.
• How often will it run? High frequency favours automation. Low frequency may not justify building anything.
• Can I describe "correct" precisely? If not, you cannot test any of these, so define it first.

• Building an agent for a task a script could do.
• Calling a simple prompt template an "agent".
• Letting the AI do the arithmetic in a pipeline.
• Skipping validation between steps.
• Automating a process you do not yet understand. Do it by hand a few times first.
• Giving broad permissions because narrowing them takes effort.
• Assuming more autonomy means more value.

• Next: Tool Use, Function Calling and Agent Loops Explained opens the box on how agents actually work.
• Then: Where Agents Fail and How to Build Reliable AI Workflows shows how to make any of these systems dependable.
• For turning prompts into reusable templates, revisit Iterate, Break Tasks Apart and Reuse What Works.