Bots are agents that stopped needing to think
The usual framing has bots as the primitive thing agents replaced. It's the wrong way round. A bot is the part of an agent that has already been figured out — and it runs for nothing.
There's a story the industry tells about automation: first there were scripts, then bots, then agents, and each generation made the last obsolete. It's a tidy story and it leads people to build expensive things.
Here's a better one. An agent is a system that decides what to do. A bot is a system that already knows. They aren't rungs on a ladder; they're two halves of the same machine, and the interesting engineering is deciding which work belongs in which half.
Every agent contains bots
Take an agent that handles customer email. Underneath, it is doing a handful of distinct things: connecting to the inbox, pulling new messages, deciding which ones matter, drafting a reply, sending it, logging what happened.
Only one of those steps needs a model. Fetching mail is a solved problem with a deterministic answer. So is sending, and logging. The judgment — which of these matters, and what should it say — is the part that genuinely benefits from a model, and it's a small fraction of the total work.
The rest is bot. Not because it's primitive, but because the decision has already been made and encoded. That's what a bot is: a decision someone already made, executing reliably and for free.
The economics nobody mentions up front
This distinction has a direct consequence on your bill. Model calls have a marginal cost per run. Deterministic code does not.
| Approach | Cost of run #1 | Cost of run #100,000 |
|---|---|---|
| Everything through a model | Fractions of a cent | Meaningful money, forever |
| Model decides once, bot executes | Fractions of a cent | The same as run #1: nothing |
A price watcher checking two hundred pages an hour is roughly 1.7 million checks a year. As deterministic code, that's free — the electricity to run a Raspberry Pi. Route each check through a model to ask "has this changed?" and you're paying, every hour, forever, for an answer that != already gives you correctly and instantly.
This isn't an argument against models. It's an argument about where to spend them. Which brings us to the useful part.
The pattern: decide once, execute forever
The highest-leverage move in this whole field is using a model to work something out, then capturing the result as code that runs without it.
Concretely: you don't know which CSS selector holds the price on a page you've never seen. A model can look at the HTML and tell you — a genuinely useful thing to ask it. But once you know the selector is .product-price, you don't need to ask again. You write it down. Every subsequent run is free.
That shape recurs everywhere:
Classification. Use a model to label a thousand support tickets. Notice that 80% fall into six categories with obvious keyword signatures. Write rules for those six, and route only the ambiguous remainder to the model. Your cost drops by four fifths and your latency by more.
Extraction. Have a model work out the structure of a supplier's invoice once. Encode the layout. Process the next ten thousand invoices deterministically, escalating only the ones that don't match.
Routing. Let a model tell you what a good triage decision looks like, then implement the rule. Keep the model for the edges.
What bots are genuinely better at
This is not a consolation prize. In their domain, deterministic systems beat models outright:
They're exact. price != last_price is correct one hundred percent of the time. No model will match that on a comparison task, and you don't need one to.
They're fast. Microseconds, not seconds. For anything reacting to events in real time, that gap decides whether the thing is usable.
They're auditable. When a bot does something surprising you read the code and find out why. That's not nothing when the surprise cost money.
They're the same on Tuesday. Same input, same output, this year and next — no variance, no drift when a provider updates a model.
They work offline and in odd places. An ESP32 in a plant pot has no internet budget and no API key. That's a bot or it's nothing.
Where models are worth every penny
Equally, there's work no amount of clever code will do:
Judgment on unstructured input — is this customer angry? — where the rules are real but nobody can write them down. Anything involving language: summarising, drafting, translating, rewriting. Perception: is that shape a parcel or a cat. Novel situations, where the value is precisely that you didn't anticipate it.
The honest test: if you can write the rule, write the rule. If you've tried and the rule keeps growing exceptions, that's a model's job.
A sane architecture
Most well-built systems in this space are mostly bot with a small model in the middle:
bot → fetch the data (deterministic, free)
bot → filter the obvious (deterministic, free) ← cheap gate
model → judge what's left (costs money, worth it)
bot → act on the answer (deterministic, free)
bot → log, notify, store (deterministic, free)
The door camera build on this site is exactly this. Comparing frames numerically is arithmetic and eliminates over 99% of them for free; only what survives that gate reaches a vision model. Take the gate away and the project costs a hundred times more and tells you nothing extra.
This is also what makes bounded autonomy tractable rather than aspirational: the system has real latitude at the one point where judgment is needed, and none at all everywhere else. Guardrails aren't bolted on afterwards — they're the deterministic majority of the machine.
So: start with the bot
The practical advice this all adds up to is unfashionable and correct. Build the deterministic version first. Run it against real data. See where it fails.
The failures tell you exactly where judgment is needed, which is almost always a narrower place than you'd have guessed. Add a model there, and only there.
You end up with something cheaper to run, easier to debug, faster, and far more likely to still be working in a year. And you'll understand your own problem properly, because you had to describe it precisely enough to write it down.
Next
If you want the taxonomy — what the eight things people call "bots" actually are — start there. If you're convinced and want to build one, the change watcher is a pure bot with zero running cost, and the hosting guide covers keeping it alive for nothing.
One new build sheet a week
Guides like this one, plus a new build sheet every Thursday. Written by a person who built it.