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

A chat window that leaves HubSpot, Linear, and the repo unchanged is a chatbot, whatever the deck called it. I look at the record after the run, not the paragraph.

If nothing mutated, I did not ship an agent. I shipped a useful reply, which is a different product.

A chatbot answers a message and waits. An agent is given a job, uses tools, and writes a change into a system of record. If HubSpot, Linear, the ledger, or the repo look the same after the run, you shipped a useful reply, not the same product.

Chatbot replies, agent changes a system of record

The difference is the side effect. Chat returns tokens to a person. An agent returns a mutation to a field, a file, a ticket, or a ledger line, and if a person still has to copy the answer into the record, the software did not finish the job.

Say you ask, “What is the status of ACME?” A chatbot reads whatever context you pasted and writes a paragraph: they are in negotiation, next step is a pricing call. You then open HubSpot and type that in.

You were the integration: the model never touched the object.

An agent gets a different job: qualify ACME, write stage and next step to the deal, stop when the record matches the last call notes. It searches mail, reads the CRM, patches the deal, and stops.

The test is not whether the prose sounded sure. The test is whether the deal object changed.

I use the same test on mail. Software that summarizes an inbox in a window is a chatbot. Software that files a one-page brief and archives the junk is an inbox agent.

The mailbox is the system of record, so if the unread pile is identical after the run, it only talked.

Ops is the same shape. A window that explains how to post a journal entry is a chatbot. Software that posts the entry, with a cap on spend and a log of the write, is an ops agent.

The ledger is the record. If the ledger is untouched, you still have chat.

GitHub’s Copilot documentation draws this line in public. Copilot Chat in the editor answers “what does this function do.” That is a reply.

Copilot coding agent, described in GitHub’s docs and in the GitHub Blog on 19 May 2025, takes an assigned issue, works in the background, and opens a pull request. The pull request is a write to the repo: chat explains, the coding agent mutates the record.

I wrote what an AI agent is as the definition. This page is the fork: when that definition fails, you usually have a chatbot, and you should keep it.

Do not stretch the word until every text box is an agent. You will buy a loop you do not need, and you will skip the write you do need.

Chatbot vs funnel vs agent

Three shapes sit on the same desk and get sold as one word. A chatbot talks. A funnel follows a path you drew, while an agent chooses tools toward a finish line and writes the result, and mixing them is how first contact turns into spam with an empty CRM.

A funnel is not a failed agent. It is a workflow you already understand. Manychat, a WhatsApp tree, Typebot, a Zap that fires when a form lands: trigger, branches, a last step.

The CRM can change. The change was mapped by a person. Anthropic would call that a workflow, not an agent.

I call it a funnel when it lives in chat, and a script when it lives in Zapier. Same shape.

The funnel is the right tool for capture. First contact should be boring: a lead magnet, a name, a slot on a calendar. If you can draw every branch on a whiteboard, draw it.

Putting a model in charge of first contact, with send permission and no eval, is how a list gets six unsolicited messages. That is a reputation problem, not an agent.

The agent starts after the path runs out. The lead exists, the ticket is open, the issue is assigned, and you cannot draw every search and exception. You can still write what done looks like: deal stage updated, ticket closed with a comment, pull request opened, brief in the folder, and that is when a model should choose tools.

Teams blur the three because the UI is the same rectangle: chat window, WhatsApp thread, Slack. The rectangle is not the product.

The product is whether the next step is a person, a graph, or a model with a short tool list. If you cannot say which, you will buy the agent SKU and run a funnel inside it.

What Anthropic split in 2024

In December 2024 Anthropic split workflows from agents. A workflow is a path you already know. An agent is a model that directs its own tool use, and most teams still need the path, so use an agent when you cannot draw it and you can still write what done looks like.

That is from Anthropic’s Building effective agents, published 19 December 2024. I keep it next to the keyboard because vendors collapse the two on purpose.

A prompt chain that always outlines, then drafts, then translates is a workflow. A loop that searches, reads a tool result, decides the next call, and stops on a done condition is an agent. Both can write to a record, and only the second chooses the path.

r/LocalLLaMA ran an agent-versus-workflow quiz on 8 Jul 2025. The poster said 150 people voted and still split on the line. That is a thread, not a measurement I ran.

The same essay is blunt about when not to bother. “When building applications with LLMs, we recommend finding the simplest solution possible, and only increasing complexity when needed. This might mean not building agentic systems at all.”

For many jobs, they say, a single model call with retrieval and in-context examples is enough. I have watched teams skip that sentence and jump to a swarm.

Anthropic also names the trade: agentic systems often trade latency and cost for better task performance. A chatbot round trip is one call. An agent that searches mail, reads three threads, writes a file, and archives junk is many calls, many tools, and many ways to stall.

You pay that tax when the path cannot be drawn, not to answer “what are your hours.”

When more complexity is warranted, they put workflows on well-defined tasks and agents on work that needs model-driven decisions at scale. The autonomous agent is the last pattern, and they attach a warning: trust, stopping conditions, and ground truth from tool results at each step, not a vibe.

Their customer-support example is the chatbot-to-agent fork in one desk. Support already looks like chat. It becomes an agent when tools pull order history and the loop can issue a refund or update a ticket.

Success is a resolved case, not a nicer paragraph. Their coding example is the same test: the agent iterates against tests, and the tests are the system of record for whether the change works.

When OpenAI says skip the Agents SDK

OpenAI Agents SDK documentation (2026) defines agents as applications that plan, call tools, collaborate across specialists, and keep enough state to complete multi-step work. Use the Responses API when the work is short-lived and the output is the model’s reply. Use the Agents SDK when you want the runtime to manage turns, tools, guardrails, handoffs, or artifacts across steps.

If you are building a chatbot, do not import the agent runtime. The production shape I want is a chatbot on the public FAQ and an agent on the back-office write, not one SDK wrapping both.

When I do use an agent runtime, I still keep the tool list short. Tool calling is the contract: named functions, a schema, a result the next step can use.

OpenAI will run that loop for you. Anthropic will too. Neither vendor can save you if “done” is “keep chatting until it feels finished.” The SDK will happily spend until you cap it.

The loop, not the window

The same model can sit behind a chatbot and behind an agent. Model size is not the product. The product is whether a runtime can call tools, read what came back, and stop when a record has changed, so a bigger model in a chat window is still a chatbot.

ChatGPT in a browser is a chatbot. It becomes agent-shaped only when it can call tools across steps and stop on a done condition you wrote.

A widget on your site that answers “how do I reset my password” is a chatbot even if the model is the same one that, in another process, opens pull requests. I do not grade the logo. I grade the loop.

The loop is boring on purpose. Goal in, model thinks, runtime executes a named tool, result comes back as fact: not found, denied, timeout, or the record. Then it thinks again until the finish line, the budget, or a forbidden call.

I described that job in what an AI agent is. The chatbot loop is shorter: message in, tokens out, wait.

People like to keep the chat UI, and that is fine. Operators already live in Slack and WhatsApp. The window can stay if the runtime behind it can write.

What cannot stay is the habit of treating every turn as a new prompt from a person. If you still type the next instruction after every reply, you have a slow assistant, not an agent.

A runtime that cannot stop is a chatbot with a bill. Caps on steps and spend belong in code, not in the prompt. The model does not get a vote on the budget, which is why I refuse to let it own the loop.

Retries, memory, permissions, and the stop rule live in the runtime so a dropped connection is not a double charge.

If you want people out of every click, the record has to be machine-checkable. I wrote how to run AI agents without a human for that edge: people set the goal and the grants, then review the score.

They do not sit inside the trace. A chatbot wants them in every turn. That is correct for a conversation and incorrect for a write you already know how to test.

When a chatbot is the right tool

Use a chatbot when the work is a conversation: support, FAQ, a guided form. The person is in every turn on purpose. A good reply is the artifact, and spending an agent loop on a path you already drew burns latency and money for a worse version of a script.

Hours, pricing pages, “where is my order” when the answer is a tracking link you can retrieve in one call: that is chat or a single function call. Anthropic’s 2024 essay says the same thing: optimize the single call, add retrieval if the answer lives in a corpus, and do not stand up a planner.

A guided form can look like chat and still not be an agent. “What’s your company size, what’s your stack, book a slot.” If every branch is known, a funnel or a form is kinder than a model that improvises.

Improvisation on first contact is how you get a tone that does not match the brand and a booking in the wrong timezone.

Internal chat is often the right tool too. A teammate pastes a contract and asks for a summary, and the artifact is the summary in the thread. Forcing that into an agent adds tools and a chance it files the summary in the wrong folder.

Classification, extraction, translation, a draft a person will edit: OpenAI’s Responses path. Short-lived. Output is the model’s response.

I have watched teams wrap each of those in an “agent” class so the architecture diagram looks current, then debug a loop that should never have started. If there are no tools and one call, it is a prompt. Call it a prompt.

Use a chatbot when you cannot write a finish line a script can see. “Help me think about positioning” has no record, so an agent will wander, call search, and spend. A person in the thread is the correct control.

Agents need a done condition. Conversations need a person.

When an agent is the right tool

Use an agent when the job has a finish line you can test and a system of record that must change. Inbox to closed ticket, research to a filed brief, issue to a pull request, ops that post, book, or close. If you cannot name the write, you do not have an agent yet.

The inbox job is the one I run most: forty vendor emails, a brief in a folder, junk archived. A chatbot that lists the same forty emails has not started.

Ops is the write people are afraid of, which is why they leave it as chat. “Draft the journal entry” is a chatbot. “Post the journal entry to the ledger, idempotent, with a dry run first, stop when the id exists” is an ops agent.

Search is not post, and draft is not send, so split the grants. An agent that can read the inbox should not also wire money.

Code is the cleanest public example because the record is obvious. If your “coding agent” only pastes a snippet into the sidebar, you built a chatbot and named it wrong.

Research only becomes an agent when the brief lands. “Look into these three vendors” is a prompt. “Write /out/brief.pdf with sources, and stop” is a job.

The file is the record. If the output is a long thread you will never read twice, you paid for chat. File it or do not call it an agent.

Anthropic’s 2024 test still holds: agents fit open-ended work where you cannot predict the number of steps, and where you can still stop. You need trust, sandboxes, and guardrails.

I add one more: you need a system of record whose new state a script can see. Without that, you will keep a person in the loop forever, which means you built a chatbot with extra tools.

Chat funnels and first contact

A Manychat or WhatsApp flow that DMs a lead magnet is a script that captures a name, and it should stay a script. Putting an open-ended agent on first contact, without eval, is how you spam a list and call it AI. Capture and completion are different jobs.

I am not against chat as a capture surface. Instagram, WhatsApp, a site widget: people already write there. The funnel should stay a funnel.

Trigger on the keyword, send the PDF, ask for the email, and write the row to the CRM on a mapped field. That write is real: it was not chosen by a model, it was drawn on Tuesday.

The failure I see is swapping the graph for a model because the model is better at small talk. Small talk on first contact, with a send tool, is a reputation problem.

The model will follow up, then follow up again, then apologize for following up, and you will not see it until a prospect forwards the thread. Eval would have caught the double send. Most capture stacks have no eval.

After the lead exists, an agent can earn the next tools: research the company, qualify against a rubric, patch the CRM, book the slot, draft the follow-up and wait for a grant to send. That is completion. It is a different permission set than the public widget.

I do not give the capture surface the keys to send, spend, or deploy.

If a Zap would do, write the Zap. Anthropic’s simplest-solution rule is not aesthetic. Agentic systems cost more per task and fail in longer traces.

A lead magnet does not need a planner. It needs a path that always files the name. Save the model for the hour after the name exists, when the path forks in ways you cannot draw.

Can a chatbot become an agent?

A chatbot can become an agent if you add tools, a runtime that owns the loop, a stop rule, and a score on the record. The chat UI can stay, because people like chatting, but the window is not the product and the shipped write is. Without those four pieces you still have a chatbot with extra buttons.

Start with the finish line, not the widget. “Close this ticket with a comment the customer can see, and tag it refund-issued.” Then name the tools: get_order, issue_refund, comment_ticket.

Then put a runtime around the model so retries, spend, and stop are not a prompt. Then freeze a set of tickets you already know and score whether the ticket state changed. I walk that order in how to put an AI agent in production.

Keep the chat window if operators will type the job there. Slack is a fine inbox for a goal. It is a bad place to hide the tool log.

After the run I read the trace, not the clever recap. If you only keep the final message, you will not see the double refund.

Evaluating AI agents means scoring the artifact. A beautiful explanation of a missing write is still a miss.

Do not bolt thirty tools onto the old FAQ bot and call it a promotion. Extra tools are how it wanders. Search is not send, and read is not deploy.

Split into specialists only when one worker would hold keys that should never sit together. Until then, one agent, one short list, one record.

OpenAI’s 2026 guidance is the same promotion test. If you still only need a response, stay on Responses. If you now need the runtime to manage turns, tools, guardrails, and artifacts across steps, pick up the Agents SDK or any runtime that can kill a runaway trace.

How I tell which one I have

I do not grade the thread. I look at the record after the run. If I still typed the next instruction I built a chatbot, and if the software left, used tools, and came back with a changed ticket, a filed PDF, or a pull request, I built an agent.

1. 01

   Name the write

   Say the object and the field: deal stage in HubSpot, ticket status in Linear, file in /out, pull request on the branch. If you cannot name the write, you have a conversation. Keep the chatbot.

2. 02

   Watch who types next

   After the first reply, who acts. If it is you, you have a chatbot. If the runtime calls a tool without a new prompt from you, you have a loop, and a loop without a stop rule is still not an agent you can ship.

3. 03

   Count the tools

   Zero tools is a chatbot, and one retrieval call plus a reply is still close to chat. A short list that includes a write, with search separate from send, is agent-shaped. Thirty tools is a wanderer.

4. 04

   Look at the record

   Run it once on a job you already know, then open the CRM, the ticket, the folder, the repo. If the state is the same, the software talked. Pretty traces that miss the file are zeros.

5. 05

   Ask if a script would do

   If you can draw the path on a whiteboard, draw it. Anthropic’s 2024 advice is to start simple, and OpenAI’s 2026 advice is to skip the Agents SDK when you only need a response. I follow both before I add a planner.

Vendors will keep calling every window an agent. The ticket, the file, and the pull request do not.

I ship a chatbot when the work is a conversation, a funnel when the path is already drawn, and an agent when a system of record has to change and I cannot draw every step.

That is the split I use on every desk.