What Really Counts as a True AI Agent? Three Core Elements and One Test

The word "Agent" is being misused. According to one tech video, my toaster probably has its own agent strategy—and maybe even a pitch deck. That quip comes from a series called "Agentic AI: A Practical Guide," which plans to cover in 15 parts everything from "what makes software an agent" to how to design, run, and make agentic systems reliable and aligned.

For people who need to buy, build, or manage these tools, there's a lot of ambiguity behind the word. Understanding what it actually means can save real money—and a few embarrassing moments.

A Testable Working Definition

The series offers this definition: An Agent is a model that pursues a goal by autonomously choosing actions, using tools, and reacting to the results returned.

Broken down, there are three elements: goal, tools, loop.

"Model" here means a large language model—trained on massive amounts of text and fundamentally predicting the next word. The author uses a vivid metaphor: a traditional chatbot is like a well-read person locked in a windowless room. Ask it about the weather in Lisbon, and it will confidently guess an answer from memory. It can talk, but it can't look.

Researcher Lillian Wang offered an influential framework: a language model is the "brain" of an agent, surrounded by three supporting components—planning, memory, and tool use. Planning is breaking a goal into steps; memory is the information it can track, starting with the context window, i.e., the amount of text the model can see at once; tool use is calling external capabilities like search or a calculator.

Underneath, this corresponds to a pattern proposed in a paper called ReAct: the model writes out its reasoning, then takes an action, alternating between the two rather than thinking it all through and then acting once. These "actions" are the windows in that windowless room—letting the model reach external information sources like knowledge bases or environments, and obtain content it didn't originally have.

So the shape of the loop is: think, act, see the result, think again.

ReAct is a prompting and reasoning framework proposed in 2022 by Shunyu Yao et al., short for Reason + Act. Its core approach is to have the language model alternately generate "Thought" and "Action," receive an "Observation" returned by the environment after each action, and continue thinking based on that observation. Unlike Chain-of-Thought, which reasons once and then outputs an answer, ReAct incorporates external feedback into the reasoning trajectory, enabling the model to correct earlier mistaken assumptions. The paper validated this pattern on question answering, fact verification, and interactive decision-making tasks. Today's mainstream agent frameworks—the cycle of "reason, call a tool, read the result"—can basically all be seen as engineering implementations of the ReAct pattern.

A Counterargument: Isn't This Just a Chatbot That Takes a Few More Steps?

Take this challenge seriously. Mechanically speaking, to some extent it's true—it's still the same model.

The real difference is who decides the next step. In the loop, it's the model that reads the result and chooses what to do next. That's the turning point.

This yields a very practical way to ask questions: when someone pitches you an agent, ask them two things—can it look things up and take action? Will it change course based on what it finds? If both answers are no, it's a chatbot in a nice coat.

Context window refers to the total number of tokens a model can "see" at once in a single inference, including the system prompt, conversation history, tool results, and so on. It constitutes the physical upper limit of an agent's memory: once exceeded, earlier information must be truncated or compressed. This is why long-task agents often need additional memory mechanisms—writing important information to external storage and retrieving it when needed, rather than stuffing everything into the context. Understanding this helps you judge whether an agent product's claimed "long-horizon task capability" is credible: if a task spans many steps, the context window alone is usually not enough, and an explicit memory management strategy is required.

Where the Three Vendors' Definitions Diverge

When you compare three vendor brochures, you'll find that the word "agent" seems to be used differently in each—but look closely and they largely line up.

Anthropic draws the clearest line. A workflow means the model and tools run along a code path the developer has written in advance; an agent means the model itself controls the flow and tool calls. Going further, in an agent the model retains control over "how to complete the task," making dynamic decisions rather than executing a script.

OpenAI's description reads more like an engineer's parts list. In its agents SDK documentation, an agent is a language model configured with instructions, tools, and several optional runtime behaviors.

Google Cloud gives you a ladder. A bot automates simple tasks or conversations, an assistant helps users complete tasks, and an agent executes tasks autonomously and proactively. The most critical rung in Google's view is likewise "who makes decisions": the assistant is decided by the user, and the agent sits at the top with the greatest autonomy.

The tension is right here: OpenAI's definition is about "ingredients," while Anthropic and Google's are about "who's holding the steering wheel." You can absolutely have all the ingredients and still run them as a fixed script—and incidentally, there's nothing wrong with that. Plenty of excellent products on the market are essentially workflows, just marketed under an agent label.

So the practical test comes down to one sentence: who decides the next step, the developer's code or the model? This one question is enough to sort that pile of brochures on your desk.

Walking Through a Real Scenario: Fixing a Failing Test

Suppose a developer types "fix the failing test" into a coding agent like Claude Code. The following is a generic pattern and does not represent the specification of any particular product.

First, a concept: harness—the software wrapped around the model that provides it with tools—reading files, executing commands, editing code, and passing results back to the model. The model is the brain; the harness is the hands and eyes.

Step one, the model reasons: I should first see which tests are failing. It asks the harness to run the test suite.

Step two, output returns, such as several failure records with error messages.

Step three, it reasons again, opens the relevant file, locates a likely bug, and makes a change.

Then it reruns the tests and reads the results. If something else breaks, it goes another round. Until the tests pass, or it decides it needs to ask you for help.

Goal, tools, loop—all three elements are present in a single task. Every step has a reason: running the tests gives it facts rather than guesses; rerunning the tests is self-checking; and the loop lets it recover from its initial misjudgment.

Coding agents are one of the most mature agent categories in deployment today, with representative products including Claude Code, Cursor's Agent mode, and the agent features of GitHub Copilot. What they share is that the harness provides tools for file reading and writing, terminal execution, code search, and more, and the model autonomously decides in the loop which file to read, which command to run, and which line of code to change. The reason this scenario suits agents is that results can be mechanically verified—whether tests pass and whether compilation succeeds are objective signals, which the model can use to self-correct and users can easily audit. Conversely, for tasks lacking clear verification signals, such as open-ended writing or strategic planning, an agent's loop easily loses direction and its benefits are harder to measure.

How It Goes Wrong, and What It Costs

Failure modes are concrete: misreading error messages, chasing the wrong file, or the most classic one of all—making the test pass by changing the test. Extremely efficient, completely wrong direction, like a student who raises their score by changing the answer key.

So for users: an agent's capabilities come from tools, and so do its risks. Know what it can touch, and check what it did, not just what it says it did.

Support tickets and coding are the two most classic agent deployment scenarios, because the tasks are open-ended but the results can be verified: was the ticket resolved? Did the tests pass?

But autonomy isn't free. Anthropic cautions that agentic systems often trade additional latency and cost for better task outcomes, and recommends seeking the simplest solution that works. Every round of the loop is a model call, and every call consumes money and seconds—ten loops, ten bills.

The Ladder: Prompt First, Then Workflow, Then Agent

The series offers a pragmatic path: first a good prompt, then a fixed workflow, and only finally a true agent—and only when the path genuinely cannot be determined in advance.

Before building, ask one question: are these steps predictable? If they are, a workflow is cheaper, faster, and easier to build trust in. Start simple and climb step by step through measurement. An agent should be the answer to a problem, not an answer looking for a problem.

The core conclusion can be boiled down to one sentence: An Agent is defined by "who decides the next step"—a goal, a set of tools, and a loop that lets the model read the results and choose again. Everything else is either a chatbot, a script, or an assistant. And those are often the better choice.