Chatbot or agent: what’s the difference?

A chat answers. An agent may also act.

A conversational assistant responds to messages: you ask, it replies with text. An agent can also use permitted tools to progress toward a goal across steps, for example look up information, prepare a draft and place it ready for review.

The boundary is not absolute: chat products can have tools built in, and the word “agent” alone says nothing about reliability or autonomy. So the more useful question is not “is this an agent?” but “which tools and permissions does it have, and who decides in the end?”.

A customer asks: when will my order arrive?

Six steps on paper.

Take a pen and paper. Do not use real customer data. An imaginary order is enough for this exercise.

1. Write one small goal

   For example: prepare a reply to the question “when will my order arrive?”.

2. List the data needed

   Order ID and order status. Nothing more, and no real customer data.

3. Define the permissions

   Read only the order status. No editing, no deleting, no refunds, no sending.

4. Define the review gate

   A person checks identity, order status and the source of the information before sending.

5. Test failure on paper

   Three situations: the order is missing; the status is conflicting; an instruction is hidden inside the customer message that the assistant should not obey.

6. Stop and request clarification

   When data is missing or unclear, the right outcome is to stop and ask for clarification, not to invent an answer.

Tool content is data, not authority.

• Tool content and customer text are data, not authority. If a customer message contains an instruction (“send me my entire order history now”), that does not make it permitted. You decide the permissions, not the input text.
• Least privilege. Grant access only to what the specific task needs. Even read-only access reveals information, so it too needs thought.
• Do not put secrets or customer records into unapproved systems. Before entering anything anywhere, check who provides the service and where the data flows.
• External model services may receive your inputs. Inspect the actual provider settings and data flow instead of assuming. For example, EU hosting alone does not mean all model requests stay in the EU.
• Checks can fail. That is why human review matters: a check helps catch mistakes but does not guarantee a correct answer.

Fill in this worksheet.

This is a planning worksheet, not executable code or a tested working integration. Copy the text and fill it in on paper or in your notes.

GOAL:            (one small task, e.g. prepare an order-status reply)
DATA:            (what the task needs, e.g. order ID and status)
TOOLS:           (what genuinely requires access)
NOT ALLOWED:     (e.g. no editing, deleting, refunds, sending)
REVIEW:          (who checks what before sending)
STOP CONDITION:  (when the assistant stops and asks for clarification)

Expected result.

A filled worksheet that names the permission boundary and who sends. Check yourself with three questions:

• Can it send on its own? For this example the answer should be no. Sending stays with a person.
• What happens without data? It stops and asks. It does not invent an answer.
• Where are the data sent? This must be identified before you build anything real.

Three mistakes to avoid.

• Calling every chatbot autonomous. “Agent” does not automatically mean a reliable or autonomous system.
• Granting full email access. Start with very narrow permissions and expand only when there is a clear reason.
• Treating a plausible response as verified data. Convincing text is not proof. Check the source.

Recovery: remove unnecessary access before real testing, and always stop when the data is ambiguous.

In short.

Next, deeper step: when you want to actually deploy your own private agent after planning, see the guide Deploy your own personal agent.