How AI Agents Work — Memory, Tools, Planning and MCP Explained | AI Agents Course Day 2 of 5

Day 1 established what an agent is and why the loop matters. Today goes inside the loop — the mechanisms that make it work, the constraints that make it fail, and the protocol that made 2026’s agent boom possible. The DNS lookup tool on SecurityElites illustrates the tool selection concept neatly: an agent given a domain investigation task would call that tool as one action in its loop — perceive the domain, plan a lookup, execute the tool call, observe the result. Today you’ll understand exactly how that decision to call a specific tool gets made.

The Three Types of Agent Memory

Memory is what allows an agent to maintain coherence across a task longer than a single exchange. Without memory, every loop iteration would start from scratch. With memory, the agent can track what it’s done, what it found, what went wrong, and what it still needs to do. There are three distinct types of memory in agent systems, and understanding the difference between them is essential for understanding why agents behave the way they do.

Type 1 — In-Context Memory. This is the agent’s working memory — everything currently in the conversation window. The original instruction, every tool call made so far, every result received, every observation noted. In-context memory is fast, immediately accessible, and directly influences every planning decision. It’s also strictly limited by the model’s context window. When the context fills up, older information gets pushed out. This is why long tasks can cause agents to “forget” earlier steps — the records of those steps have been pushed out of the working memory.

My rule for in-context memory: it’s reliable for tasks that complete in under thirty to forty loop iterations for current frontier models. For longer tasks, you need external memory.

Type 2 — External Memory. Storage outside the conversation window that the agent can explicitly read from and write to. This might be a database, a vector store (for semantic search over past information), a file system, or a key-value store. The agent reads external memory by making a tool call: “retrieve notes about this project,” “search the knowledge base for previous findings,” “read the saved state from yesterday’s session.” External memory removes the context window constraint — an agent can maintain coherent state across tasks that take days or weeks if it’s properly writing and reading external memory at each loop iteration.

The security implication of external memory is significant. What an agent writes to external storage persists. If an agent is manipulated into writing false information to its own memory, every future task that reads from that memory will be operating on corrupted data. This is a class of attack I find particularly interesting because it’s durable — the compromise outlasts the individual task.

Type 3 — Episodic Memory. The agent’s record of past completed tasks — what goal was given, what approach worked, what failed, and what the final result was. Episodic memory is what allows agents to improve over repeated similar tasks. The first time an agent researches AI security news, it might try five different approaches before finding the most efficient path. With episodic memory, the second time it runs a similar task it retrieves: “last time I searched X first, then Y, and the results from Y were better — start there.” This is a primitive form of learning from experience without retraining the underlying model.

The Context Window — The Agent’s Working Memory Limit

The context window is the maximum amount of text the model can process at once — everything it can “see” in a single inference call. This is the hardest constraint in agent design, and the one that most beginners underestimate.

Current frontier models have context windows ranging from 128,000 to 1,000,000 tokens (roughly 100,000 to 750,000 words). That sounds enormous, and for many tasks it is. But agent tasks fill context faster than you’d expect. Every loop iteration adds: the tool call itself, the tool result, the agent’s observation, and any planning notes. A research task that makes twenty web searches, reads each result, and produces summaries has generated roughly 40,000–80,000 tokens by the time it finishes — easily half a 128K context window, just for the working trace of the task.

When the context fills, the model can no longer see earlier parts of the conversation. The original instruction might still be there (most frameworks keep the system prompt anchored at the beginning), but the records of steps taken in the middle of the task get compressed or dropped. This produces the “forgetting” behaviour I described in the opening — the agent revisiting completed work because it has no record of having done it.

The engineering solutions are context compression (summarising older parts of the context to save space), external state management (writing progress notes to external memory at regular intervals), and task decomposition (breaking long tasks into shorter sub-tasks each with their own fresh context). Good agent frameworks handle this automatically. Poor ones don’t, and your agent runs off the end of the cliff mid-task with no warning.

How Tools Work — Selection, Execution, and Failure

Tools are the agent’s hands — the mechanisms through which it acts on the world beyond generating text. A tool is a function the agent can call with specified parameters. The agent is given a list of available tools at the start of the task. In each planning phase, it decides which tool (if any) to call next based on what it needs to accomplish.

Tool selection is handled by the language model — the same model doing the planning decides which tool is appropriate for the next action. This is done through a specific prompting format: the model is shown the available tools with their names, descriptions, and parameter schemas, and it produces a structured output specifying which tool to call and with what arguments. The agent framework intercepts that output, executes the actual tool call, and feeds the result back into the context.

Common tool categories in deployed agents:

Information retrieval tools — web search, database query, document reading, API data fetching. These tools only read; they don’t change the world. They’re the lowest-risk category because a failed or manipulated retrieval tool produces bad information, but doesn’t directly cause irreversible action.

Code execution tools — running Python, JavaScript, shell commands. These tools can do essentially anything a programmer with system access can do. They’re the highest-risk category. An agent with code execution can modify files, install software, make network connections, and in some configurations, do things that are very difficult to undo. I treat code execution tools as requiring explicit scoping: what directories can be read, what can be written, what network access is permitted.

Communication tools — email send/receive, Slack messages, calendar events. These tools have social consequences: they create records, affect other people, and can cause significant harm if misfired. A mistakenly sent email to a client is worse than a mistakenly generated text that was never sent.

File system tools — read, write, delete, move files. The delete capability deserves special attention: it’s irreversible in most contexts. I never give an agent file deletion capability without an explicit human approval gate before any deletion occurs.

Tool failure handling is where most production agents reveal their quality. When a tool fails — network error on a web search, permission denied on a file write, rate limit on an API — a good agent detects the failure in its observation phase, plans a recovery, and either retries, uses an alternative tool, or escalates to the human. A poor agent treats the failure as a successful result (misreading the error message) and continues building on a broken foundation.

What MCP Actually Is — And What It Changed

The Model Context Protocol (MCP) is an open standard, proposed by Anthropic and adopted across the AI industry in 2025, that defines how AI models connect to external tools and data sources. Before MCP, connecting an AI agent to a tool required custom integration code for every tool-model pair. After MCP, any tool that implements the MCP standard works with any model that supports it, through a common interface.

The analogy I find most useful: before MCP, connecting AI to tools was like the pre-USB era — every device needed its own proprietary connector. MCP is the USB standard for AI tool integration. Once a tool is MCP-compatible, it connects to any MCP-supporting model. Once a model supports MCP, it can use any MCP-compatible tool.

What this means practically: the number of tools available to any MCP-supporting agent is now determined by the MCP connector ecosystem, not by what the specific agent developer happened to build integrations for. In 2026 there are MCP connectors for Google Drive, Slack, GitHub, Jira, Notion, databases, dozens of APIs, local file systems, and hundreds of other services — each built once and available to all. An agent I build using Claude today can use the same GitHub connector that someone else’s agent uses with a different model.

The security implication of MCP: the attack surface is now shared. A vulnerability in an MCP connector that serves many agents is more dangerous than a vulnerability in a custom integration that serves one. MCP standardisation is an unambiguously good thing for the ecosystem — but it also means the security community needs to audit shared connectors more rigorously than custom ones. The MCP server attacks article covers the specific attack vectors that have emerged against the MCP ecosystem.

How Agents Plan — Chain-of-Thought, ReAct, and Tree-of-Thought

The planning phase of the agent loop isn’t a single technique — there are distinct approaches to how an agent reasons about what to do next, and they produce meaningfully different behaviour. Understanding the three main approaches helps you evaluate agents you encounter and design better ones when you build.

Chain-of-Thought (CoT) planning. The agent produces explicit reasoning before each action — a step-by-step thought process that walks through what it knows, what the options are, and what it should do next. You can often see this in agent outputs as a “thinking” section or scratchpad before the actual action. CoT planning improves reliability on complex tasks because it forces the model to be explicit about its reasoning, which catches logical errors that implicit reasoning misses. The downside: it uses more tokens per loop iteration.

ReAct (Reasoning + Acting). An interleaved approach where the agent alternates between reasoning steps and action steps. Reason: “I need to find the CVE ID for this vulnerability.” Act: call the web search tool. Reason: “The search returned three results, the second looks most relevant.” Act: fetch the full page. Reason: “The CVE ID is CVE-2026-XXXX, now I need the severity score.” Act: search for the CVSS score. ReAct is the most common pattern in deployed agents because it naturally maps to the perceive-plan-act-observe loop and produces action traces that are readable and auditable. I prefer ReAct for any task where auditability matters — the trace of reasoning steps makes it possible to understand what the agent was thinking at each decision point.

Tree-of-Thought (ToT) planning. The agent explores multiple possible approaches in parallel, evaluating each branch before committing to one. Instead of the linear “reason, act, observe” of ReAct, Tree-of-Thought generates several candidate plans, evaluates them, and selects the most promising before starting execution. This is more computationally expensive but produces better results on tasks where the right approach isn’t immediately obvious. Think of it as the agent mentally running a few scenarios before committing to one — the way a skilled human planner considers multiple strategies before choosing.

In 2026, most deployed agents use a combination: chain-of-thought or ReAct for the main execution loop, with tree-of-thought evaluation when facing a decision point where multiple approaches are viable. The choice of planning strategy significantly affects how the agent behaves when things go wrong. A pure CoT agent that encounters a failed tool call might not generate the explicit reasoning to evaluate alternatives. A ReAct agent will produce a reasoning step that reads: “the tool call failed with a rate limit error, I should wait and retry” — making the recovery decision explicit and readable.

Putting It Together — A Full Agent Architecture

Now that the components are clear, let me show you how they fit together in a real agent. This is the architecture of a research agent — one of the most common deployed agent types — with every component identified.

Reading an agent’s architecture at this level — what memory types it uses, what tools it has, what planning pattern it follows, what stopping conditions are set — tells you almost everything you need to know about its capability profile and its risk profile. Agents that lack external memory will fail on long tasks. Agents with write_file and no explicit constraint on what can be written are higher risk. Agents with no stopping condition can loop indefinitely. This architecture view is what I use when evaluating any agent I’m asked to deploy or trust with consequential work.