Almost everything gets called an AI agent right now. A chatbot with a system prompt. A script that calls an API. A workflow with a language model somewhere in the middle. The word has stretched far enough that it has stopped carrying information.
The distinction that actually matters is simple. A chatbot answers. An agent acts.
I am building agent frameworks from scratch at the moment to understand the internals properly, and this is the first of twelve posts working through what is inside one. By the end we will have built something that can answer a question no single model call can reach: whether routing our routine support tickets to an agent would actually pay for itself. Answering that needs a file read, a price looked up, and arithmetic over both, which turns out to be the shortest route to understanding why agents exist at all.
You need to be able to read Python. Nothing else is assumed. Here is what is inside an agent, in plain terms.
The five characteristics and three components that make up an AI agent
Five things have to be true
Autonomy. The agent operates on its own and performs multiple steps toward a goal without a human approving each one. This does not mean fully unsupervised. Good designs keep a person in the loop for risky actions. But if someone signs off on every step, you have a workflow, not an agent.
Perception. The agent perceives its environment, digital or physical. That input arrives structured, like API responses, and unstructured, like natural language, audio and images. It uses this to assess its current state, its context, and what has changed. Turning that mess into a usable internal representation is a genuinely hard engineering problem. Raw web data alone comes in countless formats, resolutions and quality levels, and all of it has to be parsed, validated and standardised before anything can reason over it.
Reasoning and planning. Once the agent perceives something, it reasons about it and decides what to do next. It identifies goals, evaluates possible actions, and forms or updates a plan. Planning is what lets it look ahead and choose a sequence of actions rather than only reacting to the last thing that happened.
Action. The agent takes actions in its environment: invoking a tool, calling an API, generating a response, triggering a workflow, controlling a device. This is the core function, and the thing that separates an agent from a very capable writer. It also needs the right access and permissions to actually carry those actions out.
Learning and adaptation. A more advanced agent learns from experience. It updates internal memory, adjusts strategy, and refines behaviour over time. Some agents learn offline from training data, others online from live interaction. That adaptation matters most in environments that keep changing.
Three components carry every agentic system
Whatever the architecture, any non-trivial agentic system has these three.
Memory. It lets the agent store and retrieve information about its environment, its past actions and what it has learned. It comes in three kinds worth knowing by name:
- Working memory maintains the current context window. The immediate, short-term scratchpad: every input and output token in the current session.
- Episodic memory tracks recent conversations and events, stored across sessions. This is what lets a system recall specific exchanges or past behaviour, which is where continuity and personalisation come from.
- Semantic memory is the facts and concepts learned over time. A long-term store of structured knowledge: general world facts, domain-specific information, conceptual relationships.
Tools. External resources or APIs the agent uses to act. If the model is the brain, tools are the eyes, ears and limbs that let it sense and operate on its environment. Without tools, a system can only give advice based on what you typed. With them, it has actual agency.
Orchestration. The coordination layer that makes the other parts work together. It manages the flow of information between agents, tools and memory, and handles interaction with external systems and with people. Orchestration can run through a central controller, or emerge from agents communicating directly with each other. How much human involvement sits in that flow is a design choice.
Four architectures, and when each fits
Single-agent loop. One agent perceives, reasons about its goals, and acts, cycling through observation, planning and execution. It suits tasks simple enough for one agent to hold, where the context window is large enough for the whole job. Typical uses: tool-augmented question answering (pairing the model with search, calculators or databases), monitoring devices such as air-quality sensors and raising an alert on an anomaly, or watching a code repository and commenting on changes.
Planner and executors. A planner agent reasons about the goal and decomposes it into subtasks, which it delegates to executor agents. Those executors are specialised, and each manages its own context and its own tools. Results flow back to the planner, which may adjust the plan and launch more executors. This suits work that exceeds a single agent: automated research and report generation, multi-step data pipelines, software refactoring and test planning, or coordinating several APIs at once.
Multi-agent systems. An extension where multiple agents with specific roles operate more like a human team than a hierarchy. They communicate with each other, share memory and iterate together. A coder agent finishes a module and notifies a tester agent, which tests it, while other coder and tester pairs work in parallel on other modules.
Graph-based. Agents, tasks, tool invocations and memory updates modelled as a graph. Each task or agent can spawn sub-agents dynamically, and the structure emerges from the results of earlier work. Counting the words in every file in a directory, for example, spawns one sub-agent per file and aggregates the results. LangGraph is the best-known framework here.
Its strength is that a problem decomposes naturally into a deep hierarchy. "Build a web application" becomes frontend, backend and database, each with its own tasks, each handled by specialists passing context down the graph. Its cost is coordination complexity: dependencies, message passing and error propagation get hard to scale and debug, and over-decomposition brings latency and brittleness when the work does not fit a clean tree.
Side by side:
| Architecture | Shape | Fits when |
|---|---|---|
| Single-agent loop | One agent cycling observe, plan, act | The whole job fits one context window |
| Planner and executors | A planner decomposes, specialists execute | The work exceeds what one agent can hold |
| Multi-agent | Peers with roles, sharing memory | The work looks like a team, not a hierarchy |
| Graph-based | Tasks and agents as a graph, spawned dynamically | The problem decomposes into a deep hierarchy |
The point
Autonomy, perception, reasoning, action and learning are what make something an agent. Memory, tools and orchestration are what it is built from. The architecture is how those parts are arranged.
Once you can name the parts, "AI agent" stops being a marketing word and becomes a design you can reason about, compare and question.