The Agentic AI Reference: Components, Memory and the Loop That Runs Them
What Actually Separates an Agent From a Chatbot
A chatbot answers. An agent decides, acts, checks the result, and decides again. That loop is the whole difference, and almost every term in the agentic vocabulary describes some part of it. This is a working reference for the pieces, how they fit together, and the order they run in.
Each layer inherits everything inside it. An agent is not a replacement for an LLM; it is an LLM with a loop, tools and memory wrapped around it.
The Six Components Every Agent Stack Has
Naming varies between frameworks, but the pieces do not. Whatever the library calls them, these six responsibilities exist somewhere in the system.
- Decides the next step
- Routes work between tools
- Owns the stop condition
- Interprets the goal
- Produces the plan
- Chooses which tool to call
- Search, calculators, code execution
- Database and third-party API calls
- Short-term conversation buffer
- Long-term vector store
- What survives between runs
- Validates inputs and tool arguments
- Blocks out-of-scope or destructive actions
- Traces every step and tool call
- Makes a failure explainable after the fact
The Loop, Step by Step
This is the part worth internalising. Everything above exists to serve this cycle, and when an agent misbehaves in production the fault is almost always locatable to one arrow in this diagram.
Two things in that diagram cause most real-world failures. The loop back from "Goal met?" to the planner is where an agent can spin indefinitely if the stop condition is weak. The branch at "Tool needed?" is where a model that is bad at tool selection burns budget calling the wrong thing repeatedly.
Memory Is Not One Thing
"The agent remembers" hides four different mechanisms with different lifetimes and different costs.
Short-term memory is just context window management. Long-term memory is retrieval, which is where RAG lives. Episodic memory is what lets an agent avoid repeating a mistake it already made, and it is the one most homegrown stacks skip.
The Tool Layer
Tools are the reason an agent can affect anything outside its own output. In practice a production agent has a small, well-described set rather than a large vague one, because tool descriptions compete for the same context the task does.
Web Search
Fresh information beyond the training cutoff
Code Executor
Runs generated code in a sandbox
SQL / Database
Structured queries against real data
File Reader
Parses documents into usable context
API Caller
Talks to internal and third-party services
Knowledge Base
Retrieval over your own documents
Building One Without the Usual Mistakes
- 1
Define the stop condition
Decide what "done" means before writing any loop
- 2
Start with one tool
Prove the call-observe cycle works end to end
- 3
Add memory deliberately
Pick the type the task needs, not all four
- 4
Wrap it in guardrails
Validate tool arguments; cap iterations and spend
- 5
Instrument before scaling
You cannot debug a loop you cannot trace
The order matters. Teams that add memory and multi-agent orchestration before they have tracing end up with a system that fails in ways nobody can explain.
Where the Words Get Confused
ReAct is the reason-then-act pattern most tool-using agents trace back to, introduced in 2022. RAG is retrieval, feeding real documents in as context; it is a technique an agent uses, not a kind of agent. Orchestration is coordinating steps or multiple agents, not the reasoning itself. MCP is a protocol for exposing tools to a model in a standard way, so the same tool works across different clients.
A useful test when someone says "we built an agent": ask what its stop condition is. If there isn't a clear answer, it is usually a chatbot with a function call bolted on.
If you want to build this properly rather than assemble it from blog posts, our Agentic AI course covers agent design patterns, tool calling, memory and guardrails, ending in a capstone agent rather than a slide deck.
