What Is an AI Agent? Three Analogies — Student, Train, Driver — That Explain the Core Differences

AI Agent is being hyped as the next big thing, but how is it actually different from the ChatGPT you use every day? Most people can't answer that. This article borrows a brilliant set of analogies from a Bilibili creator — student, train, driver — to clearly distinguish three easily confused concepts: large language models, AI workflows, and AI Agents. Using real task demonstrations on the Make platform, it helps you build a mental map of AI's evolution that actually sticks.

LLM: The Student Waiting for the Exam Paper

Let's start with what's most familiar. ChatGPT, Gemini, and Claude all rely on large language models (LLMs). They're excellent at generating and rewriting text — drafting emails, polishing copy, and refining language. It's worth distinguishing two things here: a model is a capability, while a chat product is that capability wrapped in an interface — and the product may additionally connect to the web, calendars, and scheduled tasks.

But a single model call with no external tools has two obvious limitations.

First, it won't automatically know information it hasn't been given. Ask it to write a coffee invitation and it'll produce something perfectly polite. But ask "when is my next appointment?" and it needs your calendar data. In Make, a single prompt asks for a coffee invitation under 45 characters and the time of the next appointment. After running, the model writes the invitation, then clearly states: "I cannot access your calendar and cannot determine when your next appointment is." The first sentence shows collaborative capability; the second shows the information boundary — an honest response from a model not connected to a calendar tool.

Second, it needs to be triggered. In a single call, if you don't send a message and no external program fires it, it won't start a new round on its own. Scheduled reminders and background monitoring need to be arranged separately by the product or program.

LLM is like sitting in an exam hall

So the first analogy emerges: an LLM is like a student sitting in an exam hall waiting for the paper to be handed out. If you don't hand over the exam (don't give a prompt), it won't start answering. And if the exam paper doesn't include a calendar, it shouldn't pass off guesses as answers.

AI Workflow: The Train on Pre-laid Tracks

So how do you let AI know your schedule? The answer is to set rules: whenever someone asks about the schedule, the program first queries an authorized calendar, passes the records to the model, and the model then organizes a response. This kind of fixed sequential process is called an AI workflow — the order of steps, which APIs to call, and where data flows are all arranged by a human in advance. It's well-suited for repetitive, rule-bound tasks.

You might not immediately notice its limitation: if only a calendar tool is configured and no weather tool is set up, asking "what's the weather like that day?" may fail — the system might throw an error or fall into a pre-set fallback branch.

The second analogy: a workflow is like a train on rails. No matter how fast the train runs or how many cars it has, it follows pre-laid tracks. You can add switches and conditional branches, but all those routes and rules are still designed by humans in advance.

Here the creator makes a key point: chaining together hundreds of steps still doesn't make something an autonomous Agent just because it's complex. The real question is whether the next step is "directly specified by fixed rules" or "autonomously chosen by the model based on goals and feedback."

RAG: Retrieve Before Answering, But Not Autonomous

It's worth clarifying a common term here — RAG (Retrieval-Augmented Generation), which in plain language means "look it up first, then answer": find relevant material, hand it to the model, then generate a grounded answer. Retrieval augmentation can improve response quality, but it doesn't inherently mean the model is autonomously choosing its actions. For example, a news copy workflow — retrieve information → model summarizes → write social media copy, launching automatically every morning at 8 a.m. — sounds smart, but all these steps may still be fully arranged by a human. If the copy isn't engaging and there's no review-and-revision step configured, you'll have to go back and manually adjust the instructions.

The core idea behind RAG (Retrieval-Augmented Generation) is to address two major weaknesses of LLMs: the knowledge cutoff date and the absence of private information. Once a model finishes training, its parameters are fixed — it can't automatically learn about events after the training data ends, nor does it know your organization's internal documents. RAG works by retrieving relevant passages from an external knowledge base (which could be a vector database, search engine, or file system) before the model answers, then passing those passages as context to the model, which synthesizes them into a response. This gives the model's answers a traceable source and relatively reduces hallucination.

Vector databases are a common retrieval backend in RAG systems: they convert text into high-dimensional numerical vectors and use similarity search to find semantically related passages rather than simple keyword matching — so even if the user's phrasing differs from the source text, relevant content can still be found. Understanding this helps explain why RAG can make a model "know" data from an internal report. However, retrieval strategy, chunk size, and the choice of embedding model all affect final quality — it's not plug-and-play.

AI Agent: The Driver Reading the Map and Choosing the Route

Now for a real-world comparison: read the Make AI Agents introduction page and organize three key points in Chinese. Both approaches use the same material and the same goal, to avoid mistaking differences in the task for differences in capability.

The fixed workflow approach connects three modules: HTTP fetch webpage → HTML-to-text extraction → AI Toolkit generates summary. A word of caution: don't just look at the connections — check where each step's input comes from and where the output goes. A connection existing doesn't mean the data mapping is correct. A wrong reference can produce a fluent but factually incorrect answer.

AI Toolkit generates summary

The key change in the Agent approach is — some action choices are handed to the model. Instead of hardcoded next steps, it can now decide based on the goal, available tools, and returned results. But this doesn't mean handing over unlimited authority: you still provide a clear goal (summarize three key points in Chinese based on a specific webpage) and supply tools along with their descriptions, and the model chooses how to retrieve the material within those tools before formulating its answer.

Agent then generates a response

The third analogy: an Agent is a driver who reads the map and picks a route based on road conditions. You give the destination and mark off-limits areas; it can choose the path, but must follow traffic rules — meaning permissions, budget caps, and stopping conditions.

Here the creator offers an extremely practical validation principle: whether tool selection actually occurred must be verified in the execution log. There's a difference between the model saying "I will look up the information" and a tool call actually appearing in the log. Don't treat a paragraph describing thought as evidence that an action was executed. In this run, "Read Make Agent Guide" did appear as a tool call in the execution log, followed by the response — only then is it proven that the information tool was genuinely used.

The concept of an Agent in AI is fundamentally defined as "perceive the environment, make a decision, execute an action, observe the result, then loop" — fundamentally different from a model call that only handles single input-output. Current mainstream LLM-based Agent architectures typically include four components: a planning module (breaking large goals into subtasks), a memory module (short-term context window plus long-term external storage), a toolset (callable external interfaces such as search, code execution, and calendar APIs), and an action execution module (actually issuing API requests or operating interfaces).

The degree of "autonomy" varies by implementation: some Agents can only choose the calling order within a preset tool list; more advanced implementations can dynamically generate code or call previously unseen APIs. Because autonomy levels vary so widely, evaluating whether a product is truly an Agent requires looking not at how polished the interface is, but at whether, in a multi-step task, the model genuinely changed its subsequent actions based on intermediate results — which is what "check the execution log" means throughout this article.

ReAct: The Loop of Reasoning and Acting

ReAct combines Reason and Act. In plain language: assess the current situation → call a tool → observe the returned result → decide the next step. The emphasis is on the loop — not on having "think" and "do" written on the interface.

When facing timeouts, empty results, or insufficient permissions, it may adapt — or it may need to stop and hand things off to a human. It cannot run indefinitely, and it must not fabricate results. A reliable implementation requires a call limit and clearly defined exit conditions.

Write-Review-Revise Loop: Giving Yourself a Demanding Editor

An Agent can also incorporate checking and revision into the task: write a first draft → call a review tool to identify problems → read the feedback and revise. The entire "write, review, revise" loop doesn't require you to copy feedback back and forth. This is the fourth picture — an author who assigns themselves a demanding editor.

The test is the review and revision

But "satisfactory" shouldn't be vague. Review criteria need to be specified: who is the reader, are terms clear, are real-life examples needed, and under what conditions can the loop end. In the actual test, the first draft read: "An AI Agent is an intelligent system goal-oriented by clear objectives that can invoke tools." The review feedback precisely noted: "lacks everyday examples, language is too abstract, needs to be more concise." The revised version immediately added examples like "helping you schedule your whole day, automatically pulling up maps and reminder tools."

One detail here deserves caution: the maps and reminders mentioned in the revision are illustrative examples in the output — they don't mean those tools were actually connected in this demonstration. When reviewing, compare the first draft, review feedback, and revised draft side by side to check whether the issues were actually fixed and whether simplifying the language changed the original meaning.

ReAct is a prompting paradigm proposed in 2022 (from the paper ReAct: Synergizing Reasoning and Acting in Language Models). Its contribution was bridging the gap between Chain-of-Thought reasoning and tool calling. Pure Chain-of-Thought lets the model reason step by step, but that reasoning stays internal and can't access external information. ReAct requires the model to explicitly output in each round: "Thought (what I'm going to do now) → Action (which tool to call, with what parameters) → Observation (what the tool returned)," then decide the next Thought based on the Observation, looping until the task is complete or a stop condition is triggered.

This visible reasoning-acting trace has two practical benefits: it makes debugging easier — developers can trace exactly where the model went wrong step by step — and it reduces hallucination risk, because the model is forced to continue reasoning only after receiving real returned results, rather than fabricating subsequent steps. The "check the execution log" emphasis throughout this article is precisely about verifying whether this Thought-Action-Observation chain genuinely occurred, rather than remaining only at the level of the model's self-description in the Thought stage.

A Simple Interface Shouldn't Hide Capability Limits

The final video retrieval example is illuminating. In Vision, entering "skier jumping in snow" returns a set of candidate clips — but the return list is just candidates, not a guaranteed correct answer. Some clips may only partially match the description, and you still need to verify the person, action, and setting.

The creator emphasizes: you can't conclude that the backend is definitely an Agent just because there's a search box. A good tool can put complex processing in the background and keep the front end simple, but users still need to know: what was the input, where did the data come from, what was actually called, and was the result verified? A simple interface shouldn't obscure capability limits.

Remember Three Questions

Back to the three analogies: the student represents a model that generates responses from input; the train represents a workflow that executes according to preset rules; the driver represents an Agent that autonomously chooses actions around a goal. And the "author and editor" picture reminds us: execution needs to be followed by checking and revision.

When you encounter a product claiming to be an Agent, ask three questions first:

What tools can it use?
Who decides the next step? (Fixed rules or the model's autonomous choice)
When results fall short, does it automatically check and adjust, or do you have to take over manually?

Looking at actual execution logs is always more useful than reading marketing copy. You set the goal; it chooses the steps, uses the tools, checks the results, and adjusts — with important actions confirmed by you. That is a true AI Agent.