An AI agent is more than a language model with a prompt. This article maps the core components AI agent systems share — a model that reasons, tools that act, memory that persists, planning that decides, and the orchestration that holds them together — and shows how they fit into one working system. The list is not identical in every source: some count four components, others add perception and execution as separate layers, and guardrails appear as a layer rather than a component. This article presents the consensus four — model, tools, memory, planning — plus the surrounding pieces, and says where the sources disagree.
The core components AI agent systems share
At its simplest, an agent is a language model in a loop: it observes its environment, decides what to do next, takes an action, and then observes the result before deciding again. Anthropic’s December 2024 engineering post Building Effective Agents defines the base unit as an augmented LLM — a model extended with retrieval, tools, and memory — and builds everything else on top of it. Amazon’s Bedrock guidance puts it as three capabilities that turn a chat completion into an agent: planning, tool use, and memory, operating in a goal-directed loop until the task is complete. One practitioner summary states the formula as “LLM + Tools + Memory + Loop = Agent” and adds that removing any of these leaves something less than an agent.
The five components this article maps are the model, tools, memory, planning, and orchestration. The model is the reasoning core. Tools are how the agent acts on the world. Memory is how it keeps state. Planning is how it decides what happens next. Orchestration is the runtime that runs the loop and connects the rest. Perception — the channels the agent reads — and guardrails — the limits it operates inside — sit around those five rather than beside them.
The model: the reasoning core
The model is the decision-maker. It receives everything in the conversation window, interprets the goal, decides what to do next, and either produces a response or requests a tool call. Anthropic draws the line between workflows and agents on exactly this point: in a workflow, LLMs and tools are orchestrated through predefined code paths that you wrote; in an agent, the LLM dynamically directs its own process and tool usage, maintaining control over how it accomplishes the task.
What the model does not provide is just as important. A chat completion on its own can generate text, but it cannot decide what to do next, reach into external systems, or remember what happened yesterday — that is Amazon’s own framing of the gap an agent closes. The model has no persistence, no fresh facts, and no effects in the world; every one of those comes from another component. Memory design matters as well: the memory experiments described below show that storing and reusing what an agent has learned can improve its performance, so memory deserves design attention alongside the model.
Tools and function calling: how the agent acts
Tools are what turn a thinking system into a working one. A model on its own can only produce text. With tools, it can search the web, query databases, run code, send messages, and operate business software. A tool is a function with a name, a description, and a JSON schema for its parameters, and well-defined tools with clear descriptions and schemas are what enable the model to use them correctly.
Function calling is the mechanism that connects the model to its tools, and it is a strict handshake. You declare the functions to the model; the model returns a structured function call naming the function and its arguments, with an ID tying the call to its result; your code executes the function and sends the result back. The model never executes anything itself. In OpenAI’s Responses API the result is returned as a function-call output matched to the call ID, and strict mode makes constrained decoding guarantee the model’s output conforms to the schema. Parallel tool calls are on by default for current models and can be disabled when one tool’s output is meant to feed the next.
Two practical points come from the providers’ own guidance. First, keep the tool list short: OpenAI suggests fewer than 20 functions available at the start of a turn, and Google suggests keeping the active set to 10 to 20. Second, tools do not have to be written by hand for each model: the Model Context Protocol, introduced by Anthropic in late 2024, is the open standard for connecting agents to tools consistently, and the OpenAI Agents SDK lets you declare a tool with a decorator and use hosted tools such as web search, file search, and code interpretation in the same list as your own functions.
Memory: short-term context and long-term recall
Memory is how an agent maintains state. Without it, every invocation starts from scratch. The sources describe three kinds. In-context memory is the current conversation inside the model’s context window. External short-term memory covers a session or a task — a Redis store, an in-memory store, or a scratchpad file. External long-term memory persists across sessions — a vector database, SQL, or the file system.
Anthropic’s November 2026 post on agent memory layers the same idea differently: transcripts are a searchable log, memory notes are things the agent writes down during or after a session, wikis are linked pages built from those notes, and a small injected context loads into every new session. Between sessions the agent runs a step Anthropic calls dreaming, reviewing old transcripts, fixing wrong notes, and deciding what to preload. On a company wiki of about 350,000 files, accuracy rose from 13% to 48% over 128 dreaming sessions; wiki plus search reached 61% against 53% for search alone, and saved about 20,000 tokens per question. On a database task, the same work moved mean reward from 0.655 to 0.838 with memory. These are Anthropic’s own benchmarks on its own models, as reported — test them on your own data before rebuilding around them.
What goes wrong when memory is missing is easy to see: the agent repeats itself, re-asks questions it already asked, and forgets the goal mid-task. When context runs short, the evidence points to managing what is kept rather than keeping everything: notes the agent writes for itself, external storage for what must persist, and a small injected context that loads only what the next session needs.
Planning and reasoning: the loop that decides what happens next
Planning is how an agent breaks a complex goal into a sequence of steps. Without effective planning, multi-step work can lose direction, fail to adapt, or loop. The most widely used planning pattern in the sources surveyed is ReAct — Reason + Act — introduced by Yao and colleagues in 2022: the model interleaves short reasoning traces with actions, so reasoning guides acting and acting grounds subsequent reasoning. On interactive decision-making benchmarks it outperformed imitation and reinforcement learning methods by 34 percentage points on ALFWorld and 10 percentage points on WebShop, using only one or two in-context examples.
Planning can live in code or in the model. In a workflow, the plan is written down in advance: predefined code paths decide what happens next. In an agent, the model decides the next step itself, and revises the plan as new information arrives — that revision is part of what Amazon lists under planning. The two are not rivals: the practical advice from Anthropic is to start with the simplest solution possible and only add complexity when needed, which often means a workflow first and an agent only when the task genuinely needs the model to choose its own steps.
Perception and guardrails: inputs, outputs, and limits
Perception is the component that collects and cleans inputs: user messages, files, events, and tool results. A typical architecture lists it as the first layer — before the reasoning core, the planner, memory, and the tool layer — because nothing else in the system can work with input it has not received. Some sources list perception as a separate component; others fold input handling into the surrounding system. Either way, it is the boundary between the system and the world it operates in.
Guardrails are different: they are a layer around the components, not a component beside them. Amazon’s reference architecture routes a request through guardrails and lists resilience and observability as cross-cutting concerns, with human review in the flow. In practice that means validation of inputs and outputs, permission checks before a tool runs, and stop conditions on the loop. LangGraph’s checkpointing makes this concrete: because state is saved at each step, execution can be interrupted and resumed, which is what allows a human approval step before a consequential action — a system could, for example, pause before a refund tool runs while it waits for a human decision. The guardrail does not do the work; it decides whether the work may proceed.
Orchestration: how the components fit together
Orchestration is the runtime that runs the loop: it calls the model, executes the tools the model requests, appends the results, manages state between steps, decides when to stop, and surfaces output to the user. The walk-through below is illustrative — not a recorded trace — and shows each component in turn on a single small task: a support agent answering “Where is my order?” It assumes a stated policy: read-only lookups need no separate approval prompt, while changes and purchases do.
Illustrative walk-through: "Where is my order?"
Perception: the user's message arrives; the order number is read from it.
Memory: the agent recalls this user's past orders from long-term memory.
Planning: the model reasons that it needs the order status before answering.
Tools: the agent calls get_order_status with the order number.
Observation: the tool returns "order not found".
Planning: the model re-reads the message, spots a transposed digit, and tries again.
Tools: the agent calls get_order_status with the corrected number.
Observation: the tool returns "shipped, arriving Thursday".
Planning: the model decides the answer is ready and no further action is needed.
Output: the agent replies with the status and the delivery day.
Guardrails: a permission check runs before any order data is read; read-only lookups need no separate approval under the stated policy.Who owns the loop depends on the framework. LangChain’s create_agent is the factory that builds it as a compiled LangGraph graph from a model, tools, and a system prompt, extended with middleware; a checkpointer persists state per conversation thread, and without one each call starts empty. LangGraph exposes the same loop as a graph: an agent node that calls the model, a tools node that executes the requested tools, and a router that sends the run back to the agent node while tool calls remain. The OpenAI Agents SDK takes the same shape with a decorator: a function marked as a tool joins the agent’s tool list, and hosted tools such as web search, file search, and code interpretation sit in the same list as custom ones. Three frameworks, one loop — the components are the same, only the vocabulary changes.
What breaks when a component is missing
Each missing component has a characteristic failure. Without memory, the agent repeats itself and forgets the goal: every invocation starts from scratch. Without planning, multi-step work can lose direction, fail to adapt, or loop. Without tools, the model can only produce text — it can describe what it would do, but it cannot look anything up or change anything. Without guardrails, there is nothing to stop an irreversible call: a support agent that can refund without approval is a liability, not a feature.
The audit is therefore short. Ask of any agent system: does it remember across turns and across sessions, and where does that memory live? Does it plan — in code, in the model, or both — and can the plan change when the evidence changes? Are its tools named, described, and few enough for the model to choose well? Is there a loop with a stopping condition, and a human approval step before consequential actions? Treat the answers as an architecture audit, not a classification test: what distinguishes an agent from a workflow is whether the model dynamically directs the process, and persistent recall or human approval are design choices to weigh, not universal requirements for being an agent.
