AI agent, automation, chatbot: the differences

The three differ on one question: who decides the next step. In an automation, you decided it in advance, when you drew the workflow. In a chatbot, the person typing decides, one message at a time, and the bot only answers. In an agent, the model decides at each step, choosing which tool to call next until the goal is reached or a limit stops it. Everything else (cost, reliability, how you test it) follows from that.

Vendors use the word “agent” for all three, so it helps to know which one you are being sold, and which one your problem needs. In my experience most growth tasks need an automation with one or two model calls inside, and fewer need a real agent than the market suggests.

Automation: you draw the path

An automation is a fixed sequence of steps triggered by an event. Make and n8n are the usual tools for it. Here is a typical one, written out:

trigger: new row in the "Demo requests" sheet
steps:
  1: search the CRM for a company with this domain
  2: if none found, create the company
  3: create a deal at stage "Demo booked", owner = round robin
  4: post the deal link in the #sales channel
on_error: email the ops owner

Same input, same output, every time. It is cheap to run, easy to test with a handful of cases, and its failures are usually loud: a step errors and you get the email. Its weakness is variety. The day a request arrives with a personal Gmail address instead of a company domain, step 1 finds nothing, step 2 creates a company called “gmail.com”, and nothing complains. Every new case means a new branch, drawn by hand.

You can put a model inside an automation. Step 2 could ask a model to classify the request as “company”, “student” or “spam” before creating anything. The path is still yours; the model only fills one box. This hybrid is what I reach for most often.

Chatbot: it answers, it does not act

A chatbot is a model in a conversation. It reads what you type and writes a reply. Some can search the web or read a file you attach, but the result comes back to you as text, and you decide what to do with it.

That makes it a good tool for thinking: drafting, rephrasing, exploring an idea, explaining a dataset you paste in. It is a poor fit for operations, because the work stops at the edge of the conversation. Somebody has to copy the answer into the CRM, the sheet or the sending tool, and that somebody is the bottleneck you wanted to remove. A support bot on your website is the same thing pointed at customers: it answers questions within what it was given, and it should not be presented as more.

Agent: a model in a loop with tools

An agent is a model given a goal, rules and a set of tools it can call. A tool is a function you expose with a name, a description and the inputs it expects. For example, in the format used by Claude’s API:

{
  "name": "find_company",
  "description": "Look up a company in the CRM by root domain. Returns id, name, owner and stage, or null if not found. Read only.",
  "input_schema": {
    "type": "object",
    "properties": {
      "domain": { "type": "string", "description": "Root domain, for example acme.com" }
    },
    "required": ["domain"]
  }
}

The model reads the goal, decides to call a tool, gets the result, decides what to do next, and so on:

give the model: goal + rules + tool definitions
repeat:
  the model returns a tool call or a final answer
  tool call    -> run it, give the result back to the model
  final answer -> check it against the spec, then stop
stop anyway after N steps or when the budget is spent

That loop is what lets an agent handle the Gmail case on its own: it finds no company, notices the address is personal, looks up the name on LinkedIn, and reports “unknown employer” instead of inventing a company. It is also what makes it harder to test, since two runs on the same input can take different paths. MCP, an open protocol, is a standard way to expose tools like find_company to any compatible AI client; chapter 7 covers it. Anthropic’s engineering team has written a clear piece on workflows versus agents that makes the same distinction from the builder’s side.

The three side by side

	Automation	Chatbot	Agent
Who decides the next step	You, in advance	The user, each message	The model, at each step
Same input, same output	Yes	No	No
Acts in your tools	Yes	Rarely, and you copy the result	Yes, through the tools you allow
Cost per run	Low and predictable	Per conversation	Variable, needs a ceiling
Typical failure	Silent wrong branch on an unexpected input	Confident wrong answer	Wrong path, loops, invented fact, reports success on partial work
How you test it	A set of test cases	Reading transcripts	Frozen test cases, sampled outputs, run logs

The last two rows are the ones people skip. An agent needs a cost ceiling and a step limit written into it, and its tests have to be rerun every time you change its instructions.

Most real systems mix the three

The outbound plugin I published for Derrick (a prospecting tool I co-founded) shows how the three combine. The overall flow is fixed, like an automation: import, enrichment, message, sequence, push, then a weekly review. Inside some steps, the model makes judgement calls: which signal on a lead is worth using, how to write the first message in the user’s own voice. At the risky step, a deterministic check runs before anything is written: the push refuses to overwrite a lead who is already in an active campaign. And at the sequence step, the agent only advises on the structure; the person builds the sequence in their sending tool.

The same logic applies to which model runs where. In the agent team behind Derrick’s marketing, the strongest model handles the lead agent and the experts, where judgement matters, and a small fast model handles purely mechanical sub-tasks like find and replace.

Rules I use to pick:

• If you can list every case in advance, build an automation.
• If one step needs reading or classifying messy text, add a model call to that step and keep the path fixed.
• If the number of steps depends on what the agent finds along the way, consider an agent, with a step limit, a budget and a check on the output.
• If a step is irreversible (sending, paying, deleting, overwriting), keep it deterministic or put a person on it.

What to ask before you buy an “agent”

When a vendor or a freelancer offers you an agent, these questions tell you which of the three you are getting:

Question	What a good answer sounds like
Who decides the next step?	A clear answer: fixed flow, model, or a mix, step by step
Which tools can it call, and with what permissions?	A list, with read-only and write access separated
What stops it?	A step limit, a cost ceiling, a stop condition on errors
How is the output checked before it reaches a customer?	A rule-based check plus a sample read by a person
What happens when an input looks nothing like the examples?	It returns “unknown” or stops, and you get told
Can I see the log of a run?	Yes, every tool call and its result

If the answers are vague, you are probably looking at a chatbot with a nicer interface, or an automation with a new label. Both can be fine, as long as the price matches.

Your next step: take the task you circled in chapter 1 and write, for each step, who decides what happens next. Then pick your tools with the tools chapter.