AI Agents from Scratch: The Three Core Components and Four-Step Loop Explained

Many people hear the terms "Agent," "intelligent agent," and "chatbot" every day, yet never quite figure out how they differ. This piece sorts out the three most easily confused concepts in one go—from definitions to principles to classification—to help you catch up with the intelligent agent wave.

Chatbots, Agent Platforms, and Agents: Distinguishing Three Concepts First

The AI you normally use for chatting is a chatbot, not an Agent. The tools and platforms used to build agents are themselves not Agents either. A true intelligent entity that can independently run tasks and get real work done is what we call an Agent—put simply, an Agent is an intelligent being with smarts that can do work. It's not a program that just goes back and forth chatting with you; it's a computer application that can call tools on your computer and independently complete an entire complex task.

An intuitive example: you want to make a PPT from a pile of materials you have on hand. With an ordinary conversational AI like Doubao or DeepSeek^Ad, you have to upload the materials one by one, wait for it to generate everything on the server, and follow along step by step the whole time. But an Agent is different: you just toss it the requirements, and it will read the files itself, recognize the formats, and build the PPT directly on your local computer. When it's done, it will proactively notify you, and can even check the content for correctness on its own. In one sentence: large model products like Doubao and DeepSeek are more like your AI consultant—you ask, it answers; an Agent is an AI employee that directly gets its hands dirty and does the work for you.

Why Agents Can Do Work on Their Own: Three Core Components

An Agent can work independently thanks to three essential parts: a brain, memory, and tools.

Brain: The Decision-Making Center

The brain is the large language model we're all familiar with—Doubao and DeepSeek can both serve as an Agent's brain. It is responsible for understanding your needs, breaking down task steps, and deciding what to do at each step; it is the command center of the entire agent.

Memory: The Task Anchor

The memory module can remember all the requirements you stated at the very beginning, and can also track in real time which step the task has reached, so it won't drift off target as it works, and will see the whole thing through to completion.

Tools: The Core of Getting Things Done

This is the most fundamental difference between an Agent and ordinary conversational AI. An Agent can, just like a real person, call all kinds of tools and software on a computer: operating a browser to look up information, managing local files, editing Excel and PPT, and even writing code and running programs. An AI without tools can only talk theory; an Agent with tools can truly get things done.

Three Categories of Agent Products, and How Ordinary People Should Choose

Agent products are proliferating these days, and they can be grouped into three major categories. Ordinary people can choose according to their needs.

Specialized agents focus on doing just one thing well—for example, dedicated video editing, dedicated image processing, or dedicated e-commerce operations. Their advantage is precise matching to a single high-frequency scenario: simple to use, ready out of the box, and no configuration hassle.

General-purpose agents are mostly mature products launched by major companies, such as desktop agents like CoreCode and CodexWorkBody.

Platform-built agents are generated by agent-building platforms, usually with fixed workflows that let AI participate only at key nodes; most of these are customized by enterprises for their own business.

For ordinary users who want to directly use AI to boost productivity, a general-purpose agent is enough to start with.

Understanding Agents Through Hammering a Nail: Why a Model Alone Isn't Enough

If you've worked with large models before, you may have noticed an obvious problem: directly calling a large model API is basically a very simple process—you feed the model some content, the model processes it and returns a result, which is the input, model processing, output we all understand. But if you want AI to truly complete complex tasks, having the model only answer questions is not enough.

Take the example of hammering a nail. Suppose you need to drive a nail into a wall. By thinking alone you know how to do it, but by thinking alone you cannot pick up a hammer, nor can you drive the nail in. You need to execute step by step: first hold the nail in place, then take the hammer and strike, then judge whether the nail is fully driven in and how deep it went. Solving real-world problems is usually not about thinking up an answer, but about understanding the problem, making a plan, using tools, executing, observing the results, and adjusting the plan when necessary.

The design of an Agent is essentially about giving AI this kind of intelligent task-handling capability. The large model handles the core understanding and reasoning, while the Agent enables the model to keep working toward a goal.

Breaking Down the Agent System: Memory, Planning, Tools, Action

Viewing an Agent as a complete system, besides the large model as the core engine, there are several important parts: a memory module, a planning module, a tools module, and an action module.

Memory: The Division of Labor Between Short-Term and Long-Term

Suppose you have a very long conversation with an AI: in the first step you tell it your goal, in the second step you add some conditions, and in the third step you raise new requirements based on the earlier results. If the AI has no idea what happened before, the later tasks cannot continue. For tasks that require continuous multi-step execution, an Agent must retain the necessary context.

Short-term memory addresses what is happening in the current task. For example, when running an Agent during development, it stores the current conversation, task steps, and intermediate results in the current runtime environment, but after this run ends that information may no longer exist. Long-term memory addresses what has happened with this user in the past. For example, in a user-facing AI application, when the user first uses it the system records their relevant information and interaction content; the next time the user comes back, the previously saved information can be retrieved by user ID, letting the Agent know what this user has done before, what they've talked about, and whether the current task is related to earlier information.

Context Window is the upper limit on the length of text a large model can "see" in a single processing pass, usually measured in tokens (the basic unit the model uses to process text). It directly determines the boundary of short-term memory: the longer the conversation and the more intermediate results, the more tokens are consumed, and once the window is exceeded, the earliest content may be truncated or forgotten. Therefore, when actually building an Agent, context management is often needed—compressing historical conversation, keeping only key conclusions, writing intermediate results to external files or databases, and retrieving them when needed. A common way to implement long-term memory is a vector database: converting historical information into vectors for storage, then retrieving relevant content by semantic similarity. Understanding the limits of the context window helps you see why an Agent cannot rely solely on "remembering everything," but must design layered memory and retrieval mechanisms.

Planning: Breaking Tasks into Steps

Planning is where an Agent differs greatly from an ordinary question-answering system. When your boss gives you a task—help me finish an industry analysis report—you generally don't start writing the moment you get it. Instead you break it down first: determine the industry scope, collect relevant materials, analyze the collected data, organize the core conclusions, and structure it into a report. An Agent is similar: when a task is complex, it first needs to judge what steps it should be broken into, then execute them step by step.

In Agent research and practice, many different planning approaches have emerged, such as Chain-of-Thought, Tree-of-Thoughts, and runtime approaches like ReAct. These methods don't solve exactly the same problems, but their core goal is similar: to make the model not just consider the final answer, but reason and make decisions around the task more systematically.

Planning is also not something done once and set in stone. Suppose you planned five steps earlier, and when you reach step three you find the actual result differs from expectations—if you keep executing the original plan, subsequent steps may fail in a chain reaction. So an Agent also needs the ability to adaptively adjust and re-plan based on execution results.

ReAct is short for "Reasoning + Acting." Its core idea is to let the model alternate between reasoning and action: first output a piece of thinking (what needs to be solved now, what to do next), then perform an action (call some tool), then read the observation returned by the tool, and use that to start the next round of thinking. It differs from Chain-of-Thought (which only does internal reasoning without touching the external environment) and Tree-of-Thoughts (which explores multiple reasoning branches simultaneously and picks the best) in that ReAct incorporates external feedback into the reasoning process, making it better suited to tasks that require interaction with the real environment. Chain-of-Thought improves accuracy on complex problems by guiding the model to reason step by step; Tree-of-Thoughts lets the model generate multiple lines of thinking and choose the better path after evaluation. The three can be combined: first plan the overall steps, then use ReAct to execute step by step and correct course.

Tools: The Bridge to the Real World

A large model does not inherently have the ability to connect to the outside. If you ask it what the weather is like today, and the model has no real-time internet capability, it can only answer based on pre-training data. But if you give it access to real-time APIs—weather, stocks, flights—it can obtain real-time information through these API services. That is the role of tools.

There are many similar tools: calculators, code execution, search tools, and APIs provided by various business systems. Tools are responsible for connecting the large model to the external world; the model is responsible for judging what capability is needed right now and calling the corresponding tool. For example, if the model determines it needs to check the weather, it calls the weather API; after the API returns results, the model completes subsequent tasks based on those results. A large model that could originally only generate text thus gains the ability to process external information and perform concrete operations.

API (Application Programming Interface) is an agreed-upon "conversation rule" between software: one party sends a request in a fixed format, and the other returns data according to the agreement. Take weather as an example: an Agent doesn't just "browse the internet randomly"; it sends a request containing parameters such as city and time to an API provided by a weather service provider, and the other party returns structured data such as temperature, humidity, and precipitation probability. The value of an API lies in encapsulating the capabilities of the external world into stable, repeatedly callable interfaces. The model only needs to know "what tools are available and what parameters to pass" to call them precisely when needed. Besides weather, stock quotes, map routes, flight status, and internal enterprise order and inventory systems are usually exposed as APIs. Understanding APIs is a prerequisite for understanding the Agent's tools module: tools are essentially a set of APIs or local functions that the model can select and call.

The Action and Decision Loop: The Agent's Most Core Mode of Operation

With memory, planning, and tools in place, there is still a very critical part—action. An Agent's ultimate purpose is not to make plans but to complete the task. When it plans step one to search for materials, step two to organize data, step three to run code, and step four to generate results, each step needs to be actually executed.

So an Agent is a loop system, and its core process is: perceive, plan, act, observe. This is also an important core process of the ReAct execution framework.

• Perceive: What problem is being faced? Input must be obtained from the external environment, and this information is then handed to the large model for understanding.
• Plan: The model judges, based on the current task, how to solve it, how many steps to split it into, and what to do next.
• Act: The Agent performs concrete operations according to the plan, possibly generating content directly or calling some tool or API to get an execution result.
• Observe: Judge how the execution result just obtained actually turned out.

The observation part is very important, because it is a key difference between an Agent and a simple workflow. Suppose the Agent originally planned to execute five steps, and executing the first step yields a result—but that result is not necessarily correct. Only if the result meets expectations can the Agent continue to the next step; if it doesn't, it needs to judge where the problem lies, whether the execution plan needs adjustment, and whether the steps need to be modified. This forms a new loop—perceive, plan, act, observe again—until the task is finally completed.

An Agent is not simply about stringing APIs together; more importantly, it can continuously adjust its execution based on environmental feedback. This is also why, when designing an Agent, you shouldn't focus only on the large model's performance but also on memory, planning, tools, and the action loop.

The Real Difficulty of Deploying Agents: First Judge Whether the Task Needs an Agent

Putting it all together: the large model is the core engine, memory is responsible for saving the context and historical information needed for the task, planning is responsible for thinking about how to break down and execute the task, tools give it the ability to connect to the outside, action is responsible for actually executing the steps, and then through perceive, plan, act, observe it loops continuously.

In actual development, different tasks suit different planning approaches. Simple tasks may not need a complex Agent at all—they have fixed processes, and an ordinary workflow may be more stable; dynamic decision-making tasks are always changing and need steps to be continuously adjusted based on feedback, and that is when an Agent is needed.

So the first question when building an Agent is not what technology to choose, but whether the current business task actually needs an Agent, and if so, what kind of planning and decision-making approach to choose. This is also what you need to focus on understanding as you go on to learn Agent task decomposition, reflection, and re-planning.

To summarize: the core of an Agent is not just letting a large model answer questions, but letting the large model, around a goal, have the ability to understand the task, make plans, call tools, execute actions, and continuously adjust based on results. Once you understand this logic, when you go on to learn Agent frameworks, tools, and planning approaches, it will be easier to see how they actually execute and what problems they each solve.

You can judge whether a task needs an Agent from three dimensions. Process determinism: if the order and decision rules of every step are fixed, a traditional workflow or script is more stable and lower cost, and the model only needs to intervene at individual points. Need for environmental interaction: whether the task needs to frequently read external information, call multiple systems, and change the next action based on returned results—this kind of dynamic decision-making in an open environment is where an Agent shines. Fault tolerance and cost: an Agent's looping calls bring higher latency and token consumption, and mechanisms such as failure retries and human confirmation also need to be designed; scenarios with extremely high accuracy requirements that are hard to verify should be evaluated cautiously. A practical way to judge is to first ask "if the model is not allowed to decide autonomously, can the task be completed?" If it can, prioritize a workflow; only when the task path cannot be hard-coded in advance and must rely on runtime feedback should you introduce an Agent.