Chapter 2 — The anatomy of an agent¶
In the previous chapter, we defined an agent as a system that decides a sequence of actions inside an environment. Now we can open that system and separate its parts. This matters because many failures attributed to the model actually come from an ambiguous runtime, a poorly defined tool, or operational state mixed into the conversation.
The minimal loop¶
The simplest pattern has four steps:
- Observe: receive the objective, context, and current state.
- Plan: decide whether to answer, request information, call a tool, or stop.
- Act: execute the call with validated arguments.
- Verify: interpret the result and decide whether the task is complete or another step is needed.
In practice there is a fifth cross-cutting component: policy. Policy determines which tools are available, which actions require confirmation, how many steps are allowed, and what happens when the evidence is insufficient.
Autonomy does not remove control. It moves control into the available tools, permissions, step budget, and stopping policy.
Tool calling: from text to a contract¶
A tool should not be presented to the model as a vague sentence such as “you can query the system.” It needs an explicit contract:
- a stable name;
- a description of when to use it and when not to;
- an argument schema;
- type and range validation;
- read or write permissions;
- timeout and retry policy;
- a clear representation of success, error, and partial results.
If a send_email tool accepts an ambiguous recipient, the model may fill the argument with a plausible inference. The problem is not only that the LLM can be wrong: the system has designed a dangerous boundary. A good tool contract makes illegal states difficult to express.
The Model Context Protocol formalizes part of this boundary for connecting agent clients to tool servers. Its authorization specification distinguishes, among other cases, a call performed on behalf of a person from an application-to-application call. That distinction is fundamental: “the agent can inspect inventory” does not automatically mean “the agent can purchase.” This series points to the current protocol specification rather than a historical snapshot.
Context, memory, and state are not the same thing¶
Context window¶
This is the information the model receives in the current turn: instructions, messages, tool results, documents, and runtime signals. It has a finite size and should be treated as a working view, not as a database.
Memory¶
This is information retained across turns or sessions: preferences, confirmed facts, summaries, or vector representations. Memory is not trustworthy by default; it needs rules for writing, expiration, correction, and deletion.
Operational state¶
This describes what the system is doing: in-flight operations, retries, pending results, locks, idempotency identifiers, and events. This state belongs to the runtime. It should not be dumped unfiltered into visible conversation history because it can confuse both the user and the model.
The distinction becomes critical when a tool is slow. The user may continue the conversation while an external operation is still alive. If the runtime treats everything as a message, the model cannot reliably distinguish whether an operation was requested, accepted, executed, or actually completed.
The agent as a state machine¶
A typical request may pass through:
requested → accepted → running → succeeded
or:
requested → accepted → running → retrying → failed
User-facing language must respect that machine. “The operation has been started” can describe accepted; “the operation has finished” is only correct in succeeded. Honesty should not depend on the model being cautious—it should depend on the runtime exposing states the model can express without inventing completion.
The Reactive/Proactive Agent pattern used by 5sigmas follows this separation: visible conversation, operations, pending updates, locks, and traces live in different structures. It solves a small but recurring problem: accept work now and close it only when an external result exists, without blocking the chat or emitting partial messages as if they were final.
Memory is not a universal solution¶
Adding a vector database does not turn a system into an agent. Retrieval can help find documentation, but the system must still decide:
- which query to make;
- which documents are trustworthy;
- how evidence is cited;
- what to do with conflicting results;
- when retrieval has not found enough information.
Memory can also increase the attack surface. If an agent writes a malicious instruction into memory and later retrieves it as trusted context, the problem has not disappeared—it has become persistent.
What to remember¶
- The loop is a decision architecture, not a marketing animation.
- Tools are software contracts with permissions, validation, and states.
- Context, memory, and operational state should remain separate.
- A task can remain alive after the visible conversation turn ends.
- MCP helps standardize connections, but does not decide which authorization is safe.
References¶
- Yao et al. (2022) — ReAct
- Schick et al. (2023) — Toolformer
- Model Context Protocol — current authorization specification
- Reactive / Proactive Agent — technical article
- OpenAI Agents SDK — documentation