Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
An AI agent is a software system built around a model—not just a model acting alone. The application or managed runtime supplies context, asks the model what to do next, executes any requested tool call, returns the result, and repeats until the run stops. The model proposes actions; the runtime and its tools do the work.
What is the agent loop?
The loop is the agent’s control flow. A typical run follows this sequence:
![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)
- Receive input and context. The system combines the user’s request with applicable instructions, conversation history, and any other context it has chosen to provide.
- Call the model. The model interprets that information and returns either a response, a request to use a tool, or another control-flow instruction supported by the system.
- Handle the response. The runtime checks what the model returned. If it requested a tool, the runtime routes that request to the appropriate handler.
- Execute and return the result. The handler performs the operation and sends its result back into the run.
- Continue or stop. The runtime calls the model again with the result, or ends the run when a defined stopping condition is met.
A tool request is an intermediate step, not necessarily the answer to the user. The model may need to interpret the returned result, call another tool, or produce a final response. OpenAI’s agent-running documentation describes an SDK-managed loop that continues through tool calls until the model produces a final answer or the run reaches its configured stopping point. OpenAI’s engineering account of the Codex agent loop likewise illustrates the repeated model-and-tool cycle.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →What does the model do?
The model interprets the context it receives and selects a response or action request. It can decide, for example, that answering a question requires searching a document or calling an application function. But the model does not independently open a file, query a service, or change an external system simply by producing text. It must communicate a request through an interface that the surrounding software recognizes.
#1 Best Overall
That distinction matters because the model’s output is not the same thing as execution. The application or managed runtime determines whether a request is valid, which handler receives it, what permissions apply, and what result is returned. Anthropic’s tool-use documentation puts it directly: “The model never executes anything on its own.” See How tool use works.
How do tools work in an AI agent?
A tool has two parts: a declared interface that tells the model what it can request and what inputs are expected, and an execution handler that performs the operation. The model returns a structured request; application code, a server, or a managed service runs the handler and supplies the result. Depending on the architecture, tools might read a file, search a knowledge base, call a business API, or run code.
Rank #2
The interface enables the model to ask for an operation, but it does not grant unlimited authority. The handler and the environment determine what the agent can actually access or change. A tool that reads a document has different consequences from one that sends messages, modifies records, or runs commands, so access and approval rules should reflect the action’s impact.
Recommended Free Tools
What does the runtime or harness manage?
The runtime—also called a harness in some architectures—connects the model to the rest of the system. It maintains the active run, interprets model outputs, routes tool calls or handoffs, returns tool results, and decides whether to continue or stop. Depending on the implementation, it may also manage streaming output, pauses, or the execution environment.
OpenAI’s agent architecture guide separates a harness, an environment, and an application server. These are useful roles to distinguish even when one product or service implements more than one of them: the harness coordinates the run, the environment is where permitted operations take place, and the application server can provide or mediate application-specific capabilities.
Where this control sits depends on the design. OpenAI distinguishes a managed Agents API, an Agents SDK used in an application, and a Responses API approach with more custom orchestration. The Agents documentation explains these options. They differ in how much of the loop and state management a platform handles versus how much the application owns.
How is agent memory different from chat history?
Session history is information retained for the current conversation or run so later model calls can use earlier turns and tool results. Persistent memory is information deliberately carried across runs, often by storing, summarizing, or retrieving selected facts. Neither is a magical property of the model: the system must decide what to retain and how to make it available again.
OpenAI’s Agents SDK memory guide discusses persistent memory artifacts separately from session history. Anthropic’s memory tool documentation describes a tool-and-handler approach, in which the model requests memory operations and an implementation performs them. These examples illustrate different ways to build persistence; they do not imply that every agent has long-term memory.
Best Value
Memory design is also a data-governance choice. Decide what information is useful to preserve, where it is stored, who or what can access it, how long it remains, and how it can be corrected or removed. Apply the same sensitivity and retention rules that govern the workspace or service in which the agent operates.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How do common agent architectures differ?
There is no single topology for an agent. A managed service, an SDK-driven application, and a custom model-API integration can all implement the same basic loop while assigning control and state differently.
| Design | Who owns orchestration? | Where do operations run? | How to think about state and control |
|---|---|---|---|
| Managed agent harness | The managed platform coordinates the run. | In the platform’s managed environment, application services, or both, according to the tools configured. | Convenient when the platform’s supported controls fit the use case; check how it handles session state, persistence, permissions, and execution boundaries. OpenAI describes a harness, environment, and application server in its architecture guide. |
| SDK loop in an application | The application uses an SDK to run the loop, while the SDK provides orchestration support. | Tool handlers and any customer-managed environment run where the application deploys them. | Offers application-level ownership of tools and integration; the application must account for the loop, state, and safeguards it controls. OpenAI documents this approach in Running agents. |
| Direct model API with custom orchestration | The application implements the control flow around model calls. | Where the application’s own handlers and infrastructure run. | Allows custom routing and state design, with corresponding responsibility for interpreting requests, executing tools, handling results, and stopping safely. OpenAI presents the Responses API as one route for more customized orchestration in its Agents documentation. |
| Coordinator or workflow pattern | A coordinator or workflow distributes work among agents or steps. | Across the services and environments assigned to those steps. | Useful when a task needs a defined multi-step or multi-agent structure; additional handoffs and state boundaries must be designed. Google Cloud’s agent design-pattern guide frames pattern choice around workload needs. |
The table describes broad patterns, not guarantees about every vendor implementation. Product boundaries and capabilities change; consult the linked documentation for the specific version and deployment you plan to use.
What should you check before choosing a design?
Compare architectures by tracing who controls each part of the loop and where authority resides. Google Cloud’s design-pattern guidance recommends choosing for workload needs and revisiting that choice as requirements change. Its core concepts of AI agents also highlights runtime services and security controls.
- Orchestration owner: Is the loop run by a managed platform, an SDK in your application, or custom API code?
- Execution location: Do operations run in a hosted environment, a customer-managed sandbox or container, or application/server handlers?
- State and lifetime: What exists only in the current model call, what lasts for the session, and what persists across runs?
- Tool boundary: Which tools are managed, and which are functions or connectors executed by your application? How are results validated and returned?
- Identity and permissions: Which identity does each operation use, and are permissions scoped to the minimum needed?
- Consequential actions: Should a human approve actions such as sending, deleting, purchasing, or changing access?
- Isolation and network access: Can a tool reach files, services, or networks beyond its task, and what sandbox or policy limits apply?
- Retention: Which conversation and memory data are stored, for how long, and under which workspace or organizational rules?
These checks are part of the architecture, not finishing touches. A model may select a tool request, but the system’s execution boundary, identity, policies, and approval design determine what that request can do.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
