The components of an AI agent break down into four parts, no matter the framework: a reasoning model, tools, memory, and orchestration. Learn what each one does and you can read almost any agent architecture diagram you come across.
Frameworks like LangGraph or CrewAI package these four pieces differently, but they don't add new categories — they just make each one easier to configure.
1. The reasoning model
The reasoning model is the language model at the center of the agent — the part that decides what to do next. Given the goal, the conversation so far, and any results from previous actions, it chooses the next step: which tool to call, what to say, or when to stop.
This is the component doing the actual "thinking," and it's also usually the most swappable one. Many frameworks let you plug in different models depending on the task — a faster, cheaper model for simple steps and a stronger one for harder reasoning.
2. Tools
Tools are how an agent affects or queries anything outside the conversation. A tool is just a function with a defined input and output — search the web, run a snippet of code, query a database, call a payment API, click a button in a browser.
Without tools, an agent is just a chatbot that talks about doing things instead of doing them. See tool calling explained for how the model actually decides which tool to use and with what arguments.
Common tool categories:
- Information retrieval — web search, document search, database queries.
- Computation — running code to get an exact answer instead of a guess.
- Communication — sending an email, posting a message, updating a ticket.
- Environment control — browser or desktop automation, sometimes called computer-use agents.
3. Memory
Memory is what lets an agent avoid repeating itself and build on what it's already learned during a task. It usually comes in two forms:
- Short-term memory — the history of the current task: what's been tried, what came back, what's left to do. This typically lives in the model's context window for the duration of one run.
- Long-term memory — facts, preferences, or past outcomes that persist across separate sessions, usually stored in a database the agent can query when it needs them.
Without memory, an agent can get stuck retrying the same failed action indefinitely, because it has no record that the action already failed.
4. Orchestration
Orchestration is the logic that actually runs the loop: it decides when to call the reasoning model, when to call a tool, when to check memory, and — critically — when to stop. It's the scaffolding around the other three components, not a component that "thinks" on its own.
Orchestration is also where guardrails live: limiting which tools an agent can call, capping the number of steps, and routing certain actions to a human for approval before they execute. This is the piece frameworks like LangGraph specialize in — see how to choose an AI agent framework for how different tools handle it.
The components of an AI agent, fitted together
| Component | Question it answers | Common examples |
|---|---|---|
| Reasoning model | What should happen next? | An LLM like Claude or GPT |
| Tools | How does the agent act? | Search, code execution, APIs |
| Memory | What has already happened? | Context window, vector database |
| Orchestration | When does each piece run, and when does it stop? | LangGraph, CrewAI, a custom loop |
Put together, these four components form the agent loop: orchestration triggers the reasoning model, the model picks a tool, the tool acts, memory records the result, and the cycle repeats until the goal is met.
A simple example, component by component
Say the goal is: "Summarize this week's support tickets and flag any that need urgent follow-up."
- Reasoning model decides to first pull the tickets, then read them, then classify urgency.
- Tools include a database query to fetch tickets and, potentially, a messaging API to send the flagged list.
- Memory tracks which tickets have already been read and classified during this run.
- Orchestration runs the loop: query, read, classify, repeat until every ticket is covered, then send the summary and stop.
Nothing about that example needs a specific framework — it's the same four pieces you'd find in any agent, hand-built or not.
FAQ
Do all four components need to be separate systems?
No — in a simple agent, all four can live in one script: a loop (orchestration) that calls an LLM (reasoning), which picks from a few Python functions (tools), while the conversation history (memory) is just a list variable. Frameworks become more valuable as the agent grows more complex, not as a requirement from day one.
Which component is hardest to get right?
Orchestration tends to cause the most real-world problems, because it's where stopping conditions, error handling, and guardrails live — get those wrong and an agent either gives up too early or loops indefinitely on a broken plan. See AI agent error handling for how well-designed systems handle this.
Is memory the same thing as the model's context window?
Short-term memory often is just the context window, but long-term memory usually isn't — it's typically an external database the agent queries when it needs something from a previous session, since context windows don't persist between separate runs.
Do I need to understand all four components before building an agent?
Understanding what each component does conceptually will make any framework you pick up afterward far less confusing, since every framework is just a specific way of wiring these same four pieces together. You don't need deep expertise in each one before starting — a working mental model of all four gets you further than mastery of just one.