Chatbot, assistant or AI agent: which system fits?

A customer writes: "Can you move our meeting and send a confirmation?" Behind that single sentence lie three possible architectures, with very different costs, risks and limits. This article compares the three forms on the same request, without marketing jargon, to help you pick the system that fits your situation.

Three architectures, one request

The chatbot answers. It queries a knowledge base or a model and produces text: opening hours, return policy, explaining a document. It changes nothing. On our example, it can say "your meeting is on November 3 at 10 am", but it will not move the event.

The AI assistant drafts or prepares. It proposes a confirmation text, structures a request, fills in a draft. You review and approve. This is a copilot architecture: the machine produces, the human decides.

The AI agent executes. It calls tools — calendar, messaging, CRM — to carry the action through end to end, possibly without human review. It is the most powerful form and the most demanding in controls. For scoping an agent, the guide on choosing a business AI agent mission with a clear finish stresses missions with a verifiable end state, which maps directly onto our example.

What each form can and cannot do

The chatbot fails as soon as the answer depends on personal data it cannot access or on an action to perform. It can hallucinate a plausible answer if its base is incomplete. Its core limit: it makes no commitments.

The assistant limits risk because a human approves every output. Its limit is throughput: if you send fifty confirmations a day, review becomes the bottleneck. It also does not fit requests where human validation adds nothing, such as looking up a schedule.

The agent can handle the whole request, but it inherits every integration problem: permissions, API errors, intermediate states. An agent's mistake is not a badly worded sentence; it is a deleted meeting or a message sent to the wrong recipient.

The same request, three concrete treatments

Back to: "move our meeting and send a confirmation".

• Chatbot: it replies "I cannot change calendars, here is how to reach your contact". Correct answer, work not done.
• Assistant: it drafts the confirmation message with the proposed new date and prepares a draft. You check availability, adjust the tone, send it. The calendar remains your responsibility, or the assistant also prepares a change summary.
• Agent: it checks the calendar, proposes or picks a slot, modifies the event, drafts and sends the confirmation. Every step is a tool call that can fail.

The right choice depends on volume, the cost of an error and tolerance for review. A decision table follows below.

Durable state: the real dividing line

A chatbot lives inside the conversation. Once the session closes, it remembers nothing: no moved meeting, no reliable history. That is fine for isolated questions and disqualifying for customer follow-up.

An assistant produces artifacts: drafts, summaries, proposals. Those artifacts can persist in your tools, but their lifecycle stays manual. A draft forgotten in a mailbox is a commitment that was never kept.

An agent must maintain durable state: which meeting was moved, which confirmation was sent, to whom, with what content. This is where projects usually fail, not in model quality. If the agent's state and your tools' state diverge, you no longer know what was promised to the customer. The guide on making human handover work in a customer service chatbot shows the same problem from another angle: resuming a conversation requires rebuilding its context.

Managing commitments and boundaries of autonomy

"Send a confirmation" is a commitment to the customer. Any architecture that crosses that line without control must answer three questions: who authorizes the send, how you prove what was sent, and how you undo a mistake.

Take Gmail. The gmail.compose scope allows creating but also sending drafts, and scopes such as gmail.modify additionally allow direct sending. Restricting an agent to drafts therefore requires application-level controls: a scope label is not a Gmail permission boundary. In practice this means verifying on the application side that no send call is possible, rather than trusting the permission's name. The official documentation on Gmail API scopes details these access levels.

Another subtlety: a Gmail draft's identifier is stable, but the identifier of the message it contains changes when the draft is modified. If your agent stores the message identifier as proof of what was to be sent, that proof can become stale after an edit. Keep the draft identifier and a copy of the approved content.

On Calendar, you can create events with explicit identifiers, which makes tracking easier. But there is no guaranteed global transaction between Calendar and your system: if the agent modifies the event and then fails before sending the confirmation, you are in an intermediate state. Your architecture must be able to describe and repair that state; nobody else will do it.

Tools, protocols and the limits of orchestration

Connecting an agent to its tools often goes through APIs or protocols like MCP. MCP exchanges tools and context; it does not choose your business rules or permissions for you. "The agent can call this tool" and "the agent may send on behalf of the company" are two separate questions. The guide on connecting business tools via APIs and MCP details this split between technical capability and business authorization.

Also keep in mind that transport connection, provider authorization and proof of operation are three different things. A working connection proves neither that the action was authorized nor that it happened. For proof, log the operation identifiers returned by the APIs and keep them with the related content.

The messaging channel changes the rules too

If the confirmation goes out on WhatsApp, the platform adds its own constraints. The 24-hour service window is reopened by a message from the user; beyond it, approved templates are required. Platform pricing is set per delivered message, with categories and markets that vary; not all messages are paid, but the unit cost depends on context. The rules of the WhatsApp Business platform also govern compliance, permission and exit from the channel: an agent that sends messages must follow those rules, not only your business logic.

One last common confusion: a QR code displayed in an app does not prove an official connection to the Business Platform. Verify the actual channel before designing automations on top of it.

Decision table

Situation	Recommended system	Why
Frequent questions about public information	Chatbot	No action, no personal data, cheap errors
Drafting sensitive personalized replies	AI assistant	Human review catches substance errors before sending
Rescheduling with confirmation, low volume	AI assistant	The manual step is quick; an agent's mistake costs trust
Rescheduling with confirmation, high volume and clear rules	AI agent	Volume justifies automation when rules are deterministic
Calendar change with no external confirmation	Restricted agent	One tool only, verifiable state via the event identifier
Outbound messages on WhatsApp	Guarded agent	24-hour window, approved templates and per-delivered-message cost to factor in
Regulated process where every send must be justified	AI assistant	Human validation is part of the proof

When a deterministic rule beats an agent

An agent is not always the right answer. Counter-examples where a simple rule is preferable:

• Time-based routing: if the rule is "any request received after 5 pm goes out the next day", a scheduled trigger is enough. An agent would add uncertainty for nothing.
• Reliable keyword routing: if three categories cover 95% of requests (an assumption to validate on your data), a simple, explainable classifier is often enough.
• Mandatory review: if every send must be proofread for internal reasons, the agent only helps with preparation, not execution.
• Unreliable data: if the reference calendar is incomplete, an agent that "reschedules" on wrong data makes things worse.

The question to ask: does the decision involve judgment, or only execution? If it is execution with clear rules, a deterministic rule is more predictable, cheaper and easier to audit.

Procedure: choosing and framing the right system

1. Describe the request in verbs and objects: "modify a calendar event", "send a confirmation message". Each verb becomes a capability to allow or deny.
2. Classify each verb: risk-free read, reversible write, irreversible write or customer commitment. The last two call for strong controls.
3. Choose the minimal form: chatbot if reading is enough, assistant if human validation is needed, agent only when volume or the lack of review value justifies it.
4. Define the source of truth: where the truth lives (the calendar, the CRM) and how your system retrieves it. For Calendar, the documentation on creating and syncing events explains how to track changes on the service side.
5. Plan for the intermediate state: what does the system do if the event is moved but the confirmation is not sent? Write the recovery rule before go-live.
6. Test failures, not just success: tool unavailable, permission denied, wrong recipient. Acceptance of a chatbot or agent is judged on these cases; the guide on chatbot acceptance testing and handover offers a workable testing approach before launch.

Main commented example: the confirmation scenario

Here is a hypothetical scenario, built to illustrate the trade-offs. A services SME receives rescheduling requests by email. Assumed volume: about thirty per week, each confirmation error potentially costing a lost slot.

Chosen architecture: an assistant for drafting, a restricted agent for the calendar change, a human validation point before sending. Concretely: the agent checks the calendar, proposes two slots, modifies the event with an explicit identifier, then prepares a confirmation draft. The account manager reviews the draft and sends it. The proof consists of the event identifier, the draft identifier and a copy of the approved text.

Commentary on the choices. The calendar change is automated because it is reversible and verifiable: you can reopen the calendar and see the real state. Sending stays manual because it is a commitment to the customer and the volume does not justify removing review. The draft serves as a control artifact: until it is sent, nothing is committed. And if the customer replies "no, not that slot after all", the rollback targets an identifiable event, not a vague promise.

This split is not universal. With a hypothetical volume of several hundred requests per week and written rescheduling rules, sending could be automated with a reviewed control sample. With strong contractual stakes, even the calendar change could go back under human validation.

Common mistakes and what to do

• Confusing technical capability with authorization: an accessible tool is not an authorized tool. Write the list of permitted actions and enforce it on the application side.
• Trusting permission labels: as seen with Gmail, a scope name does not guarantee the expected behavior. Test what the system can actually do.
• Ignoring the intermediate state: a large share of agent incidents happen between two tool calls. Define recovery before day one of production.
• Choosing an agent by default: more autonomous does not mean better. Every degree of autonomy must be justified by volume or by the absence of review value.
• Forgetting the channel: a messaging platform's rules apply to your agent just as to a human.

To structure a first agent project with these safeguards, see how to build your first AI agent, and to weigh the intermediate forms, how to choose an AI virtual assistant.

Frequently asked questions

Can we start with a chatbot and move to an agent later?

Yes, and it is often the safest path. The chatbot teaches you which questions recur and where its knowledge base falls short. That data then helps scope an assistant or agent mission on genuinely frequent cases, rather than on assumptions.

How do we stop an agent from sending emails when it should only prepare drafts?

By combining two levels: a service account with the narrowest possible rights, and application-level controls that block any send call. Since Gmail scopes can cover several behaviors, the restriction must be proven by testing, not inferred from the permission's name.

What if the agent moved the calendar event but did not send the confirmation?

That is a classic intermediate state. Your system must detect it, expose it clearly (event moved, confirmation pending) and offer recovery: resend the draft, propose another slot, or undo the change. Without that written rule, the state stays invisible until the customer complains.

Does MCP make an agent more autonomous?

No. MCP organizes the exchange of tools and context between the model and your services; it does not define your business rules or permissions. Autonomy comes from what you decide to allow, not from the connection protocol.

Can an AI assistant be enough for customer service?

Often, yes, especially when every reply commits the company. The assistant drafts a personalized proposal, the human approves and sends; handover to an advisor remains organized for out-of-scope cases. The gain lies in the speed and quality of preparation, not in removing human control.