Module 1 · Lesson 4
How an AI Agent Loop Works
The agent loop is the runtime cycle that lets a model move from one-shot generation to multi-step action: decide, act, observe, repeat, stop.
Frameworks can make agents look magical, but the core mechanism is straightforward. OpenAI's Agents SDK describes a built-in loop that continues until a task completes, while tools provide external capabilities and the runner handles repeated turns.
The six stages
1. Receive a goal
The user asks for an outcome, not necessarily a single operation. Example: “Find the unpaid invoices for Acme, summarize the total, and draft a reminder email.”
2. Build the model context
The runtime sends the model instructions, conversation history, available tool definitions and any relevant application context. Tool schemas matter because they define what actions are available.
3. Let the model choose the next step
The model may return a final answer or request a tool call. A tool request should be treated as structured intent, not as proof that the action is safe or authorized.
4. Execute the tool
Your application validates the request, checks permissions and calls deterministic code or an external service. The model should not directly hold database credentials or bypass your application's authorization layer.
5. Return the observation
The tool result is added to the agent's context. Now the model can decide whether the result is sufficient or whether another action is needed.
6. Stop or continue
The loop continues until the model produces a final answer, a step or token limit is reached, a guardrail interrupts execution, a tool fails in a non-recoverable way, or a human approval boundary pauses the run.
Pseudocode
context = initial_context(user_goal)
for step in range(MAX_STEPS):
response = model(context, tools)
if response.final_answer:
return response.final_answer
call = validate_tool_request(response.tool_call)
result = execute_tool(call)
context.append(result)
raise AgentLimitReached()This is intentionally simplified. Real runtimes also handle streaming, retries, structured outputs, tracing, handoffs and interrupted/resumable state.
Why stopping conditions matter
An agent should never be an unbounded while True around a paid model and side-effecting tools. Limits protect cost and reliability.
- Step limits: cap the number of model/tool cycles.
- Time limits: stop work that exceeds the user-facing latency budget.
- Tool timeouts: avoid waiting indefinitely on downstream services.
- Approval gates: pause before sensitive actions.
- Budget limits: optionally track token/tool cost per run.
What counts as an observation?
An observation is simply information returned to the agent after an action. It could be database rows, an API response, a search result, an error, a file summary or a human decision.
Observations should be designed for the model. Anthropic's tool-design guidance emphasizes returning meaningful context while keeping responses token-efficient. Dumping an enormous raw payload into the context can make the next model decision worse and more expensive.
Errors belong in the loop too
A well-designed tool returns failures in a way the runtime can distinguish from normal results. Some failures are recoverable. For example, if a lookup tool reports “customer not found,” the model may ask the user to clarify. Other failures should stop the run.
Where human approval fits
A human-in-the-loop system pauses the agent before a sensitive action and persists enough state to resume safely later. OpenAI's current Agents SDK includes human-in-the-loop mechanisms, while LangGraph uses persistent state and interrupts for resumable approvals.
One loop, many architectures
A single agent can use one loop. A manager-agent system may have nested loops. Handoffs can switch the active agent while keeping the run alive. A graph framework can make the loop explicit through nodes and state transitions. The underlying principle remains the same: a model decides, the system executes, and the new information influences the next decision.