What Are the Core Components of an Agentic System?

Introduction

An AI agent may appear to behave like a single intelligent entity: give it a goal, and it decides what to do next. Underneath that behavior, however, is usually a collection of components working together.

Consider a scheduling agent given this request:

“Schedule a one-hour project review with Maya and Daniel next week. Avoid moving any existing customer meetings.”

Completing this task requires more than generating text. The system has to understand the constraints and use a calendar tool to choose an appropriate meeting time, then determine whether the result satisfies the request, and react if the environment changes. For example, if one attendee becomes unavailable before the meeting is created, a new time must be selected.

A useful way to think about an agentic system is therefore not as “an LLM with extra features,” but as a decision-and-action loop built around a model.

One practical foundation is the combination of a model, tools, and instructions(Ref: A Practical Guide to Building Agents by OpenAI). Across agent systems developed by frontier AI labs such as OpenAI, Anthropic, and Google, common building blocks include models, instructions, external tools, memory, planning, and feedback.

The exact architecture varies between systems. A planner or evaluator, for example, does not always exist as a separate model or software service. These terms are most useful as functional roles: things the system must accomplish somewhere in its workflow.

The model provides the reasoning capability

At the center of the system is the model, usually a large language model.

Its job goes beyond generating the final response. Within an agentic workflow, the model can interpret the user’s objective, reason about constraints, select tools, interpret observations, and decide what should happen next.

For the scheduling request, the model might recognize several requirements:

The model could then determine that it first needs calendar information before it can choose a time.

The model can decide what to do next, but the surrounding system is what lets it use tools, track progress, and respond to results.

A model alone could suggest, “Try Tuesday at 2 p.m.” An agent connected to the appropriate systems could determine whether Tuesday at 2 p.m. is actually available.

Tools let the agent interact with external systems

Reasoning alone cannot inspect a live calendar. That requires a tool.

Tools are interfaces that let an agent retrieve information or perform actions outside the model itself. Depending on the application, tools might provide access to:

For our scheduling agent, a calendar API might expose operations such as:

• Check availability
• Read event details
• Create event

The model can decide that it needs Maya and Daniel’s availability, but the tool is what retrieves that information.

This creates an important distinction:

Reasoning: “I need to find times when all three calendars are free.”

Action: Call the calendar availability tool with the correct attendees and date range.

Research on ReAct demonstrated this general pattern by interleaving model reasoning with actions that interact with external sources or environments. Rather than trying to answer everything from internal model knowledge, the system can act, obtain new observations, and then reason from those observations. (Ref: ReAct: Synergizing Reasoning and Acting in Language Models by Yao et al.)

Context and memory give the agent relevant information

As an agent takes multiple steps, the model needs more than the user’s original request. It also needs information collected during the task.

This is where context becomes important.

Context is the information currently made available to the model for its next decision. It might contain:

After checking the calendars, for example, the scheduling agent’s context might include:

Maya is free Tuesday 10–12 and Thursday 2–5.
Daniel is free Tuesday 11–3 and Thursday 1–4.

The next model decision can now use those observations.

Memory becomes useful when information must persist beyond the immediately available interaction or be selectively retrieved later.(Ref: Generative Agents: Interactive Simulacra of Human Behavior by Park et al.)

For example, the agent may have stored a preference that the user normally avoids meetings before 10 a.m. If that preference is relevant to the current task, it can be retrieved and added to the model’s context.

Memory stores information. 

Context is the information currently available for reasoning.

Not every piece of memory belongs in every model call. Agentic systems often need a way to retrieve only what is relevant.

State records where the task currently stands

Memory answers questions such as: “What information from the past might matter?”

State answers a different question: “What is true about this task right now?”

Halfway through the scheduling task, the state might look conceptually like this:

The agent can use this record to know what has already happened and what still needs to happen.

Without reliable state management, a multi-step agent can lose track of progress. It might repeat a search, forget a constraint, or attempt an action that has already been completed.

Context, memory, and state therefore overlap, but they serve different purposes:

Context supplies information to the current reasoning step.
Memory preserves information that may become useful again.
State represents the current status of the active task.

This separation becomes increasingly valuable as workflows grow longer.

The planner decides what should happen next

Once the system understands the goal and current state, it needs to determine the next action.

That is the role of planning.

At the beginning of the scheduling task, a planner might reason:

1. Retrieve all three calendars.
2. Identify overlapping one-hour windows.
3. Remove times that conflict with protected events.
4. Select the best remaining option.
5. Create the meeting.
6. Verify that the meeting appears correctly.

But planning does not have to mean generating a complete fixed plan at the beginning.

Suppose Thursday at 2 p.m. initially looks suitable, but Daniel adds another meeting before the agent creates the event. A rigid workflow could fail because its original plan is now outdated.

An agentic planner can instead use the latest state and observations to answer a more useful question:

“Given what I know now, what should I do next?”

This is one reason agent workflows are often represented as loops rather than straight pipelines. ReAct, for example, allows reasoning to update action plans as new observations arrive and exceptions occur. (Ref: ReAct: Synergizing Reasoning and Acting in Language Models by Yao et al.)

The executor turns decisions into actions

The planner may decide:

“Check whether Thursday from 2–3 p.m. is still available.”

Something then has to carry out that decision.

The executor is the part of the system responsible for turning intended actions into actual operations.

For example, it may:

1. select the calendar availability tool,
2. construct its required parameters,
3. submit the request,
4. receive the response,
5. return that result to the rest of the agent.

Planning and execution are therefore conceptually different.

The planner decides what should be done.

The executor handles doing it through the available interface.

They do not have to be implemented as separate models. A single LLM-based agent may both decide which tool to call and generate the tool arguments. Larger systems may separate planning from execution to improve control, reliability, or observability.

The distinction is architectural rather than prescriptive.

The evaluator asks whether the action actually worked

An action succeeding technically does not necessarily mean that the goal has been satisfied.

Imagine that the calendar API returns:

Event created successfully.

That sounds like success. But what if the event is only 30 minutes long? Or Daniel was accidentally omitted from the attendee list?

The system needs to compare the result with the original requirements.

That is the role of evaluation.

An evaluator might check:

Evaluation can take many forms. Some conditions can be checked with deterministic rules. Other tasks may use model-based evaluation, external tests, human approval, or direct signals from the environment.

The broader idea is that agents should not automatically assume action = success.

The Reflexion framework demonstrates one version of this feedback-oriented behavior: agents use feedback from previous attempts and store linguistic reflections that can influence later decisions. (Ref: Reflexion: Language Agents with Verbal Reinforcement Learning by Shinn et al.)

Environment feedback closes the loop

The final component is not inside the agent at all.

The environment is whatever external world the agent can observe or affect.

For a digital agent, this could include:

Every action can change, or reveal something about that environment.

In our example:

Agent checks calendar → Calendar returns availability.

The returned availability becomes a new observation.

Later:

Agent creates meeting → Calendar confirms creation.

Again, the environment provides feedback.

Or:

Agent attempts to create meeting → API reports that the selected time is no longer available.

That failure is also useful information.

The system can update its state, return to planning, select another time, and try again.

This creates the feedback loop at the heart of agentic behavior:

Reason → Act → Observe → Evaluate → Update → Reason again

Research systems such as ReAct explicitly interleave reasoning with environmental actions and observations rather than treating reasoning and acting as independent processes. (Ref: ReAct: Synergizing Reasoning and Acting in Language Models by Yao et al.)

Taken together, these components form a closed-loop system in which reasoning, execution, environmental feedback, evaluation, and state updates continuously influence what the agent does next.

The components form a system, not a checklist

Model, tools, instructions, memory, context, state, planning, execution, evaluation, and environmental feedback are useful concepts for understanding agent architecture, but they should not be interpreted as a mandatory list of separate software modules.

A simple agent might rely on one model call to interpret instructions, choose a tool, and evaluate its result.

A more complex application might maintain explicit state, retrieve long-term memories, use one component for planning, another for tool execution, and separate evaluators for checking outcomes.

The architecture depends on the task.

What connects these systems is the same underlying pattern:

The agent maintains information about a goal, decides what to do, acts through available capabilities, observes what happened, and uses that feedback to decide what comes next.

Understanding these components separately makes it easier to understand more advanced agent architectures later. But their real value appears when we see how they work together: not as isolated building blocks, but as parts of a continuously updated decision-and-action process.

Videos

• This “Agentic AI 101 | NVIDIA GTC” session from NVIDIA Developer explains the internal building blocks that make an AI system agentic. The 8:23–18:18 segment covers long-term memory, multiple models, skills and tools, access to structured and unstructured data, tool selection, and orchestration between specialized agents. (Runtime: ~10 mins)

• This “Full Course (Lessons 1–10) AI Agents for Beginners” from Microsoft Developer course provides practical explanations of several components discussed in this article. The most useful sections are 14:14–19:35 (How to design good AI agents), 19:35–25:47 (Agent Tool Use Design Pattern), and 38:54–44:20 (AI Agent Planning Design Pattern). Together, these sections show how agent design, tool use, and planning fit into a broader agentic workflow without requiring readers to watch the entire course. (Runtime: ~17 mins)

References

• OpenAI. A Practical Guide to Building Agents. OpenAI, 2025.
• Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., & Cao, Y. ReAct: Synergizing Reasoning and Acting in Language Models. International Conference on Learning Representations (ICLR), 2023.
• Park, J. S., O’Brien, J. C., Cai, C. J., Morris, M. R., Liang, P., & Bernstein, M. S. Generative Agents: Interactive Simulacra of Human Behavior. ACM Symposium on User Interface Software and Technology (UIST), 2023.
• Shinn, N., Cassano, F., Berman, E., Gopinath, A., Narasimhan, K., & Yao, S. Reflexion: Language Agents with Verbal Reinforcement Learning. Advances in Neural Information Processing Systems (NeurIPS), 2023.

Related Articles

• What Is the Agentic Loop?
• What is function calling in LLM applications?