Chatbot or AI agent?

According to Mesterséges Intelligencia Központ Kft., a software development company based in Budapest, Hungary, a chatbot is needed when the task is answering questions, and an AI agent when the system must also carry out steps: look things up, record, book.

In short: A chatbot talks; an agent also acts. It pays to start with the simplest solution that does the job and to move to an agent only where the order of the steps cannot be written down in advance. In that case, the agent should work with narrow permissions, with logging and with human approval before important steps.

What do the terms mean?

The words “chatbot” and “AI agent” are used in many different ways on the market. So that we talk about the same thing when making a decision, we distinguish five solutions, from the simplest to the most autonomous.

Rule-based chatbot

It follows a pre-written script made of buttons, keywords and a decision tree. It is fully predictable, calls no language model and says exactly what was written into it. But it only understands what it was prepared for: a question phrased differently falls outside the script, and every new topic has to be built in by hand.

Chatbot built on a language model

A large language model (LLM) understands free-text questions and answers in natural language, coping with typos and everyday phrasing too. If it relies only on the model's general knowledge, however, it can confidently give wrong answers about the company, so in business use we almost always tie it to the company's own material.

Chatbot that answers from documents

For each question the system first finds the relevant passages in the company's documents (FAQs, policies, manuals), and the model answers from them, citing the source. The method is called RAG (retrieval-augmented generation); the article AI on the company's own documents (RAG) covers how it works, the Hungarian language and where the data is stored.

AI workflow

Anthropic's guide on agents defines a workflow as a system in which language models and tools are orchestrated through predefined code paths. An example: incoming email → classification → data extraction → draft reply in the CRM. The order of the steps is fixed, and in each step the model does one well-defined language task. Many business needs are in fact workflows like this, not agents.

AI agent

The same guide describes an agent as a system in which the language model dynamically directs its own process and its use of tools. According to OpenAI's documentation, agents plan and complete tasks using tools and maintain context across steps. The agent receives a goal (“please record the complaint and send the customer a confirmation”) and decides itself which steps achieve it: it looks up the order, checks the warranty, records the case and writes the email. The tool is not run by the model: according to Google's Gemini documentation the model does not execute the function itself, and according to Anthropic your own tools are executed by your application. The model only requests the operation; our code carries it out, and that is where it is decided what is allowed.

Anthropic's advice is simple: find the simplest solution possible and only increase complexity when needed. According to the guide, agents suit open-ended problems where it is difficult or impossible to predict the required number of steps, and agentic systems often trade latency and cost for better task performance.

Comparison in one table

In the table, the chatbot built on a language model appears in its document-answering form, because that is almost always how it is built for business use.

Aspect	Rule-based chatbot	Chatbot answering from documents	AI workflow	AI agent
What it does	follows a pre-written script	answers from the company's material	carries out a fixed sequence of steps with language tasks	receives a goal and chooses the steps itself
What it understands	the keywords and buttons it was prepared for	free text	the text entering the process	free text and the results of its tools
What it can access	the script	the knowledge base	the systems assigned to the steps	the tools it is given
Predictability	complete	high, if it cites sources	high	lower; strict limits are needed
Main risk	rigid, many questions fall outside	a wrong or outdated answer	a faulty extraction in one step	wrong or too many actions, compounding errors
Control	maintaining the script	cited sources, “I don't know”, handover to staff	checks at each step, approval	permissions, approval, logging, limits
A good choice if	there are few, well-defined questions	there are many questions and many documents	the steps of the process can be written down in advance	the number and order of steps cannot be foreseen

The boundary is not sharp: a chatbot that looks up an order's status with a single read-only tool has taken a step towards being an agent, but its risk stays low. The deciding question is always what the system is allowed to do, not what we call it.

Which fits where?

Customer service

For frequent questions (delivery, payment, warranty, opening hours), a chatbot answering from documents is the right starting point, at any time of day, with handover to a member of staff when it gets stuck. For order status, a read-only lookup is enough. Where the bot also writes, for example recording a complaint or initiating a refund, agent capabilities are needed, with approval before any step that involves money.

Sales

The bot recommends products from the catalogue, prepares quote requests, books appointments and records leads in the CRM. Booking and recording are tool use, so they are agent elements; prices, discounts and deadlines, however, are best taken out of the bot's remit and assigned to staff.

Internal help desk

For HR and IT questions, policies and work instructions, a chatbot answering from documents is the natural choice, and it also helps new colleagues get up to speed. Here access rights are the main question: the bot may only answer from documents that the colleague asking could open. Opening a ticket or requesting access can already be an agent with a narrow set of tools.

Back office

Processing invoices, orders and emails is typically an AI workflow, because the steps are known in advance: extraction, matching, recording, exceptions to staff. An agent is justified where cases vary widely, for example when investigating a complaint that requires collecting data from several systems. We write about automation spanning several systems on the Process automation page, and about integration patterns (API, webhook, function calling, MCP) in the article How do we connect business systems with artificial intelligence?.

Agent risks and controls

An agent is useful because it acts, and that is also what makes it risky. Anthropic's guide names higher costs and the potential for compounding errors as the price of an agent's autonomy, and recommends extensive testing in sandboxed environments, with appropriate guardrails. The OWASP GenAI Security Project's risk list names three root causes of Excessive Agency: excessive functionality, excessive permissions and excessive autonomy. That is why we build in these controls:

A narrow set of tools: the agent only gets the tools its task needs; a customer service agent does not need to delete anything.
Minimal permissions: read-only access wherever possible; the action runs with the user's own permissions, not with a service account that can reach everything.
Checks in the target system: every request is also checked against the target system's rules, so what is allowed does not depend on the model's judgement.
Human approval: a person decides before any step involving money, a contract, a message to a customer or an irreversible change. OpenAI, for example, asks for approval by default before data is shared with a remote MCP server.
Logging: every tool call, parameter and result can be traced, so the cause of a faulty action can be found.
Limits: caps on the number of steps, frequency and amounts, so that a mistake cannot multiply.
External content as data: the text of an incoming email or an uploaded document is not an instruction. Against prompt injection, OWASP recommends handling external content separately, clearly marked as untrusted.
Testing in an isolated environment: before go-live, in a test system, with real cases and deliberately misleading inputs.

These controls do not slow the work down unnecessarily: an approval can be a single click, and based on measurement it can gradually be narrowed to where it is really needed.

Transparency: people must know an AI is answering

Under Article 50(1) of the AI Act, Regulation (EU) 2024/1689, AI systems intended to interact directly with natural persons must be designed so that the people concerned are informed that they are interacting with an AI system, unless this is obvious from the circumstances. When this applies, exactly to whom, and what the GDPR requires for a chatbot are covered in detail in the article AI Act and GDPR for a business chatbot; this is information, not legal advice.

A live example: the AI assistant on our homepage

Next to the game on our homepage, the AI assistant talks with visitors: it is our own live AI chatbot, and it shows well where the line between a chatbot and an agent runs.

It runs on a Claude language model and receives machine-readable reports of the game's events (losing a life, a new record, reaching a new level), to which it reacts live.
It answers in the game's 14 languages and always uses the polite form of address, even when the visitor does not.
It talks about the company from the facts it is given: its instructions forbid inventing references, prices, deadlines or guarantees.
It can talk but cannot act: it cannot interfere with the game, and it cannot award points or lives.

The last point is the key one: the limit of what it may do is set not by the model's good intentions but by how the system is built. You can read about our own projects on the Our work page.

How to start small

One area, one list of questions: collect what people ask most often, for example in customer service.
A chatbot built on your own material: with cited sources, an “I don't know” answer and handover to a member of staff.
Measurement on real questions: on an evaluation set before go-live, and from the conversation logs afterwards.
A first tool, read-only: for example looking up the status of an order.
A first write operation with approval: for example recording a complaint, which a member of staff approves.
Expansion based on the logs: a new tool or a narrower approval circle only where measurement justifies it.

Typical mistakes

An agent where a chatbot would do: more moving parts and more risk, with no benefit.
All tools at once: the agent can do things it will never need to do.
No “I don't know”: the bot would rather make something up than pass the question on.
No handover to a person: a customer who is stuck never reaches a member of staff.
No log: afterwards nobody can tell why a faulty action happened.
Treating external text as instructions: a sentence hidden in an email can steer the agent.

Frequently asked questions

What is the difference between a chatbot and an AI agent?

A chatbot answers questions, ideally from the company's own material, citing its sources. An AI agent also uses tools (it looks things up, records, books, writes emails) and chooses the steps itself towards a goal. Both can run on the same language model; the difference is in what they are allowed to do.

When is a chatbot enough?

When the task is providing information: frequent questions, policies, product information, internal knowledge. It is also enough when a person does the work after the answer. When the system has to change data or act in another system, a workflow or an agent comes into play.

What can an AI agent do on its own?

Whatever it is given tools and permissions for, and whatever its risk allows us to entrust to it without approval: typically lookups, internal records, preparing drafts and booking appointments. Before steps involving money, a contract or a message to a customer, or steps that cannot be undone, it is advisable to ask for human approval.

How can we prevent the agent from making mistakes?

They cannot be ruled out completely, but the damage can be limited: with a narrow set of tools, minimal permissions, requests that are also checked in the target system, approval before high-impact steps, limits on steps and amounts, a complete log and testing in an isolated environment before go-live. Incoming text is treated as data, not as instructions.

Do we have to tell users that an AI is answering?

As a rule, yes: under Article 50(1) of the AI Act, people must be informed that they are interacting with an AI system unless this is obvious. A chatbot we build says so in its very first message. The details are in the article AI Act and GDPR for a business chatbot; this is information, not legal advice.

How we can help

Mesterséges Intelligencia Központ Kft. develops both AI chatbots and AI agents: bots that answer from the company's own documents and agents connected to the company's systems that carry out steps, built on the language models of OpenAI (ChatGPT), Anthropic (Claude) and Google (Gemini). The first consultation is free of charge; we measure the size of the development in COSMIC function points, and the offer and the schedule are based on it. We sign a non-disclosure agreement (NDA) on request, and after handover we also take care of operation and maintenance. The contract governs source code and usage rights.

The details are on the AI chatbots and agents service page, and connecting language models is covered on the AI integration page. If you are planning a chatbot or an agent, write to us using the details on the Contact page.