Class 28 gave you the agent formula: model plus instructions plus tools plus memory plus an execution loop equals an agent. That formula is useful, but it leaves a practical question unanswered. When you open ChatGPT, Claude, or Gemini and get a good answer, was that an agent?

This lesson draws the line cleanly — so you stop paying agent prices and agent attention for work a simple chat could have done.

Two different shapes

A chatbot conversation and an agent run have different shapes. Learn the shapes and you can classify almost any AI feature in seconds.

A chatbot works like this:

question → model → answer

You ask. The model reads the conversation so far, generates a response, and stops. Even in a long back-and-forth, each turn follows the same pattern: your message restarts the work, and the model answers from what it knows plus what is in context. Nothing happens between your messages. Nothing is remembered outside the conversation unless some other system saves it.

An agent works like this:

goal → tool → observation → next decision → result

You (or a schedule, or an event) give it a goal. The agent takes an action through a tool, looks at what came back, updates its state, and decides whether more work is needed. It can run several steps without you typing anything. It leaves a trail: tool calls, observations, saved records, a stop reason.

The difference is not how smart the words sound. A chatbot can sound brilliant and still be a chatbot. The difference is whether the system can act, observe the result, and decide what to do next on its own — and whether that progress survives after the chat ends.

"Agent" is not a gold star

Marketing has made "agent" sound like a promotion. Basic chatbot, premium agent. That framing will cost you money and mislead your designs.

A chatbot can be extremely useful without being an agent. Debugging help, explanations, brainstorming, drafting from material you paste in, summarizing a document you supplied — these are high-value tasks, and they fit the question-to-answer shape perfectly. Calling them "agents" adds nothing except confusion about who did what and where the result lives.

Reserve the word "agent" for systems that actually carry work forward: they use tools, keep state, loop, and stop according to a rule. If a feature cannot call a tool, cannot continue without your next message, and holds no durable record of progress, it is chat — even if it is excellent chat. Name it honestly and you will choose simpler, cheaper, more debuggable designs, which Lesson 29.3 makes into a habit.

Two examples, side by side

Example 1: Explain a SQL error (chat).

You paste an error message and the query that caused it:

The model explains that the table uses customer_id, suggests the corrected WHERE clause, and notes how to check column names with \d orders. One turn, one answer, no tools needed. If you want, you paste the next error. This is the ideal chatbot job: bounded knowledge, no outside action, no state worth keeping beyond the conversation.

Example 2: Gather evidence, record it, request review (agent).

Now the job is bigger: "Each morning, check our three approved supplier-price sources, record any change over 5%, and queue a review packet." That cannot fit in one answer. The system must load its source list and yesterday's prices (state), call a search or fetch tool for each source, compare the observations against the threshold (decision), write new records to a file or database, and either stop with "no material change" or produce a packet for a human to review. It runs without you chatting, and its value is the carried-forward record — not any single sentence.

Notice the test: in Example 1, if you close the chat, nothing is lost except a transcript. In Example 2, closing a chat window should change nothing, because the run lives in jobs, logs, and records. That durability is the point of state from Class 28, and it is what the next two lessons build on.

Why the distinction changes your decisions

Three practical consequences follow.

First, cost and latency. A chat turn calls the model once. An agent run may call the model and several tools many times. If the job fits in one turn, an agent loop is pure overhead.

Second, debugging. When chat gives a wrong answer, you rephrase and retry. When an agent fails on step four of seven, you need the run record: which tool was called with which inputs, what came back, and why the agent continued. No record, no diagnosis.

Third, responsibility. A chat answer advises; you decide what to do with it. An agent run can draft records, queue messages, or propose changes that other systems consume. That is why every agent needs a named owner and a stop-or-review rule — ideas Class 30 turns into budgets and gates.

Exercise: label five familiar AI features

Take five AI features you have actually used — autocomplete in an editor, a support chatbot, a "summarize this page" button, a scheduled price alert, a coding assistant that edits files. For each, write one line:

• Chat, workflow, connector, or agent? (You will sharpen the middle two terms in Lessons 29.2 and 29.3; for now, "not-chat-and-not-agent" is an acceptable middle bucket.)
• One-sentence justification naming who starts it, whether it uses tools, and whether anything persists after the turn.

Finish line: a five-line list in a note or file, each line with a label and a justification.

Verify: for every item you labeled "agent," point to the tool, the state, and the stop condition. If you cannot name all three, relabel it.

Common failure mode: labeling anything impressive as an agent. Fluency is not agency. Check the mechanism, not the tone.

Check your understanding

1. A friend says, "This chatbot is so good it must be an agent." What two questions do you ask to test the claim? 2. Why does an agent run need a saved record even if the model's context window is very large? 3. Which shape fits "explain this error message": question-to-answer or goal-to-observation-to-decision? Why?

Next

Chat tells you something. An agent carries something forward. But there is a middle case that confuses almost everyone: a chat window with connected tools — drive search, calendar lookup, a permitted write action. It looks like an agent and sometimes acts like one. Lesson 29.2 shows why a connector is a capability, not automatically an agent, and gives you three questions to tell them apart.