This article is published in English.
Inside an AI Agent: Models, Tools, Memory, and Reasoning Explained
Breaks down the core architecture of AI agents—goals, models, tools, memory, and reasoning—and walks through a practical Python-based research agent example.
In the first installment of AI Agents with Python 2026, we tackled a foundational question:
What exactly is an AI agent?
We looked at how traditional software differs from chatbots, generative AI systems, and agents that pursue goals on their own. We also laid out the core building blocks that make up an agent — models, tools, memory, knowledge, actions, and safety mechanisms.
This time, we're going to open the hood and look at the machinery inside.
What actually happens when an agent runs?
How does it choose its next move?
How does it pick the right tool for the job?
How does it retain information across steps?
And how does it recognize that a task has been completed?
Welcome to Part 2 of this series — moving from simple automation toward genuinely autonomous systems.
The Architecture of an AI Agent
At a conceptual level, an AI agent stitches together a handful of components in a repeating cycle:
Goal → Model → Decision → Tool → Observation → Next Decision → Result
A stripped-down version of this architecture might look like this:
USER / APPLICATION
│
▼
┌──────────────┐
│ GOAL │
└──────┬───────┘
│
▼
┌──────────────┐
│ AI MODEL │
│ LLM / Model │
└──────┬───────┘
│
▼
┌──────────────┐
│ DECISION │
│ / PLANNING │
└──────┬───────┘
│
┌─────────┼─────────┐
▼ ▼ ▼
TOOL 1 TOOL 2 TOOL 3
│ │ │
└─────────┼─────────┘
│
▼
OBSERVATION
│
▼
┌──────────────┐
│ NEXT ACTION? │
└──────┬───────┘
│
┌──────┴──────┐
│ │
YES NO
│ │
▼ ▼
Continue Result
Keep in mind this is a simplified picture.
Production-grade agent systems are typically far more elaborate, but grasping this core loop gives you a solid starting point for everything that follows.
1. The Goal
Every agent's behavior starts with a goal.
The system needs a concrete understanding of what it's supposed to achieve.
Consider this example:
"Analyze this month's sales data and identify the three products with the largest decline."
A goal sets the direction for the entire process.
When the objective isn't clearly stated, the agent risks producing off-target answers or taking actions that don't actually help.
A well-formed goal typically spells out:
- The task to be completed
- The data or information that matters
- The expected form of the output
- Any limits or constraints to respect
Take these two versions:
Weak goal:
"Analyze the data."
Stronger goal:
"Look at the sales dataset, flag any product whose monthly revenue dropped by more than 10 percent, and put together a table summarizing the findings."
Compared to the vague version, this phrasing hands the agent a much clearer target to work toward.
2. The AI Model
The model acts as the reasoning and language engine at the heart of most modern agents.
Large Language Models (LLMs) earn their place here because they're capable of:
- Parsing natural language input
- Making sense of instructions
- Weighing contextual information
- Producing well-structured output
- Choosing among possible actions
- Constructing the arguments a tool needs
That said, the model is just one piece of the puzzle.
Picture it as the brain within a larger organism.
A brain isolated from eyes, hands, memory, and the outside world can't do much on its own.
The same holds for an LLM — its usefulness multiplies once it's wired up to relevant tools and data sources.
3. Instructions and Context
The model needs to know its role and the specifics of the current task.
This typically includes:
- System-level instructions
- Instructions coming from the user
- A list of tools it can call
- Prior conversation history
- Data pulled in through retrieval
- The current state of the task
- Any rules or boundaries it must respect
As an illustration, an agent built to support an IT helpdesk might be configured with something like:
You are an IT support assistant.
Your responsibilities:
1. Diagnose common technical issues.
2. Search the approved knowledge base.
3. Provide troubleshooting instructions.
4. Escalate high-risk issues to a human technician.
Do not modify production systems without authorization.
Instructions like these shape how the agent is expected to behave.
4. Tools
While a model can produce text and reasoning, tools are what let an agent actually reach out and touch external systems.
Common categories of tools include:
- Web search
- External APIs
- Databases
- File systems
- Calculators
- Custom Python functions
- Email integrations
- Calendar integrations
- Line-of-business applications
Consider an assistant tasked with reporting the current weather.
The model's built-in knowledge won't include live conditions.
So instead, the agent reaches out to a weather API through a tool call.
The flow looks roughly like this:
User Request
↓
AI Model
↓
Weather Tool
↓
Current Weather Data
↓
AI Model
↓
Response
The tool supplies data the model has no reliable way of producing by itself.
Tool Calling
A key idea in agentic systems is what's known as tool calling.
Rather than only generating a plain-text reply, the model can flag that a specific tool needs to run.
For instance:
tools = [
"search_database",
"calculate",
"get_weather"
]
Say a user asks:
"What is the weather in Accra?"
The model might recognize that get_weather is the right tool for this request.
The surrounding application then runs that function and feeds the result back into the model.
In Python, this might be expressed simply as:
def get_weather(city):
# Call an approved weather service
return weather_data
The essential rule here is that the model proposes what it needs, but the application retains control over what actually gets executed.
That separation matters a great deal for security.
Models Shouldn't Have Unlimited Access
Imagine handing an AI model unrestricted control over:
- Your database
- Your email accounts
- Your file system
- Your financial systems
- Your operating system
That kind of exposure would introduce serious risk.
Agents should instead be granted only the access they genuinely require to do their job.
This mirrors a well-known idea from security engineering:
Principle of Least Privilege
Grant a system only the permissions it truly needs to carry out its job, nothing more.
For instance:
A customer-support agent might legitimately need to read customer records.
But it likely has no reason to delete those records.
This idea will come up again in more depth when we cover agent security later in this series.
5. Memory
Memory lets an agent hold on to information that matters across a conversation or task.
Without it, each exchange would feel disconnected from the last.
Picture a personal AI assistant.
You mention:
"My preferred programming language is Python."
Then later you ask:
"Recommend a programming project for me."
If the assistant has working memory, it can connect these two moments and tailor its answer using what you told it earlier.
Memory isn't a single concept — it operates at different scopes.
Short-Term Memory
Short-term memory covers details that are only relevant within the current session or task.
User:
My budget is GHS 5,000.
User:
Show me laptops.
Agent:
I'll focus on options around your GHS 5,000 budget.
Without holding onto the budget mentioned earlier, the agent wouldn't know how to properly scope its laptop recommendations.
Long-Term Memory
Long-term memory persists beyond a single conversation.
User Preference:
Prefers Python tutorials.
Previous Project:
Built an AI study assistant.
Current Goal:
Learning AI agents.
An application typically stores this kind of data in a dedicated database or memory layer.
That said, saving personal details raises privacy questions that shouldn't be brushed aside.
You'll need to think through:
- What information is worth remembering
- How long it should be kept
- Where it gets stored
- Who is allowed to access it
- How a user can have it removed
Memory should never be an afterthought — it needs deliberate design.
6. Knowledge
Memory and knowledge sound similar but serve different purposes.
Memory typically tracks details about the user, the conversation, or the task's current state.
Knowledge retrieval, on the other hand, means pulling in relevant facts from external sources.
Consider a corporate AI agent that may need to reference:
- Employee policies
- Product documentation
- Technical manuals
- Internal procedures
- Frequently asked questions
Rather than stuffing every document into the prompt, the system can fetch only what's relevant at the moment it's needed.
This is the foundation of an important pattern in AI architecture:
Retrieval-Augmented Generation (RAG)
At a high level, a RAG pipeline looks like this:
User Question
↓
Retrieve Relevant Information
↓
Knowledge Source
↓
Relevant Context
↓
AI Model
↓
Answer
RAG becomes especially valuable once it's paired with agents.
An agent can recognize that it lacks certain information, go fetch the relevant content, and then continue the task using what it found.
We'll dig into this pattern more thoroughly in Part 6.
7. Reasoning and Planning
One of the more compelling capabilities of AI agents is breaking down a large task into a sequence of smaller, manageable steps.
Say a user asks the agent to put together a comparison of three cloud providers aimed at a small business.
Completing this might require:
- Identifying the platforms
- Gathering pricing details
- Comparing features
- Weighing advantages and disadvantages
- Organizing the findings
- Producing the final report
The agent may need to figure out, dynamically, what step makes sense next based on what it currently knows.
That's the role planning plays.
Planning Does Not Always Mean Complex Reasoning
Don't assume every agent requires an elaborate, fully autonomous planning engine.
Some workflows can stay straightforward:
Input
↓
Call API
↓
Format Result
↓
Return Response
Others genuinely call for something more elaborate:
Goal
↓
Plan
↓
Research
↓
Analyze
↓
Verify
↓
Generate
↓
Review
↓
Complete
Which one fits depends entirely on the problem you're solving.
Worth repeating:
Pick the simplest architecture capable of solving the problem reliably.
8. Observation
Once an agent takes an action, it needs feedback on what actually resulted.
That's the observation step.
Agent:
Search for information about Python.
Tool:
Returns 20 search results.
Agent:
Analyze the results and determine which are relevant.
The data that comes back becomes an observation the agent factors into its next move.
Together, this forms a repeating cycle:
Think → Act → Observe → Decide → Act Again
The Agent Loop
With all the pieces in place, here's how they fit together:
┌──────────────┐
│ GOAL │
└──────┬───────┘
↓
┌──────────────┐
│ CONTEXT │
└──────┬───────┘
↓
┌──────────────┐
│ AI MODEL │
└──────┬───────┘
↓
┌──────────────┐
│ DECISION │
└──────┬───────┘
↓
┌──────────────┐
│ TOOL │
└──────┬───────┘
↓
┌──────────────┐
│ OBSERVATION │
└──────┬───────┘
↓
┌──────────────┐
│ COMPLETE? │
└───┬──────┬───┘
│ │
NO YES
│ │
↓ ↓
Continue Result
Understanding this loop is essential to understanding how agentic systems operate.
A Practical Example: Research Agent
Let's walk through a simple research agent design.
Imagine a request asking the assistant to look into how small businesses in Ghana could benefit from adopting solar power, and to put the findings into a short summary.
Handling that could break down into the following stages.
Step 1 — Understand
Pin down:
- The topic
- The geographic focus
- The intended audience
- What the output should look like
Step 2 — Plan
Figure out what information is actually required.
Step 3 — Retrieve
Pull data from approved sources.
Step 4 — Analyze
Examine what was retrieved.
Step 5 — Organize
Sort the findings into logical categories.
Step 6 — Generate
Draft the requested summary.
Step 7 — Review
Confirm the output actually addresses the original request.
Step 8 — Return
Deliver the final answer.
This illustrates a goal-driven agent workflow in practice.
What Happens When a Tool Fails?
In the real world, things break.
APIs go down.
Databases time out.
Searches return irrelevant results.
Tools sometimes send back malformed data.
A well-built agent has to account for these scenarios.
For example:
try:
result = get_data()
except Exception as error:
print("Tool failed:", error)
Production-grade systems typically need far more robust handling than this.
Depending on the situation, the agent might:
- Retry the failed step
- Switch to a different approved tool
- Ask the user for more detail
- Escalate the issue to a human
- Halt safely rather than proceed blindly
Handling failure gracefully is a core part of agent design, not an edge case.
Human-in-the-Loop
Automation shouldn't extend to every decision.
Some actions genuinely need a human to sign off first.
For example:
AI Agent
↓
Prepare financial transaction
↓
Human Approval
↓
Execute Transaction
This pattern is known as Human-in-the-Loop (HITL).
It's especially valuable whenever an agent is capable of taking high-stakes actions, such as:
- Financial transactions
- Deleting data
- Sending sensitive messages
- Modifying production systems
- Approving major decisions
Adding a human checkpoint can dramatically limit the damage from an agent's mistakes.
Deterministic vs Agentic Workflows
There's one more distinction worth understanding.
A deterministic workflow follows a fixed sequence of steps:
Step 1 → Step 2 → Step 3 → Step 4
An agentic workflow, in contrast, decides on the fly what to do next:
Goal
↓
Decision
↓
Action
↓
Observation
↓
Next Decision
Neither one is inherently the better choice.
For tasks that are predictable and well-understood, a deterministic workflow is often easier to test, monitor, and lock down securely.
When conditions are uncertain and requirements keep shifting, giving an agent room to decide its own path tends to work better.
Neither pattern wins in every situation. Choosing between them is simply part of doing good engineering.
Where Python Fits
Python is well suited to serve as the glue that ties an agent's pieces together.
A stripped-down architecture might resemble the following:
Python Application
│
├── AI Model
│
├── Tools
│
├── APIs
│
├── Database
│
├── Memory
│
└── RAG / Knowledge Base
Python handles the coordination between these pieces and carries the surrounding business logic.
This is part of why Python has become such a strong fit for building AI systems.
A Simple Python Agent Architecture
Here's a conceptual sketch of a minimal agent:
class SimpleAgent:
def __init__(self, model, tools):
self.model = model
self.tools = tools
def run(self, goal):
context = goal
while True:
decision = self.model.decide(
context,
self.tools
)
if decision["action"] == "finish":
return decision["result"]
tool = self.tools[decision["tool"]]
result = tool(**decision["arguments"])
context = {
"goal": goal,
"previous_result": result
}
This example is deliberately bare-bones.
A real, production-ready agent would need a lot more supporting infrastructure, such as:
- Checks on incoming data
- A way to verify who's calling the system
- Handling for failures along the way
- A record of what happened and when
- Rules about which tools can be used
- Tracking of the agent's ongoing state
- Broader safeguards against misuse
- Visibility into what the system is doing
- Controls to keep spending in check
- Boundaries on how long the loop can run
Even so, the snippet captures the essential flow:
Take in a goal → make a decision → call a tool → observe the outcome → keep going or stop.
Why Agent Loops Need Limits
Picture an agent that keeps concluding it needs to take just one more action.
Without a cap, it might run forever.
Left unchecked, this can result in:
- Runaway API costs
- Sluggish responses
- Excess resource use
- Repeated, redundant actions
- Unpredictable behavior
To guard against this, developers should build in controls like:
- A ceiling on iterations
- Time limits on execution
- Caps on tool calls
- Spending limits
- Mandatory approval steps
For instance:
MAX_STEPS = 10
The system can halt the agent once it crosses the allowed step count.
A safeguard this simple can be enough to stop workflows from spiraling out of control.
Security Is Part of the Architecture
Security for an agent isn't something you bolt on after the fact.
It needs to be baked in from day one.
Key areas to think through include:
Authentication
Who's permitted to interact with the agent?
Authorization
What resources is the agent cleared to touch?
Input Validation
What kind of input are users allowed to submit?
Tool Permissions
Which functions is the agent actually able to run?
Data Protection
What sensitive data might the agent be exposed to?
Logging
What did the agent actually do, step by step?
Human Approval
Which actions need a person's sign-off before they happen?
These concerns only grow more critical as agents gain more capability.
The Agent Stack
An AI agent can also be viewed as a layered technology stack:
┌──────────────────────────────┐
│ USER / GOAL │
├──────────────────────────────┤
│ AGENT LOGIC │
├──────────────────────────────┤
│ AI MODEL / LLM │
├──────────────────────────────┤
│ TOOLS & FUNCTIONS │
├──────────────────────────────┤
│ MEMORY & STATE │
├──────────────────────────────┤
│ KNOWLEDGE / RAG │
├──────────────────────────────┤
│ APIs & DATABASES │
├──────────────────────────────┤
│ SECURITY / GUARDRAILS / LOGS │
└──────────────────────────────┘
Each layer serves its own purpose.
Getting comfortable with these layers makes designing and debugging agents far more manageable.
A Beginner's Mental Model
While you're getting started with agents, keep these six questions in mind:
1. What is the goal?
What outcome is the system supposed to deliver?
2. What does the model need to understand?
What instructions and context does it require to do the job?
3. What tools are available?
What outside capabilities can it call on?
4. What information does it need?
Where does its knowledge actually come from?
5. What actions can it take?
What is it actually permitted to do?
6. What happens if something goes wrong?
How does the system respond when something breaks?
Being able to answer these six questions means you're already reasoning like someone who builds agents.
Your Practical Exercise
Before moving on, try sketching an agent design on paper.
Pick a scenario, for example:
AI Study Assistant
Then work out:
Goal:
Support students in understanding their study materials.
Model:
A language model.
Tools:
A document reader and a calculator.
Knowledge:
The course materials themselves.
Memory:
The current study session.
Actions:
Producing explanations and generating practice questions.
Guardrails:
Never invent facts when the relevant course material isn't available.
Human Oversight:
The student checks over whatever the agent produces.
At this point, you've sketched out a working agent architecture.
What's Coming in Part 3?
With the architecture in hand, the next step is turning it into working code.
Part 3 will cover building your first simple AI agent with Python.
You'll move from diagrams and theory into actual implementation, and you'll come away knowing how to get an agent project up and running, wire Python up to a language model, spell out a clear goal for the agent, put together a basic tool for it to use, let it invoke that tool, work with whatever the tool hands back, and finally produce a finished answer.
The first version will be kept deliberately minimal.
The goal at this stage is grasping how the pieces fit together, not shipping a fully hardened production system right away.
Final Thoughts
An AI agent is more than a chatbot wearing a new label.
It's a system built around a goal, given the means to work with information and act through tools.
At its core, the architecture boils down to:
Goal → Model → Decision → Tool → Observation → Next Action → Result
Layered around that core, you add:
Memory + Knowledge + Security + Guardrails + Human Oversight
Once these pieces click, agentic AI stops feeling like magic.
It turns into an ordinary software engineering challenge.
And that's precisely the kind of challenge Python is well equipped to handle.
You now know what AI agents are and how they operate.
The next step is building one yourself.