One-sentence definition
Sistema que utiliza un modelo para decidir pasos, mantener estado y operar herramientas bajo objetivos, permisos y reglas definidos.
What Is an AI Agent?
An AI agent is a system that receives information from an environment, selects actions in pursuit of a goal, and observes what happens next to decide whether to continue, change course, or stop. The important word is “system”: an agent is not necessarily an isolated artificial intelligence model. It may include a model or control policy, instructions, contextual information, tools, an environment, and rules that limit the actions available to it.
This definition describes a cycle of perception, decision, and action. It does not require the system to have a personality, consciousness, permanent memory, or freedom to do anything it wants. Nor does it require a large language model (LLM). The classical framework for agents is broader than today’s generative assistants; those assistants are one possible family of implementations, not the whole definition.
In this article, “agent” is used in a functional sense: what matters is whether the system can choose among possible actions based on the state it observes and the task it needs to accomplish. A system can have very limited autonomy—for example, selecting one of two authorized tools—and still exhibit agent-like behavior. Autonomy is therefore not a binary switch.
Possible Components and the Operating Cycle
An agent may combine several elements. The goal defines what it is trying to achieve; the model or control policy helps select the next step; instructions and context frame the task; state holds the information needed to continue; tools or actuators make it possible to act; and the environment is what the agent observes or changes. Permissions, checks, usage limits, and stopping conditions may also be present. These are possible components, not a checklist of requirements that every agent must satisfy.
In an implementation using a generative model, the loop may involve sending the model the task and available state, inspecting its response, executing a tool if the system permits it, and then consulting the model again with the result. The process ends when a final response is produced, a stopping criterion is met, a limit is reached, or human intervention is needed. Documentation for a particular SDK describes an execution cycle of this kind; other designs may organize the process differently.
Memory also needs to be described precisely. A system may retain information during a task or receive saved state between tasks, but you should not assume that every implementation does this. Similarly, an agent may use one tool, several tools, or none. Having tools available does not mean the agent can invoke them without restrictions: permissions and control rules determine which actions are actually possible.
An agent cycle, step by step
- 01Receive a task and identify the goal and applicable limits.
- 02Observe the relevant state of the environment and the available context.
- 03Choose whether to respond, request information, use an authorized tool, or stop.
- 04Execute the authorized action and collect its result.
- 05Update the state with the new observation and decide whether to continue, escalate the task, or finish.
- 06Check the stopping condition and, where appropriate, verify the result before presenting it.
Four Examples in Different Fields
The following examples are illustrative outlines, not claims that every product in these fields works this way. In each case, what makes the design agent-like is the cycle of observation, action selection, and review of results. A bounded task can have restricted permissions and human controls while still being a system that chooses its steps in response to what it finds.
Agent, Chatbot, Tool, and Automation: Practical Differences
A chatbot is usually described by its conversational interface: it receives messages and produces responses. It may do no more than respond, but it can also incorporate actions and a decision cycle. “Chatbot” and “agent” are therefore not always mutually exclusive categories: the first term can describe the interaction format, while the second describes how the system selects actions to advance a task.
A tool call is a capability or an execution step, not a guarantee of broad autonomy. A model may decide which tool to call, when to call it, and with what arguments, as Toolformer studies; even so, the complete system includes the mechanism that authorizes and executes the call. Agents can also exist without using external tools. A tool interface such as MCP is a related concept, but simply connecting a tool does not tell you how much the system decides for itself.
An automation or workflow specifies steps in advance: if a condition is met, a predetermined action is performed. Adding an LLM to one of those steps means the workflow includes AI, but does not necessarily give it dynamic action selection. In a broad sense, someone might call a workflow that incorporates decisions “agentic.” In this article, we reserve “dynamic agent” for a design that can choose the next step based on the task and its observations, rather than merely following a closed sequence.
An assistant is a product category or role that can cover everything from answering questions to carrying out tasks with tools; the term does not, by itself, determine the architecture. A multi-agent system coordinates more than one agent, but having more components does not demonstrate that the solution is better. Agent memory, context engineering, retrieval-augmented generation (RAG), and human-in-the-loop processes are related concepts that may appear in some designs; none is a universal requirement for calling a system an agent.
Decision table: what best describes the system?
| What you observe | More precise description | What to check next |
|---|---|---|
| It receives messages and responds, with no described actions afterward. | Chatbot or conversational interface. | Whether it can select and perform actions beyond responding. |
| It always runs the same steps when the same condition occurs. | Automation or predefined workflow. | Whether new results can dynamically determine the next step. |
| The model requests a tool and the system executes it. | Tool use; this may be part of an agent. | Who makes the decision, what permissions apply, and how the result is used. |
| It observes results and chooses among permitted actions to advance a task. | Agent-like behavior, with the degree of autonomy allowed by its controls. | Scope, verification, human intervention, and stopping conditions. |
Common Misconceptions and Limitations
The first mistake is treating an agent as if it were only the LLM. A model can produce a proposed action, but the system receiving it decides whether to execute it, with what permissions, and how to return the result for the next step. The distinction matters for analyzing safety and responsibility: a text response and an action that modifies a resource do not have the same consequences.
The second mistake is inferring extensive autonomy from tool use. The system may have just one available tool, require approval for every action, or operate in a test environment. Conversely, an automation without an LLM may select actions based on observations. It is better to describe the behavior and controls than to rely on a marketing label.
Autonomy should not be confused with reliability either. An agent may misinterpret a task, plan poorly, receive incomplete observations, or misuse a tool’s result. It may repeat actions in a loop, stop too soon, or produce a synthesis that does not reflect the evidence it retrieved. A fluent response, demonstration, or successful run does not by itself prove consistent performance.
When a system processes instructions or external content, that material may try to influence its decisions, for example through prompt injection. The risk depends on what data the system reads, what actions it can perform, and how trusted instructions are separated from observed content. Least-privilege permissions, human review at sensitive steps, and the ability to reverse changes are design measures that can reduce consequences, but they do not make an open-ended task infallible.
Finally, persistent memory, explicit planning, and multiple agents are not universal requirements or guarantees of better results. They are design choices. Their usefulness depends on the task, how they are implemented, and how they are evaluated. The sources available for this article do not establish a general performance comparison across all of these options or support a universal classification of agents.
How to Evaluate an Agent Before Using It
Start by defining an observable task. “Help with operations” is too broad; “classify requests of a particular type and prepare a proposed response without sending it” makes it possible to identify inputs, the expected output, and the limits. Then describe the environment, the information the system can access, and the actions it can perform. This helps distinguish a generated response from an actual intervention.
Specify permissions and controls: which actions are read-only, which modify data, which require approval, and which are prohibited. Also define what should happen when data is missing, results conflict, tools fail, or the system is uncertain. Stopping conditions should be explicit—for example, stop when an action is unauthorized, or escalate a request that does not fit the agreed criteria.
Evaluate task performance and safety separately. A measure may show whether the result meets the goal, but that is not enough to establish whether the system respected permissions, avoided unwanted changes, or asked for help when it should have. Also check cost, time, repeated actions, how easy results are to review, and whether an operation can be reversed. The evaluation method should include ordinary cases and edge cases from the real environment.
Human intervention does not have to be identical at every stage. It may be necessary before an irreversible action, after a proposal, or when the system detects ambiguity. The important thing is to make clear who approves, what information they receive, and whether the system can act before approval. If the same agent that produced the result is also responsible for verifying it, consider whether an independent check is needed.
Practical evaluation checklist
- 01Describe the task, accepted inputs, and the output that counts as success.
- 02List the environment, information sources, and every action available to the system.
- 03Separate read, write, send, and approval-required permissions.
- 04Set stopping, escalation, reversal, and failure or uncertainty-handling conditions.
- 05Test ordinary, ambiguous, and adversarial cases; record both errors and required interventions.
- 06Review quality, safety, cost, and auditability before expanding the system’s scope.
Related Concepts and Final Criteria
Tool calling helps explain how a model can request an external action; agent memory and context engineering relate to information the system retains or receives; RAG concerns incorporating retrieved information into a response or task. Human-in-the-loop processes and the principle of least privilege help frame supervision and access limits. These are topics worth linking to their dedicated glossary entries, not components to assume are required in every agent. It is also useful to consult the comparison between agents and other forms of automation to examine borderline cases.
In short, call a system an agent when you can describe a goal, observations of its environment, and a selection of actions that adjusts to the results it obtains. To judge it, do not stop at the label: ask what it decides, what it can execute, what requires approval, how it verifies the result, and when it stops. A concrete description of those limits is more informative than simply claiming that a product is autonomous.
