What Is an Agent?

An Agent Is Not a Tool Loop

Introduction: What Comes to Mind When We Say, “Let’s Build an Agent”?

When we think about designing an AI agent, implementation details often come to mind first.

Which LLM should we use?
Which tools should we connect?
Should we separate the planner from the executor?
How should we structure memory?
How many times should tool results be fed back into the model?
Which agent framework should we use?

These are all necessary considerations when implementing an agent. But choosing the implementation components first does not automatically help us understand the work we are trying to automate.

We can connect a search tool and a code execution tool, then build a loop that feeds their results back into an LLM. Yet that structure alone does not tell the system what it should judge or decide.

Which information should it treat as important?
Which action should it take first among several alternatives?
When a result differs from what was expected, should it keep the current plan or look for another approach?
At what point should it decide that the task is complete?

If we connect tools and loops before answering these questions, we may create a system that looks like an agent from the outside but has no clear idea of what it is supposed to do well.

Tools and loops are mechanisms for implementing decision-making. They do not define the substance of those decisions.

Before designing an agent, we need to examine the work we want to automate.

What does a person observe while performing that work? Which information do they treat as an important clue, and which information do they ignore? On what basis do they choose the next action, and when do they revise an earlier judgment?

Building an agent means uncovering these decisions and designing how much of them should be delegated to the system.

1. What a Tool Loop Shows—and What It Does Not

Today, an LLM agent is often described as a system with the following structure:

The user provides a goal.
The LLM selects the next action or tool.
The tool is executed.
The result is returned to the LLM.
The process repeats until the task is complete.

In simpler terms:

Observe, decide, act, receive a result, and decide again.

This structure is useful for explaining agents. Many LLM agents do, in fact, operate through a similar loop.

The problem begins when we judge the nature of a system by this outward structure alone.

Imagine two systems that both use a search tool and an analysis tool.

The first system runs the search tool, summarizes the results, and then calls a predefined analysis tool. The execution order and termination conditions are written in code in advance. The LLM generates the content required at each step, but it does not change the overall direction of the process.

The second system reviews the search results and changes the query when it decides that the available information is insufficient. If it finds conflicting sources, it looks for additional evidence. It begins the analysis only when it believes that enough support has been collected. If confidence in the result is low, it performs further verification or asks the user a question.

Both systems call tools and feed the results back into the model. From the outside, they appear to use the same tool loop.

What differs is the decision-making authority delegated to the model.

Can it change the order in which tools are used?
Can it revise the existing plan based on new results?
Can it determine what information is still needed?
Can it choose a different method?
Can it decide when the task should end?
Can it ask a human for help when uncertainty remains?

The existence of a loop tells us only that execution is repeated. It does not tell us what is being decided inside the loop, what choices are available, or how far the system is allowed to act.

A simple for loop is still a loop. An automation that calls a fixed sequence of APIs also uses tools.

No matter how sophisticated the tools and loops may be, their presence alone does not mean that the system has been given meaningful decision-making authority.

2. Start by Dissecting the Work You Want to Automate

How, then, should we design an agent?

We should begin by examining exactly what we are trying to automate. Here, “work” does not mean only the visible sequence of actions a person performs on a screen.

Clicking a button, opening a document, and entering a search query may feel almost unconscious once they become familiar. But each action still serves a purpose.

Even the smallest action is shaped by judgment and experience.

Consider a security expert assessing a web service for vulnerabilities.

The visible sequence of actions might look like this:

Open a page.
Inspect requests and responses.
Modify an input value.
Send a payload.
Record the result.

If we automate this sequence exactly as written, we can build a scanner that sends predefined inputs and collects responses. That kind of automation is already valuable.

But an experienced security professional does not simply send payloads in a fixed order.

The more important question is not merely which input vectors, outputs, or error messages exist. We need to examine how we interpret that information and how, among an enormous amount of code and data, we learn to focus only on what matters.

Even when we are not consciously aware of it, we are constantly optimizing. We trace relationships among pieces of data, combine them, and narrow the space of possibilities.

That process contains many hidden decisions:

Which information is an important clue?
What is normal, and what is anomalous?
Which hypothesis should be tested first?
Which action carries less risk?
Does the result support the hypothesis?
Is additional verification necessary?
How much evidence is enough to classify something as a vulnerability?
When should automated verification stop?

There are likely many more decisions beyond these. For experienced practitioners, such decisions become habits. They may make them quickly without consulting an explicit checklist.

As a result, they may not be able to explain immediately why they checked one piece of information first or why they chose not to try a particular method.

Understanding a task well enough to automate it therefore requires practice in bringing hidden judgment to the surface: both the parts we perform unconsciously and the decisions embedded in knowing what must be done.

This does not mean reproducing human thought exactly or turning every inner monologue into a sentence. It means separating the elements that make up a decision and redesigning them in a form the system can use.

Observation: What information and state should be inspected?
Interpretation: What meaning should be assigned to what was observed?
Hypothesis: How should possible causes or solutions be generated?
Prioritization: How should the system decide what to examine first?
Action: Which tool or intervention should it choose?
Feedback: How should the result change the current judgment?
Termination: What counts as success or failure?
Escalation: When should the task be handed to a human or another system?
And so on.

Only after analyzing this process can we determine which tools are actually needed.

At that point, it also becomes clearer what information should be retained in memory, which results should influence the next decision, and why a loop is necessary in the first place.

If the task’s decision structure has not been defined, however, we may end up with a system that has many tools but does not know what to do with them. Its memory may accumulate large amounts of information without identifying what is relevant to the next action.

Dividing the work among multiple agents does not solve this problem. A decision that was never defined in a single system does not suddenly become clear simply because it has been distributed across several agents.

The starting point of automation is not an agent framework. It is identifying the decisions that actually occur in the work being automated.

3. Agents Did Not Begin with the LLM Era

One reason we tend to think of an agent as a combination of tool calling and a loop is that most people today encounter agents through LLMs.

But the concept of an agent did not originate in the LLM era.

For decades, artificial intelligence has treated an agent as a system that receives information from an environment and acts back upon that environment.

The widely used textbook Artificial Intelligence: A Modern Approach describes an agent as something that perceives its environment through sensors and acts upon that environment through actuators.[1]

The important point here is not any particular tool or LLM.

An agent exists within an environment.
Information about that environment is received.
A set of possible actions is available.
An action is selected according to some criterion.
The result of that action appears in the environment.

This structure has appeared in different forms across many areas of AI research.

AI planning studied which actions should be performed, and in what order, to reach a goal. Robotics used sensors to inspect the surrounding environment and physical devices to act within it.

Multi-agent research examined how several agents cooperate or compete within the same environment.

BDI agent research in the 1990s attempted to explain an agent’s behavior by separating its information, motivations, and current commitments into Beliefs, Desires, and Intentions.[2]

The relationship between an agent and its environment is also central to reinforcement learning. The agent selects an action in the current state, and the environment returns a new state and a reward as a consequence of that action. The agent then uses this experience to adjust how it behaves in the future.[3]

These fields did not all study the same kind of agent.

An agent that controls a robot’s movement, a software agent that handles operational tasks, and a reinforcement-learning agent that learns to play a game solve very different problems.

Even so, a recurring structure remains:

An agent occupies the position of selecting one action from a set of possibilities based on the state of its environment, then interacting with the result of that action.

From this perspective, today’s LLM agents did not create an entirely new concept.

LLMs introduced a new way to interpret natural language and unstructured information and to select among possible actions. Tools such as APIs, search systems, and code execution environments became channels through which an LLM could observe and alter a digital environment.

ReAct proposed a structure in which an LLM alternates between reasoning and concrete actions, allowing it to update its plan and respond to exceptions using information obtained from an external environment.[4]

As tool calling and agent frameworks became widespread, the public image of an agent increasingly became that of an LLM repeatedly invoking tools.

4. A Common Structure Across Different Agents

It is difficult to place every kind of agent under one strict definition.

Instead, we can identify a common structure that helps us analyze different systems.

Environment

The environment is whatever the agent receives information from and can affect through its actions.

For a robot, the environment may be a physical space. For a web automation agent, it may be a browser and a web service. For a coding agent, it may include a repository, a runtime environment, and test results.

The environment does not have to be the physical world.

A database, file system, game, conversation, or even another agent can be part of the environment.

Observation

An agent cannot know the entire environment directly.

It observes the current state through limited channels such as sensors, API responses, documents, logs, and user messages.

An agent’s performance therefore depends not only on the model’s capabilities but also on what information the system makes observable.

An incident-response agent that cannot access the necessary logs will struggle to identify the true cause of a failure. A security agent that cannot inspect the DOM or network requests of a page must make decisions based only on what is visually displayed.

State

A current decision may depend not only on the latest input but also on what happened earlier in the process.

Actions that have already been attempted
Results of previous actions
Hypotheses formed so far
Approaches that have already failed
Remaining time and budget
Constraints specified by the user
Actions that a human has approved or rejected

Together, this information forms the current state.

Memory is an implementation mechanism for storing and carrying that state forward. Rather than building memory first, we should determine which past information is actually needed for the next decision.

Goals and Evaluation Criteria

For an agent to choose an action, it needs some basis for deciding which outcomes are better.

A goal may be supplied by the user or encoded by the developer. The system may also divide a given goal into several subgoals.

Here, we need to distinguish between a goal and the criteria for success.

“Find a vulnerability” is not specific enough.

What type of vulnerability should be found?
What level of evidence is required?
Are verification methods that could affect the service allowed?
Which matters more: reducing false positives or reducing false negatives?
How much time and how many requests may be used?

Only with such criteria can the system determine what should count as a good result.

The behavior of a rational agent is not simply behavior that appears intelligent. A rational agent selects the action expected to produce the best outcome according to what it has observed, the actions available to it, its knowledge of the environment, and the criteria used to evaluate performance.[1]

Action Selection

An agent may have several possible actions available.

It may search, execute code, request more information, verify an earlier result, or stop the task.

What matters in agent design is not the number of available actions.

What matters is how the system decides which action to take in the current state and what determines that choice.

Execution and Feedback

When the selected action is executed, the environment may change or new information may become available.

The agent must incorporate that result into its next decision.

But merely placing the result back into the prompt does not create meaningful feedback.

The result should produce changes such as the following:

Confidence in an existing hypothesis increases or decreases.
The priority of the next action changes.
Part of the plan is revised or abandoned.
A new risk is identified.
The task is terminated or escalated to a human.

If new results arrive but the system repeats the same action every time, a loop may exist, but no meaningful adaptation is taking place.

5. Where Tools and Loops Fit

Saying that tools and loops are not the whole of an agent does not mean that they are unimportant.

On the contrary, once the task and its decision structure are clear, we can design the role of each more precisely.

Tools Connect Decisions to the Environment

An LLM cannot modify a file, search the web, or send an email merely by generating text.

A tool is an interface that turns the LLM’s selection into an action in the real environment.

Tools are not used only to change the environment. They can also be used to obtain new observations.

Retrieve search results.
Query a database.
Inspect logs.
Execute code and receive the output.
Modify a file.
Send an email or message.

The same tool can serve different purposes depending on the agent’s decision structure.

What matters more than merely having a search tool is knowing when a search is necessary and what information the system is trying to find.

A Loop Feeds Results Back into Decision-Making

A loop is needed when the task cannot be completed through a single action.

The agent observes the result of an action and selects what to do next. When the result differs from what was expected, it may revise the plan or choose another tool.

But not every task needs a long loop.

When the input format is clear and the processing order is stable, a predefined workflow may be faster and more reliable. If one LLM call and a single validation step are enough, forcing the system through repeated iterations may only increase cost and the chance of error.

The length of a loop is not a measure of how advanced an agent is.

A good loop is not one that runs for a long time. It is one that stops when the necessary result has been obtained and takes another path when failure becomes clear.

Memory Maintains the State That Matters

More memory does not automatically create a better agent.

If irrelevant information continues to accumulate, the model may struggle to find what matters for the current decision. Old hypotheses or incorrect results may continue to distort later judgments.

Before designing memory, we should ask:

What past information is needed to choose the next action?
Which information should remain after the task is complete?
Which information should be summarized or deleted?
How should facts be distinguished from hypotheses?
What must be recorded to prevent the system from repeating a failed action?

Memory is not a feature that gives an agent human-like recollection.

It is a mechanism for maintaining, in an appropriate form, the state required for decision-making in the current task.

6. The Key Difference Between a Workflow and an Agent Is Where Decision Authority Resides

Workflows and agents are often presented as opposites.

Anthropic distinguishes workflows, in which LLMs and tools follow predefined code paths, from agents, in which an LLM dynamically directs its own process and tool usage.[5]

Harrison Chase of LangChain has described an agent as a system in which an LLM determines the application’s control flow.[6]

Both descriptions point to the same important distinction:

Is the next step predetermined in code, or is it selected by the model at runtime based on the current situation?

Consider a document-processing system that works as follows:

Extract text from a document.
Classify predefined fields.
Store the results in a database.
Generate a report.

If the steps and their order are always the same, a workflow is appropriate. Even if an LLM is used at each stage, the model is still performing a component within the workflow when the overall path is fixed in code.

Now imagine that the system must determine what information is relevant based on the type of document, decide whether it should compare the document with other materials, and request additional documents when information is missing.

In that case, some decisions must be made during execution.

The model is no longer merely generating content inside a predefined step. It is selecting the next step itself.

In practice, however, it is difficult to classify most systems as purely a workflow or purely an agent.

Most combine the two approaches.

Code limits which tools are available.
The model chooses the order in which tools are called.
A human approves actions such as payments or deletions.
Code limits the maximum number of iterations and the total cost.
The model makes an initial judgment about whether the current result is sufficient.
A validator determines whether the task has actually been completed.

The more useful question, therefore, is not, “Is this a real agent?”

For each decision in the system, who holds the authority: code, the model, or a human?

A workflow is not a lower stage of development than an agent.

A workflow is often the better choice when rules are clear, exceptions are rare, and reproducibility matters. By contrast, when the required action changes from one situation to another and it is difficult to encode every possible path in advance, there is a reason to delegate some decisions to the model.

Increasing complexity should never become the goal itself.

We need to distinguish between decisions that can be fixed in advance and decisions that truly need to be made during execution.

7. Being an Agent Is Not a Binary Switch

It is difficult to decide whether a system is or is not an agent based on a single condition.

An LLM does not make every decision by itself merely because it selects one tool. Conversely, a system does not cease to be an agent simply because the user provides its goal.

Rather than treating agentic behavior as one vague measure of autonomy, it is more accurate to examine the individual decisions and permissions that make it up.

Authority to Set Goals

Who defines the goal?

The user may provide the final objective while the system creates only the subgoals. Alternatively, both the objective and the processing order may be fixed in code.

Even when the system creates its own subgoals, there must be a way to verify that those subgoals remain aligned with the user’s intent.

Authority to Choose the Next Action

Is the next action predetermined?

Or does the model select it based on the current state and previous results?

Having many possible actions is not the same as being able to choose the correct one. The candidate actions and the criteria for selecting among them must be designed together.

Authority to Select Tools

Can the model choose which tools to use and in what order?

We should also distinguish between selecting only the name of a tool and controlling its inputs and scope of execution.

Generating a search query and generating a command that deletes files from a server do not represent the same level of authority.

Authority to Revise the Plan

Can the system change its existing plan when execution produces an unexpected result?

Even if it can revise the plan, it should not be allowed to try new methods indefinitely. Retry and termination conditions should be defined according to cost, time, and risk.

Authority to Act on the External Environment

How far is the system allowed to change its environment?

Can it only read information?
Can it create temporary files?
Can it modify code in a real repository?
Can it send messages or emails?
Can it make payments or enter into contracts?
Can it delete user accounts or data?

Decision-making capability and permission to act must be evaluated separately.

Even a system that makes good decisions should be restricted when an action is difficult to reverse. Conversely, even a fixed workflow can create serious risk if it has powerful external permissions.

Authority to Declare Completion or Failure

Who decides that the task is complete?

The fact that the model generated a final answer does not mean the actual objective was achieved.

Completion conditions should be externally verifiable whenever possible.

Did the tests pass?
Were all required materials collected?
Were the changes actually applied to the environment?
Were all of the user’s conditions satisfied?
Is there enough evidence to support the result?

An agent claiming that it has finished is not the same as the task being verified as complete.

Conditions for Human Escalation

When should the task be handed to a person?

A system is not more advanced simply because it attempts to resolve every exception on its own.

Escalating to a human may be the better decision when:

The user’s intent can be interpreted in several ways.
The system lacks permission to access necessary information.
Confidence in the result is low.
The action is difficult to reverse.
A legal or ethical judgment is required.
The expected cost or time exceeds the allowed limit.
Conflicting objectives are discovered.

Asking a human a question or requesting approval is itself a valid action.

Once we abandon the assumption that an agent must handle everything alone, we can build systems that are safer and more realistic.

8. More Autonomous Does Not Mean Better

Autonomy sounds appealing when we talk about agents.

It invites us to imagine a system that reaches a goal without human intervention, handles exceptions, and continues working over long periods of time.

But autonomy is not a score that should always be maximized.

As autonomy increases, the system gains more actions to choose from. This allows it to respond to situations that were not anticipated in advance, but it also creates failures that were not anticipated in advance.

More tools expand what the system can do, but they also increase the possibility of choosing the wrong tool.

Longer loops create more opportunities for self-correction, but they can also reinforce a mistaken hypothesis or continue consuming resources without making progress.

More memory gives the system access to more information, but it also increases the chance that outdated or incorrect information will influence its decisions.

Greater authority over the external environment allows the system to complete more of the task, but it also allows a mistaken decision to cause real harm.

A good agent, therefore, is not the system with the greatest amount of authority.

It is a system whose decision-making authority and permission to act are limited to what the task actually requires.

Encode decisions with clear rules in code.
Delegate context-dependent, unstructured judgments to the model.
Verify results against independent criteria whenever possible.
Leave high-risk or high-responsibility decisions to humans.
Set limits on cost and iteration count.
Design failure and human-escalation conditions in advance.

The goal is not to make an agent look like a person.

The goal is to implement the decisions required by the work and place each decision in the most appropriate part of the system.

Conclusion: Building an Agent Means Designing Delegation

Tools and loops are important components of modern LLM agents.

Tools allow an LLM to retrieve external information or alter its environment. Loops allow it to inspect the result of an action and continue making decisions.

But tools and loops alone do not explain what the system is deciding.

To understand an agent, we need to examine the decisions and permissions placed within it.

Who defines the goal and the criteria for success?
What can the system observe?
Who chooses the next action: code or the model?
How does an execution result change the existing judgment?
Who selects the tools and the order in which they are used?
How far can the system alter the external environment?
Who determines completion and failure?
When should the system stop or escalate to a human?

Once we can answer these questions, whether we choose to call the system an “agent” is no longer the most important issue.

If we cannot answer them, however, then no matter how complex the tools and loops may be, it will remain difficult to explain what has actually been delegated to the system.

When we want to automate a task, we should begin by observing human behavior.

But we should not stop at the buttons people press or the sequence of screens they navigate. We also need to examine which information they treat as important, which hypotheses they form, and what causes them to revise a judgment.

As far as possible, we should bring the decisions people make unconsciously into the open. We should remove human limitations that machines do not need, encode clear rules in software, and delegate only the judgments that genuinely vary with the situation to the model.

A good agent is not the system with the most complex loop. It is a system that understands the decision structure of the work being automated and delegates the necessary decisions and permissions to act only as far as the task requires.

Ultimately, building an agent is not about connecting tools.

It is about discovering the decisions embedded in the work and designing how those decisions should be divided among code, models, and humans.

A Final Note

The essential idea is not especially complicated.

Even when building a basic agent or a simple automation, we first need to identify the actions we perform, the data we perceive, what each piece of data means, and what information is actually available.

Mapping all of these steps may feel tedious at first.

But finding them is essential.