Parser, bot, service or agent: what to automate a process with

Almost every automation request is answered by one of four tools. A parser gets you data you do not have. A bot gives people an interface where they already are. A service holds state and connects systems to each other. An agent takes a goal and picks the steps itself. The expensive projects are rarely the ones that chose a tool that was too simple. They are the ones that reached for the most complicated tool without a reason.

I have been building these for the last few years: Telegram bots for event operations, a FinTech prototype with an AI layer, a voice command deck sitting on top of a 27-project portfolio, a Shopify course store. Choosing the tool never took more than a day. Choosing it wrong cost weeks. Here is how I make the call.

Four tools and what each one actually does

A parser turns someone else's data into your table. Competitor prices, job listings, classifieds, industry news, a supplier catalogue with no usable API. It runs on a schedule, decides nothing and talks to no one.

A bot is an interface. It lives in Telegram or another messenger and can ask, show, remind and accept a file. It is exactly as smart as you made it. Its real value is not intelligence, it is that nobody has to install an app or remember a password.

A service is your own backend. It has a database, permissions, an operation history and an API. You need one when data must outlive a session, when different people work with it under different roles, and when two outside systems have to know about each other.

An agent receives a goal rather than an instruction. It decides the order of actions, which tool to use, and when to stop and ask a person. It is the most expensive and the most temperamental of the four.

The difference between them is not how much AI sits inside. It is who makes the decision: a schedule, a user, your code, or a model.

Parser: the data you do not have yet

Parsing looks like the easy job right up to the moment it runs in production.

Check for an API first. An official API is almost always cheaper to maintain than the tidiest scraper, even when it costs money. HTML parsing breaks quietly: the site changed its markup on Thursday and you find out two weeks later from a report that looks slightly wrong.

Then the legal side. I am not a lawyer, but two facts are worth knowing. In the United States, the Ninth Circuit in hiQ Labs v. LinkedIn upheld an injunction against blocking a scraper, reasoning that the Computer Fraud and Abuse Act was written against intrusion into protected systems rather than against collecting pages open to everyone (2022 opinion). In the EU, Article 4 of Directive 2019/790 allows text and data mining while letting rights holders opt out (EUR-Lex). Personal data sits under GDPR on its own terms, and "it was public anyway" is not a defence there.

What actually breaks scrapers:

• Page structure changes without warning. Write assertions on the shape of the data, not only on its presence.
• Pagination and rate limits. Run slower than you can. A blocked IP costs more than the hour you saved.
• Duplicates. The same product under three SKUs turns a report into noise. Normalisation takes more code than collection.
• Silent empty results. The scraper finished, no errors, zero rows. That should raise an alarm, not count as a success.

On putting AI inside a parser. A model is good at pulling meaning out of dirty text: reducing five phrasings of the same job title to one, lifting specs out of a description. A model is bad at navigating pages and bad at arithmetic. Leave collection and navigation to code, and hand the model the job of making sense of what came back.

I held to the same rule writing the markdown parser for this blog. It is two hundred lines, pulls in no dependencies, and supports exactly the syntax I use. A ready-made library was tempting, but the Railway build installs with a frozen lockfile, and one extra dependency would have cost more than the code did.

Bot: an interface, not a brain

A bot wins wherever the job is to remove friction. Nobody downloads an app, registers, or hunts for a password. They are already in the messenger.

TT Production Event Planner was exactly that problem. Requests for sound and lighting arrived as free text, and a manager burned half an hour clarifying each one. The bot walks people through equipment and venue selection and hands the manager a structured brief. There is no AI anywhere in the critical path, which is correct: picking from a catalogue does not need a model.

AI earns its place in a bot when the input is unstructured. Event AI Agent is that case. People describe an event however they like, and what comes out has to be a parsed request with a date, a format and a budget.

Where bots run out: complex screens, long forms, tables, a personal dashboard with history. That is where a mini app starts. I drew the line in detail in bot versus mini app, and the price of each in what a mini app costs.

Service: when you cannot avoid your own backend

Signs you have outgrown bots and scheduled scripts:

• Data has to survive longer than one session and look different to different people.
• Roles have appeared: client, operator, admin.
• Two external systems need to exchange data, and something has to resolve their conflicts.
• You need history: who changed what and when.

A service is rarely impressive. Its value is that it is boring and predictable. In NeuroWallet I built the wallet prototype with a dashboard, a virtual card and AI insights as a stateful product rather than a bot, because without proper storage of balance and transaction history the demo would have fallen apart on the second screen.

One practical detail that saves months: add webhooks and a queue on day one. Calling an outside API synchronously from a form handler works right up to the first Friday evening that API goes down.

Agent: when the goal matters more than the steps

An agent earns its cost when the route is not known in advance. Research a topic, compare sources, draft the material, send it back for review. If the steps are known and stable, write an ordinary pipeline. It will be cheaper, faster and more reliable.

My working example is Pulsara, a voice command deck over a 27-project portfolio. You can ask for the status of a project out loud or hand it an audit, and the system runs the work in the right folder. Inside there is a router and seven specialised agents with memory. Three decisions mattered more than the architecture: the API key stays on the server and the browser only ever gets a temporary token; agent permissions are scoped to one project folder, with no Git and no deploy access; architecture maps are cached, or every request would cost as much as a full session.

The full method, with roles, autonomy limits and source checking, is in AI agents for business. Short version: an agent without limits is not a powerful agent, it is an unmanaged one.

How to choose in five minutes

Ask four questions in order and stop at the first yes.

1. 01Do you need data you do not have, from a source that stays put? Parser.
2. 02Do you need a person in the loop, and are they already in a messenger? Bot.
3. 03Do you need state, roles and a link between systems? Service.
4. 04Does the route change from task to task, with a result a person can check? Agent.

Most working setups end up as a combination: the parser collects, the service stores and serves, the bot faces people, and an agent handles the one stretch that genuinely needs freedom of choice. You do not need to build all of it. You must not start with all of it.

What it costs and how long it takes

The numbers I estimate with.

A parser for one source with output to a table or database: one to two weeks. Each additional source adds roughly a third of the first, because normalisation is already written.

A bot with a scripted flow and handoff to a human: two to three weeks. Add a week for AI parsing of free text, most of it spent on prompts and on testing that the model answers predictably.

An internal service with roles and one external integration: four to eight weeks. The second integration costs more than the first, not the same.

An agent workflow on top of data you already have: three to six weeks before you can put it in front of people. More than half of that goes into boundaries rather than building: what it does alone, what it shows for approval, how it explains where each fact came from.

Rates explain the gap between two quotes better than scope does. Eastern European teams charge $30 to $65 an hour, Western European teams $80 to $140. Starting figures for the formats I work in are on the pricing section.

Three mistakes I see most often

Automating a process that does not exist. While the sequence lives in one employee's head and changes weekly, there is nothing to automate. Write the process down in plain words first. Half of all projects end at this step, and that is a good outcome.

Reaching for an agent where a script would do. Agents cost more to build, more to run and are noticeably harder to debug. If you can draw the flowchart without branches that require judgement, you want a pipeline.

Leaving out verification. Every automation needs an answer to "where did this number come from". A parser should keep the source page or its hash. An agent should show the source of a fact. Without that, the first mistake wipes out trust in the whole system, including the parts that work.

Where to start

Take one process that repeats at least weekly, eats noticeable time, and ends in a result somebody can check by eye. Write down the input, the output and the acceptance criterion. Then pick the tool with the four questions above.

I try to get a first version in front of real people within two weeks. Not because it sounds good, but because every estimate stays a hypothesis until it meets real data. What actually fits in that window is in what you can ship in two weeks. My process is the same at any budget, because the expensive mistakes happen in step one.

FAQ about AI automation

How is AI automation different from ordinary automation?

Ordinary automation runs steps you described in advance. AI automation adds work with unstructured input: free text, documents, speech, images. You need a model where the rule cannot be written down explicitly. Everything else is cheaper and more reliable in code.

Is scraping websites legal?

It depends on what you collect and where. In the United States, the Ninth Circuit in hiQ v. LinkedIn treated the Computer Fraud and Abuse Act as aimed at intrusion into protected systems rather than at collecting publicly accessible pages. The EU has a text and data mining exception that rights holders can opt out of. Personal data falls under GDPR regardless of whether it was public. A site's terms of service and its robots.txt matter too. Take the borderline cases to a lawyer before launch rather than after.

Does a small business need an AI agent?

Usually not, and certainly not first. Start with one process and the simplest tool that closes it. An agent earns its place once the route changes from task to task and you already know how to check the result.

What does automating one process cost?

A parser for one source is one to two weeks of work, a scripted bot two to three, an internal service with roles and an integration four to eight. The final figure depends on the team's rate and on how many outside systems are in scope. Starting figures are on the pricing section.

Can no-code tools do the job?

Often yes, and that is a reasonable first step. n8n, Make and Zapier close simple chains quickly. Custom code wins once you hit non-standard logic, sensitive data, meaningful call volume, or a requirement to keep everything on your side.

What if the model gets things wrong sometimes?

Treat that as normal and design for it. Split actions into reversible and irreversible. A draft, a shortlist and a classification the model can deliver on its own. Sending an email, taking a payment, deleting data and changing permissions need a person to confirm. And every fact should show its source.

What good automation means to me

A good system does not make anyone learn about models and tokens. It explains in plain words what it will do, what data it needs, what it will cost and where it will stop and ask you. It can be switched off without a developer. Its output can be checked.

There is one more test I rate above the rest: you are not nervous about leaving the system running on a Friday evening. If you are, what is missing is boundaries, not horsepower.

If you have a repeating process worth testing, send me a message. We can start with one task and a result we can measure.