AI Agents Aren't Chat Boxes: Breaking Down the Plan-Tool-Read-Decide Loop

Many people imagine an AI Agent as a smarter chatbot, as if it were born able to remember context and complete tasks automatically. But after watching this breakdown from the "One AI Concept a Day" series, it becomes clear: the essence of an Agent is not a more powerful model, but a four-step loop that repeats endlessly—Plan, Tool, Read, Decide.

The video runs this chain through a real workspace task, and every file size shown on screen is in actual bytes. This "reproducible" demonstration style precisely illustrates the fundamental difference between an Agent and ordinary conversation: its capability comes from the loop, not from memory.

A Small 18KB Task That Ran Two Loops

The task goal is very specific: is there a report.pdf in the workspace? If so, report its file size. The folder actually contains three files—notes.txt, report.pdf, and data.csv—but the Agent can't see them at first; it only has the goal.

The first step is planning. The model breaks the goal into callable tools: first perform a directory listing on the workspace to confirm which files exist; if report.pdf appears, then call a function to get its size; finally answer "yes/no" plus the specific byte count. This step executes no tools, just lists a short checklist.

The second step is calling a tool, executing a directory listing on the workspace path. The runtime actually executes the function, taking about one millisecond—that moment of waiting is the Agent working outside the chat box.

The third step is reading. The tool result is pasted back into the conversation: besides report.pdf, there are two distractor files. The file does exist, but the byte count is still unknown—information is incomplete. The loop doesn't stop; it decides to call again—this time getting the size of report.pdf, which returns 18,448 bytes, about 18KB.

The fourth step is deciding: has the goal been achieved? Yes, so it outputs "yes, 18KB" and stops. The whole process involved one plan, two tool calls, two reads, and one final decision.

There's an easily overlooked insight here: one tool call is usually not enough. A single call only gets partial information, and the Agent's value lies precisely in judging "what's still missing" based on incomplete information, then continuing to the next round. Larger tasks are just the same four steps run more times.

Function Calling / Tool Calling is the technical foundation that makes this loop work. It means that when generating a response, the model doesn't directly output natural language but instead outputs a structured call request, such as {"name": "list_directory", "arguments": {"path": "/workspace"}}. The model itself doesn't execute any code; what actually executes is the host application (the runtime): the application parses this request, calls the corresponding function, serializes the return value as JSON, and splices it back into the conversation history, so the model can "see" the result and continue reasoning. Therefore, the Agent's capability boundary is largely determined by the set of tools exposed to the model—the granularity of tools, parameter design, and return format directly affect whether the model can make correct decisions. This is why practice emphasizes "least privilege": the fewer tools exposed, the smaller the model's search space for trial and error, and the easier the loop converges.

Runtime and Sandbox is another easily confused concept. Runtime refers to the external program that hosts the Agent loop; it is responsible for scheduling the model, executing tools, maintaining conversation state, and imposing stopping conditions. The sandbox is the isolation boundary the runtime defines for tool execution, restricting file system access scope, network egress, and system calls. Only when the two work together can the "call tool" step be both real and controllable. The "about one millisecond" mentioned in the article is exactly the time the runtime spends executing the function—this latency occurs outside the model and is an intuitive signal of whether the Agent is truly "doing work."

The Same Loop Is Hidden in Products You Use Every Day

This four-step loop is not proprietary to any single product; it appears in the implementations of multiple mainstream tools.

Claude Code's form is: plan a modification, call a shell or file tool, read the output, then decide whether to edit further or stop. According to Forrest Cherney's description, early versions used RAG and later shifted to agentic search—using search, glob, and grep to search within the loop rather than relying on vector indexes.

Codex presents the same structure in a shell session: call tools, append results, make decisions. It runs commands like ripgrep and iterates continuously until the task criteria appear to be satisfied.

ChatGPT's tool calling is the chat form of this loop: the model issues a function call, your application executes it, returns the JSON result, and the model reads it and either calls again or answers the user directly.

The interfaces differ, but the mechanism is completely identical. The video deliberately labels the diagrams as "illustrative," but emphasizes that the mechanism itself is real.

The difference between RAG (Retrieval-Augmented Generation) and agentic search deserves elaboration. The typical RAG approach is to pre-chunk documents, embed them as vectors, and store them in a vector database; when a user asks a question, it first performs similarity retrieval, stuffs the top-k snippets into the context, and then lets the model answer. It is one-time, static retrieval; retrieval quality depends on the chunking strategy and embedding model, and the model cannot ask afterward, "Is there anything else?" Agentic search, by contrast, turns retrieval itself into a tool call within the loop: the model actively initiates search, glob, and grep, sees the results, judges whether the information is sufficient, and if not, changes keywords or narrows the path and searches again. The cost is more rounds and higher latency; the benefit is handling vague, multi-hop queries that require gradual focus. Claude Code's shift from RAG to agentic search essentially moves "retrieval" from the preprocessing stage into the decision loop, letting the model decide what to search and how many times.

ripgrep is a search tool commonly used by coding Agents such as Codex. Written in Rust, it can quickly perform regex matching in large codebases, respects .gitignore by default, and automatically skips binary files. Compared with traversal-based search, it returns results in milliseconds, making the high-frequency "search—read—search again" loop feasible in terms of latency. The speed of a tool often determines how many rounds the loop can run.

Five Typical Traps That Get Agents Stuck

Once you understand the loop, you can understand why Agents fail. The video lists several high-frequency problems worth checking one by one.

Infinite tool loop. Without a stopping rule, the Agent keeps calling tools and consuming tokens, never considering itself done. This is the most common form of loss of control.

Blindly trusting tool output. Tools may return errors, failures, or stale data; reading is not verification.

Lack of a sandbox. A loop that can delete files at will and access the network without restriction isn't smart—it's dangerous.

Vague goals. Instructions like "make it better" will never tell the decision step when to stop. Clear goals can wrap up; vague goals only wander.

Stopping Criteria is the key to understanding "infinite tool loops." The model itself has no built-in judgment of "I'm done"; it merely predicts the next token at each step. If the prompt or runtime doesn't provide an explicit termination signal, the model tends to keep calling tools, because "let me check once more" is always probabilistically a reasonable next step. Engineering solutions usually come in two layers: hard constraints at the runtime layer, such as maximum steps, maximum token budget, and timeout; and soft constraints at the task layer, i.e., writing the completion state as a decidable predicate, such as "the file exists and the size field is non-empty." The former prevents loss of control; the latter prevents wandering. It's worth noting that when hard constraints trigger, the task is often incomplete, so the termination reason should be logged to distinguish "normal completion" from "budget exhausted."

Five Practices to Make the Loop Truly Converge

In response to the above traps, the video offers corresponding operational advice; the core idea is to turn "when to stop" into a decidable condition.

Give a goal with a measurable completion state: the file exists, plus its size, passes tests, returns a certain value. Constrain the available tools, exposing only the functions the task needs, following the principle of least privilege. Set decision and stopping rules, such as a maximum step limit, or stopping when the target field is filled. Write the loop process into logs, recording which tool was called, what result was obtained, and what decision was made—a debuggable Agent is far better than a mysterious one. Finally, treat tool results as untrusted input: check structure and value ranges first, then make decisions.

One-Sentence Summary

An Agent is not a smarter chat box, but a four-step loop of plan, call, read, and decide until the goal is achieved. The poll question raised at the end of the video is also worth pondering: does a model with no tools that only replies with text count as an Agent? According to this loop definition, the answer tends toward no—without tool calls, there is no loop, and therefore no Agent.

One-line Summary

The essence of an AI Agent is a four-step loop of plan, call tools, read, and decide; capability comes from the loop, not from memory.

Paragraph Summary

The article breaks down the core mechanism of AI Agents: they are not smarter chatbots, but repeated execution of a four-step loop—plan, call tools, read results, decide. Through a real workspace task demonstration, the Agent first lists the directory to confirm report.pdf exists, then obtains its size of 18,448 bytes, outputting the result only after two rounds of tool calls, showing that a single call is usually not enough and the value lies in judging "what's still missing." The article points out that Claude Code, Codex, and ChatGPT tool calling share the same loop structure with different interfaces, summarizes traps such as infinite tool loops, blind trust in tool output, lack of a sandbox, and vague goals, and finally offers five convergence practices: measurable completion states, least privilege, stopping rules, logging, and verifying tool output.