What people actually mean when they say "bot"

Someone says "we should build a bot" and everyone in the room nods while picturing something different. One person is imagining a chat window. Another is imagining a script that files invoices. A third is picturing a thing with wheels. All three are correct, which is the problem.

Here are the eight jobs the word actually covers, grouped by what the thing does rather than what it's built with. For each: what it is, what it costs, and the honest signal that you've picked the wrong one.

Group one: it fetches

1. The scraper

Reads a web page a human would otherwise read, and pulls out the bits that matter — a price, a job listing, a policy change. No conversation, no decisions, no intelligence required. At its simplest it is about sixty lines of Python and it runs for free.

This is the most under-estimated category on the list. A very large share of "we need AI to monitor our competitors" turns out to be a scraper and an email. There's a complete one here if you want to see the whole shape of it.

Wrong tool signal: you're driving a full browser to read a static page. That's a hundred times slower and more fragile than reading the HTML directly.

2. The crawler

A scraper that follows links. One page is a script; fifty thousand pages is a different discipline — queues, retries, deduplication, rate limiting, resuming after a crash. The scraping is the easy part; not being rude or blocked is the job.

Wrong tool signal: you wrote a for loop over URLs and it died at hour six with no way to resume.

3. The monitor

Watches something that isn't a web page — an inbox, a folder, a database, an API, a sensor — and reacts when it changes. Mechanically the same as a scraper, different source. Usually the cheapest useful thing you can build.

Group two: it acts

4. The automation

A fixed sequence of steps that runs the same way every time. Read the invoice, extract the total, put it in the sheet, file the PDF. Deterministic, debuggable, and boring in the best way. One of its steps might call a language model — that's fine and doesn't change what it is.

Tools: n8n, Make, Zapier, or eighty lines of Python and a cron entry.

Wrong tool signal: you built it as a conversational agent and now nobody's sure what it will do on Tuesday.

5. The browser bot

Drives a real browser like a person would: logs in, clicks, fills forms, downloads a file. Reach for it when there's genuinely no API and the site needs a session, or when the task is the clicking — filing the same report every Friday, for instance.

Wrong tool signal: an API exists and you're clicking anyway. Always check for the API first, including the undocumented JSON one the page itself calls.

Group three: it talks

6. The rules chatbot

The decision-tree kind. "Press 1 for billing." No model involved, entirely predictable, and still the right answer when the conversation has five possible paths and a wrong answer is expensive. Unfashionable; occasionally correct.

7. The assistant

A conversational layer over a body of knowledge — your docs, your catalogue, your policies. It answers, clarifies, and hands off when unsure. Crucially it doesn't do anything: no bookings, no refunds, no writes to your data. That constraint is what makes it cheap and safe.

Typical cost: a few hundred to a few thousand dollars, and a handful of dollars a month to run.

Wrong tool signal: customers keep asking it to actually do the thing, and it can only describe the thing. That's the moment you need the next category.

Group four: it decides and acts

8. The agent

An assistant that can also take action in your systems — look up the real order, book the real slot, update the real record. The moment software can change the world, everything gets harder: permissions, guardrails, approvals, logging, and a plan for the first time it's confidently wrong in front of someone who matters.

This is the only category on the list where most of the work is not the feature. It's the safety rails.

A multi-agent system is several of these with distinct roles, coordinated. Genuinely useful for a small number of problems, and prematurely adopted for a very large number of them. If one agent hasn't demonstrably failed at the job yet, you don't need several.

The whole thing as a table

Ranges are for a competent build including deployment, not a demo. A voice channel pushes any row up a band.

How to pick, in two questions

Does a person talk to it? If no, you're in the fetch-or-act half: scraper, crawler, monitor, automation or browser bot. If yes, ask the second question.

Does it only answer, or does it also act? Only answers — assistant, or a rules chatbot if the paths are few and fixed. Also acts — agent, with everything that implies.

Where to go next

If you landed on scraper, crawler or browser bot, the tools comparison is the next thing to read — it settles which library to use before you write a line. If you're not sure what any of these are built from, the library reference groups everything by the job it does. And if you'd rather just build one, answer four questions and we'll order the library around what you want to make.