Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsAn AI agent is not a model that can simply “think for longer.” It is a software system in which a model works inside an application or managed runtime, and that runtime does most of the structural work: it supplies instructions and context, interprets what the model returns, executes any tool requests, feeds results back, and decides when the run is finished. The model chooses what to do next. The surrounding software decides what actually happens.
This article breaks that system into its four working parts (the model, the loop, the tools, and memory) and explains how each one depends on the others. The examples draw on current official documentation from OpenAI, Anthropic, and Google Cloud, which is version-sensitive, so treat implementation details as a snapshot from the sources as accessed on 7 October 2026.
![Claude AI for Beginners Bible: [5 in 1] The Ultimate Guide to Automate Your Work, Save Hours Every Week, and Use AI for Real-World Results](https://m.media-amazon.com/images/I/415+fSJacsL._SL160_.jpg)
As an Amazon Associate I earn from qualifying purchases.
The agent loop is the control flow
Most agent behavior comes from a repeated cycle rather than a single model call. OpenAI’s documentation on running agents describes an SDK loop that calls the model, examines the response, handles tool calls or handoffs, and repeats until the run reaches a stopping point. The OpenAI engineering write-up “Unrolling the Codex agent loop” describes the same model-and-tool cycle from the implementation side.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
In practice the cycle looks like this:
- Input and context are assembled. The runtime combines the user’s message, system-level instructions, earlier conversation turns, and any other material the application decides to include.
- The model responds. The response is either a final answer for the user or a structured request to use a tool.
- The runtime inspects the response. If it contains a tool request, the runtime does not treat it as a finished answer.
- The tool runs. Application code or a managed service performs the operation requested.
- The result returns to the model. The output is added to the context so the model can use it on the next call.
- The loop continues or stops. The model is called again until it produces a final response or the runtime reaches another stop condition, such as a limit it has set or a pause for approval.
The key point is that a tool call is an intermediate step, not the answer the user sees. A runtime that treats the first model output as final has not built an agent; it has built a single prompt-and-response call.
#1 Best Overall
The model interprets context and proposes the next step
The model is the component that reads the assembled context and selects a response. Depending on the design, that response is text for the user, a tool request, or a handoff to another agent or workflow stage. Its job is interpretation and selection.
It is easy to imagine the model acting in the world on its own, and that picture leads to bad design. Anthropic’s official documentation on how tool use works puts the boundary plainly: “The model never executes anything on its own.” The model can ask for an action; it cannot perform one. Any design that assumes otherwise will misplace its safety controls.
This separation also explains why the same model can behave very differently in two products. The model may be identical, but the instructions, available tools, stop conditions, and permissions around it are not.
Tools are typed interfaces plus execution handlers
A tool has two halves. The first is a declaration: a name, a description of what it does, and a structured schema for its inputs. The model sees this declaration and can emit a request that matches it. The second is the handler: the code or service that actually performs the operation when the request arrives.
Declaration
The declaration tells the model what the tool is for and what arguments it expects. Clear descriptions and tight input schemas reduce malformed requests, but they are not a security boundary. A schema tells the model how to ask; it does not decide whether the request should be allowed.
Execution
The handler runs outside the model. Anthropic’s tool-use documentation distinguishes tools the application executes from tools the provider’s platform runs on its servers. Where the handler lives determines where the work happens, what credentials it can use, and what it can reach on the network. Filesystem access, shell commands, browser control, and calls to business services all fall into this category, and each one expands what the agent can change.
Returned results
After execution, the result is passed back into the conversation as structured output. The model then reasons over that output in the next loop iteration. Errors belong here too. A well-designed runtime returns a failure message the model can act on, rather than silently dropping the request or crashing the run.
Why tools change the risk profile
Tools expand capability and risk together. A search tool reads information; a file-writing tool changes state; a payment or deletion tool has consequences that are hard to reverse. OpenAI’s architecture guide separates the harness, the environment, and the application server, which makes it clear that the environment where tools run is a distinct design decision. Google Cloud’s guidance on core agent concepts emphasizes identity, policy, and network controls around these operations. The safe default is to give each tool the narrowest permissions it needs and to require explicit approval for consequential actions.
The runtime or harness makes the system work
The runtime, sometimes called the harness, is the code that wraps the model and turns a sequence of model calls into an agent run. Its responsibilities include:
- Loop state: tracking the current turn, pending tool calls, and whether the run is still active.
- Routing and handoffs: deciding which model, tool set, or sub-agent handles the next step when a system uses more than one.
- Tool dispatch: matching each requested call to a handler, enforcing permissions, and returning results.
- Streaming and pauses: delivering partial output to the user and suspending the run when it needs input or approval.
- The stop condition: recognizing when the run is complete, when it has hit a limit, or when it has failed.
OpenAI’s architecture documentation describes a harness, an environment, and an application server as separate layers. Keeping those layers distinct is useful even if your system is built differently, because each one has its own failure modes and its own security surface.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Memory is a design choice, separate from history
People often use “memory” to mean everything the agent remembers, but two different mechanisms are involved, and they behave differently.
Session history
Session history keeps the current conversation available to the model. It lets the agent refer back to an earlier instruction or a tool result within the same session. It is ordinary context, and it is usually bounded by the session’s lifetime. When the session ends, the history either goes away or is stored by the application for other purposes.
Best Value
Persistent memory
Persistent memory is information kept across runs. OpenAI’s Agents SDK documentation on agent memory describes persistent memory artifacts that can summarize or retrieve information for later use, distinct from the session history that preserves the current conversation. Anthropic’s memory tool documentation describes a similar model in which the application, not the model, handles the reads and writes to a memory store through a handler. In both cases, the model asks to remember or recall, and the runtime performs the storage operation.
What should persist
Memory is not automatically useful. Designers have to choose what persists, how it is summarized, how it is retrieved, and when it is deleted. Each choice has consequences: stale memories can mislead the agent, sensitive details can leak into later runs, and a retrieval step that pulls in the wrong records can distort a decision. Apply the workspace’s sensitivity and retention policies to memory the same way you would to any other stored data.
Choosing an architecture
There is no single agent topology. OpenAI’s documentation distinguishes a managed Agents API, the Agents SDK, and the Responses API as different routes, and Google Cloud frames design choices around workload needs and recommends revisiting them as requirements change. When you compare designs, check five axes:
- Orchestration owner: whether a managed platform runs the loop, an SDK inside your application runs it, or your own code calls a model API and orchestrates everything directly.
- Execution location: a hosted environment, a sandbox or container you manage, or your application’s own tool handlers.
- State location and lifetime: current-turn context, conversation or session state, or persistent memory across runs.
- Tool boundary: managed tools versus functions or connectors your client executes, and how results return to the model.
- Control and security: identity, permission scope, approval gates, sandboxing, network access, and retention requirements.
A managed harness reduces the amount of loop code you write but moves some control out of your hands. A custom integration gives you full control over state and tool dispatch and makes you responsible for every failure path. Neither option is inherently safer; the safety depends on the permissions and approvals you wire around it.
Operational safeguards
Whatever architecture you choose, these checks catch the most common design gaps:
Quick Recap
- Confirm that every tool handler runs with the least credentials it needs, not with a broad service account.
- Require explicit approval before any action that deletes, sends, spends, or publishes.
- Set a maximum number of loop iterations and a timeout so a confused run cannot continue indefinitely.
- Return tool errors to the model in a form it can act on, and log every tool request and result for review.
- Decide, per memory type, what persists, how long it is kept, and who can read it.
- Restrict network access from tool handlers to the destinations the task actually requires.
- Revisit the architecture when the task, data sensitivity, or required autonomy changes.
|
