What counts as an AI agent
An AI agent is a software system that pursues a goal on a user’s behalf, rather than simply answering a single question. It perceives its environment, reasons about what to do next, takes an action, observes the result, and repeats that loop until the task is finished or a stopping condition is reached. The AI agent components described in this guide are the parts that make that loop work. That loop is the difference that matters: a chatbot produces one response to one prompt, while an agent works through a multi-step task, changing course as new information arrives.
An agent is also not the same thing as a fixed workflow. A workflow follows steps written in advance, in a set order, and produces predictable outputs from defined inputs. An agent chooses its next action dynamically, based on its goal, its context, and the results of its previous actions.
Autonomy is a spectrum, not a switch. Some agents act only after a person approves each consequential step. Others act on their own within permissions and guardrails set in advance, and pause when they reach something outside those bounds. Knowing where a particular agent sits on that spectrum is part of understanding what it is made of, because the controls around the loop are themselves a component, covered later in this guide.
The core AI agent components at a glance
Ask different guides to list the AI agent components and you will get different counts, because they group the same machinery at different levels of detail. One common account names three core parts: a reasoning core, tools, and memory, working through a perceive-reason-act loop. Another names five layers: model, tools, memory, orchestration, and runtime. A third names seven: goal definition, perception, memory, reasoning and planning, tool execution, orchestration, and feedback and observability.
Those counts are not contradictory. They are the same system described at different zoom levels. Goal definition, for example, can be treated as part of the reasoning engine or as its own component; orchestration can be folded into planning or named separately. This guide uses the following grouping, chosen because it covers parts that appear across the guides cited here, with responsibilities that overlap: a reasoning engine, memory, perception and tools, planning, and guardrails, plus the orchestration that holds the loop together.
The loop that connects them is simple to state and hard to get right. The agent takes in input, the model reasons about the next step, the agent acts through a tool, and the result comes back as a new observation. That observation joins the agent’s context, and the loop runs again. Responsibilities overlap between these parts — planning, for example, can sit inside the reasoning engine or stand apart — and a weakness in any one of them can show up as unreliable behaviour, whatever model powers the system.
The reasoning engine: the model at the centre
The reasoning engine is usually a large language model. It reads the goal, the current context, and the latest observations, and produces the next step: an answer, a plan, or a tool call. It interprets user intent, reasons about what to do next, chooses among available tools, and generates the actions and responses the rest of the system carries out.
The quality of reasoning at this layer shapes what the rest of the system can do well, but it is not the whole story. Reasoning quality depends on the model, on the instructions it is given, and on the context it can see. A capable model fed stale data, a vague goal, or a missing tool description will still choose badly. That dependence cuts both ways: clear instructions, good context, and well-described tools also affect whether a system is fit for a given task.
The reasoning engine also has limits worth stating plainly. A model can misread a task, pick the wrong tool, or produce a plausible but wrong next step. That is why the other components exist: memory supplies context the model does not have, tools let it check facts against the world, and guardrails constrain what its decisions are allowed to do. An agent is a system built around a model, not a model with a new name.
Memory and context: what the agent remembers
Memory is what lets an agent work across steps and sessions instead of starting from scratch each time. It comes in two broad kinds. Working context is the active material of the current task: the conversation so far, the goal, the plan, and the recent observations from tool calls. It is usually held in the model’s context window, which is why long tasks need careful management of what stays in context and what is set aside.
Persistent memory is stored knowledge retrieved across sessions: facts about a user or an entity, past interactions, and documents pulled in through retrieval. Vector stores and databases are common implementations, and retrieval from stored sources is one way an agent pulls stored facts into its working context when it needs them. The distinction matters because the two kinds fail differently: working context can be crowded out by a long task, while stored memory can go stale or retrieve the wrong record.
Memory design also affects cost, consistency, and privacy. Keeping everything in context grows costly and eventually impractical; retrieving selectively can reduce that cost but risks missing the fact that mattered. Storing user facts across sessions creates value and a responsibility: the agent’s memory should hold only what the task needs, and the people whose data it holds should be able to understand what is stored.
Perception, tools and action: how the agent touches the world
Perception is how an agent takes in its environment: user messages, files, sensor readings, database rows, and the results of its own earlier actions. Without perception an agent would be reasoning about a world it cannot see. With it, each new observation can change the plan, which is what makes an agent adaptive rather than merely scripted.
Tools are how an agent acts on that world. A tool is a function or interface the agent can call: an API, a database query, a code executor, a web search, a document retrieval step, or another agent. The model does not call tools directly in the sense of running them itself; it decides which tool to call and with what arguments, and the surrounding system executes the call and returns the result as a new observation. Well-typed function interfaces and clear tool descriptions are what make that choice reliable: the model can only choose well among tools it understands.
The result of a tool call is as important as the call itself. An agent that books, sends, or deletes without reading the result cannot tell success from failure, and cannot recover. The action-and-observation pair is therefore the unit of progress in an agent loop: act, observe, reason again. A tool that returns a clear success or error, in a shape the model can interpret, is worth more than a powerful tool that returns an ambiguous result.
Planning and goal decomposition
Planning is how a goal becomes a sequence of steps. A high-level goal such as resolving a support ticket is broken into sub-tasks — find the ticket, gather the relevant history, check the policy, draft a response — and those sub-tasks are ordered so that each step’s output feeds the next. The planner is sometimes described as a separate component and sometimes folded into the reasoning engine; either way, the function is the same: turning a goal into an executable order of work.
Plans also change. When a step fails, when a tool returns unexpected data, or when new information arrives, the agent replans: it revises the remaining steps rather than blindly continuing. The trade-off between a fixed plan and replanning at each step is a real design choice. A fixed plan is predictable and cheap, and suits routine work. Replanning at each step adapts to surprises, but costs more and can drift.
One widely used orchestration pattern for this loop is ReAct, short for Reason and Act. The agent reasons about its situation, acts with a tool, observes the result, and reasons again. ReAct is not a separate component; it is a pattern for running the components in order, and it is a widely cited pattern for describing the agent loop in concrete terms.
Guardrails and oversight: the controls on the loop
Guardrails are the component that constrains what an agent may do, and they deserve a section of their own because an agent without them has fewer limits on what it may do. The first guardrail is permission: an agent should have access only to the tools and data its job requires, so that a mistake or a manipulated instruction has less reach into systems it never needed. Least-privilege access is the boring, effective version of this idea.
The second is action checks before consequential steps. Sending a message, spending money, changing a record, or deleting data are actions that cannot easily be undone, and many agents are designed to check them before executing: filtering inputs and outputs for policy violations and sensitive data, validating arguments against what the task allows, and running the action in a sandbox designed to limit harm. The third is human approval. High-stakes actions pause for a person to approve before execution, rather than proceeding on the model’s say-so.
The fourth is observability: tracing and logging every reasoning step and tool interaction, so that behaviour can be checked after the fact. If an agent makes an error, the trace shows where it went wrong — which observation it saw, which tool it chose, and which check passed or failed. Guardrails do not make an agent infallible. When configured well and covering the actions that matter, they can restrict what an agent may do, reduce the harm of a mistake, and leave a trace that supports investigation — but their effectiveness depends on that configuration and coverage.
Putting the components together: a worked example, limits and common mistakes
Consider a support agent asked to resolve a ticket about a delayed order. Perception takes in the ticket and the customer’s message. The reasoning engine reads the goal — resolve the ticket — and the planner breaks it into steps: look up the order, check the delivery status, and check the refund policy. Memory supplies the customer’s history and the retrieved policy document. In this hypothetical example, assume the retrieved policy allows a refund for a failed delivery and the customer is eligible. The agent calls the order tool, observes that the delivery failed, and replans: a refund becomes the outcome to propose, under those stated assumptions.
Guardrails operate inside that same trace. Suppose the refund tool requires approval above a threshold, so the agent pauses and presents its findings to a human instead of refunding on its own. The human approves, the agent acts, and the trace records each step: what was observed, which tool was called, and which check ran. Removing a component would change the story in ways that depend on the assumptions above: without stored memory, the agent might ask the customer for details it already has; without tools, it could not look up the order or issue the refund; without the approval check, it might refund an amount nobody authorised.
Each component also has its own failure mode, and recognising them is the practical payoff of the map. Bad context can produce confident wrong answers. The wrong tool can produce a correct action on the wrong object. Stale memory can produce an answer that was true last month. An unchecked action can produce a mistake that cannot be recalled. A guardrail that is too strict produces an agent that asks for approval at every step and helps nobody; one that is too loose produces an agent that acts before anyone can stop it.
Two misconceptions are worth leaving behind. The first is that the model alone is the agent: the model is the reasoning engine, and an agent is the system around it — memory, tools, planning, orchestration, and guardrails. The second is that more autonomy always means better results: autonomy is a choice about which decisions the agent may make alone, and the right amount depends on the stakes of the action, the quality of the observations, and whether a human is available to approve the steps that matter.
