How an AI agent execution loop works
Follow one AI agent request through instructions, a typed tool call, host approval, execution, returned evidence, retries, and completion.
The whole story in 5 lines
An agent is a model inside a host-managed loop that turns typed proposals into checked actions and returned evidence.
- The model receives the user goal together with application rules and available capabilities.
- The model emits either text or a tool request based on what the task still needs.
- A schema turns a proposed action into named fields that software can inspect.
- The host owns validation, permissions, credentials, and the final decision to execute.
- Results return as evidence, then the model finishes, repairs the call, or stops at a limit.
A refund cannot happen through words alone
A customer asks for order 1042 to be refunded because the screen arrived cracked. A useful answer must change an account, not merely sound confident.
The model can propose what should happen, but it does not secretly own the store database. A host application controls tools, credentials, and real side effects.
The request points at a locked refund action, while the model begins outside that boundary. What must connect language to the real system?
The complete route now appears between the request and the account change. We will follow inputs, a decision, a typed call, host checks, execution, and return.
Four terms will carry us through the lesson: model, tool call, host, and tool result. Now let us start with what enters the model.
The model receives a goal inside rules
We begin with two sources that matter for the same turn. The customer supplies a concrete goal, while the application supplies rules for handling account changes. Keeping them separate makes their authority easier to inspect.
Our worked application says to use tools for account changes and require approval before writes. Those rules limit how the customer request may be completed. The user goal remains important without overriding those safeguards.
The goal asks for a refund, but the application forbids an unchecked write. The two inputs now point toward different immediate behaviors. Which source should control that conflict?
Both bands enter the model together, but their order stays intact. In OpenAI Responses, top-level instructions take priority over the input parameter for that request. The host deliberately constructs this ordered context before inference.
Here is the key: the model receives a goal, rules, and available capabilities before acting. That bundle defines the choices available for this turn. Next, we will inspect its observable choice between text and a tool request.
The next output is text or a tool request
Now that the request and rules are together, the model must choose its next observable output. We do not need to invent or expose private reasoning. The host only needs a well-defined output item.
One branch produces ordinary assistant text. That works when the answer already exists in context and no external system must be read or changed. Text communicates a result without requesting an external capability.
The refund still requires a real account change, and only the host can reach that system. A sentence cannot supply execution evidence by itself. Which output can move the task forward?
The tool branch receives the request because the goal remains unfinished outside the model. This output is a proposal for the host, not proof of execution. Its meaning is deliberately narrower than a success claim.
The observable contract is simple: text communicates, while a tool item requests capability. The host can branch on that public item type. Next, we will open that item and inspect the fields software can validate.
A schema shapes the proposed action
We just selected the tool branch. The host previously advertised a refund tool with a name, description, and JSON Schema for its accepted arguments. That advertisement is the proposed action contract.
The schema requires an order identifier and a reason from a small allowed set. Unknown fields are rejected in this strict worked definition. Strictness narrows the shapes that downstream software must handle.
The call names refund_order and supplies both arguments, but a later result must still find this exact request. Multiple calls may exist in one conversation. Which field provides that link?
Every call field now fits a declared slot, including the call identity. Ordinary software can parse this record and reject missing, mistyped, or unexpected arguments. Validation still does not authorize the side effect.
OpenAI names this output a function_call, while MCP wraps comparable data in tools/call. The envelope differs, but typed names and arguments create the same boundary. Each runtime still owns its exact wire format. Next comes host validation.
The host checks before it executes
The typed call has left the model, but nothing has executed yet. The host receives the proposal because it owns the actual tool connection and credentials.
The host parses the arguments, checks the advertised schema, and confirms refund_order is allowed. Each check can stop the call before a side effect.
The fields are valid and the tool is allowed, but this call changes an account. Who gives the final permission to cross the boundary?
Approval opens the final gate, so the call reaches the executor. A denial would divert the same valid proposal into a blocked result instead.
Switch Approval between Approve and Deny. The downstream path changes between an executor-bound call and a blocked result, while the proposed arguments stay identical.
The host is the trust boundary because it validates, authorizes, and dispatches. The exact interface varies by runtime. Next, we will execute the call and return evidence.
Execution returns evidence for the next decision
★ If you remember one thing · A tool result becomes new model input, so execution can continue as a controlled loop.
The call has passed every host check, so the executor can route refund_order to the account service. The model remains outside that trusted execution boundary.
The refund tool runs with the validated arguments and returns a submitted receipt. Execution may also return a structured failure rather than ordinary success data.
The host now holds a real tool result linked to call_refund_1042. Where must that evidence go before the model can answer truthfully?
The green result travels back into the model ledger under the same call identity. This return closes one iteration and gives the model grounded evidence.
A successful receipt lets the model finish, while a recoverable error can produce a corrected call. A denial or permanent failure should become an honest limitation.
Hosts also enforce budgets for time, cost, and repeated calls. Our three-turn ceiling is illustrative, but the principle prevents an error from becoming an endless loop.
The agent stops when the goal is satisfied or a host boundary says to stop. Otherwise, returned evidence starts another checked iteration. Now let us step back and see the whole picture together.
The host-managed loop as one system
We started with the input boundary. The model received the customer goal together with application rules and a list of available capabilities.
Then we learned that the model emits an observable choice. Text communicates directly, while a tool item asks the host for external capability.
Next, the schema gave that proposal a machine-checkable shape. Required arguments and a call identity let software validate and later match the result.
The host gate kept authority outside the model. It parsed the call, checked policy, gathered approval, and controlled the credentials used for execution.
Execution produced evidence that returned to the model. Success finished the goal, recoverable errors invited repair, and hard limits stopped unsafe repetition.
Together, these boundaries explain the whole agent loop. A model proposes the next step, while the host checks actions, returns evidence, and decides when execution must end.
The whole story in 5 lines
An agent is a model inside a host-managed loop that turns typed proposals into checked actions and returned evidence.
- The model receives the user goal together with application rules and available capabilities.
- The model emits either text or a tool request based on what the task still needs.
- A schema turns a proposed action into named fields that software can inspect.
- The host owns validation, permissions, credentials, and the final decision to execute.
- Results return as evidence, then the model finishes, repairs the call, or stops at a limit.