Chatbots and agents

These days all we talk about are AI agents. So let’s define the term.

A chatbot receives a message and returns a response. Then it stops. An agent can take actions to reach a goal. It reads files, runs commands, checks the result, and keeps going until the job is done or it gets stuck.

Anthropic has the simplest definition I know: agents are models using tools in a loop.

The two ingredients

You have a model, the brain. Claude, GPT, Gemini. It understands your request, plans what to do, and writes text.

And you have tools. A tool is a capability the model can ask for, to interact with the world beyond generating text. For example:

• file system: read, write, and edit files in your project
• terminal: run commands, install packages, start servers
• browser: open pages, click around, read what’s on screen
• APIs: talk to a database, a deployment platform, a search engine
• MCP servers: reach specialized tools and data sources through the Model Context Protocol

Every coding tool you’ll use, from Claude Code to Cursor to Codex, is an agent in this sense.

The model does not own the tools

This is an important detail. The model doesn’t run anything. It proposes a tool call: read this file, run this test. The host application checks the request, applies your permissions, runs the tool, and hands the result back to the model.

So the model doesn’t have your filesystem or your accounts. The application around it decides which capabilities exist and which ones need your approval.

Where the line is

The boundary between chatbot and agent isn’t sharp. A chatbot may search the web once. An agent may stop after one tool call. What matters is how much of the sequence the system chooses and executes without you naming every step.

Compare:

Explain why this date test is failing.

Fix the failing date test and verify the change.

The first can end with an explanation. The second needs to read files, run a command, edit code, and run the test again. It also needs permission to change your repository.

A practical example

Say you ask: Create a small React app with a todo list and deploy it.

Without an agent, the chatbot writes code snippets in the chat. You paste them into files. You run the commands. You fix the errors. You deploy.

With an agent, it goes like this:

1. write_file creates package.json, App.jsx, index.html
2. run_command runs npm install
3. run_command starts the dev server
4. it reads the console output and sees an error
5. edit_file fixes the bug
6. run_command restarts the server, now clean
7. run_command runs the deploy command
8. it reports the live URL to you

You gave one instruction. The agent handled the whole workflow, including a mistake it made along the way.

More autonomy, bigger blast radius

Explaining how to send an email changes nothing. Drafting one creates text you can review. Sending one reaches another person, and you can’t take it back.

As agents get more autonomy, pay attention to which tools they have, what permissions those tools carry, where you approve, how much they can spend, when they stop, and how they verify. Autonomy doesn’t remove your responsibility. It makes the boundaries more important.

Take one task you’d normally give a chatbot and rewrite it as an agent task. List every extra tool, permission, side effect, and check the agent would need. That list is the rest of this module.