Agent Loop

An Agent Loop is an observe–decide–act–observe cycle. It breaks a complex task into many small steps that can be checked.

User objective
   ↓
Prepare context and the Tools available for this turn
   ↓
Model decides: respond or call a Tool?
   ├─ Respond ───────────→ Complete
   └─ Call a Tool
          ↓
   Permission, parameter, and approval checks
          ↓
   Execute and obtain a result
          ↓
   Return a safe result to the model ───→ Next turn

What happens in one loop

1. Prepare

The system reads the current conversation, model configuration, permissions, selected Skills, and available MCP Tools to assemble the context the model can actually see for this turn. Each model request freezes the Tools available at that moment. After a Skill or built-in capability is activated, the next request can receive an updated set, but the model cannot invent an unregistered Tool.

2. The model chooses the next step

The model may answer directly or propose one or more Tool calls, such as searching files and then reading two of them. Tool parameters must satisfy the required structure.

3. The Host validates and executes

Before anything executes, the system checks paths, permissions, Tool identity, and risk policy. When a user decision is required, the Run saves recoverable state and pauses instead of letting the model pretend the Tool succeeded.

4. Observe the result

Tool results are returned in a bounded form suitable for the model to read. Large results may be paginated, truncated, or stored as a separate artifact. Activity shown in the interface does not mean that all raw output entered the model context.

5. Continue or finish

The model chooses its next step from the new evidence. If the task is complete, it produces a final answer. If the task fails, is canceled, or encounters an unrecoverable problem, it ends with the corresponding state.

Why work can continue after approval

While a Run waits for approval, the system stores a checkpoint containing the observed history, pending action, Tool identity, and permission boundaries. After you approve, the Host revalidates the frozen action and continues the same logical Run instead of asking the model to recreate the call from memory.

Why an automatic retry is sometimes unsafe

A failed read is usually safe to retry. Writing a file, calling an external MCP Tool, or submitting a website form may already have had an effect. If the connection is interrupted before the result returns, the system can report only Outcome unknown. Repeating the action could write twice, so the correct response is to inspect the real environment first.

How users influence the Loop

• State completion criteria and prohibited actions at the beginning of the task.
• Choose appropriate permissions and handle approvals individually.
• Use the interface's steering capability when adding direction to an active Run.
• When an outcome is unknown, content conflicts, or sources are insufficient, ask for facts to be verified first.
• Cancel the Run when it must stop, but still inspect actions that have already crossed a side-effect boundary.

For authorization details, see Tool Calling. For continuity in long conversations, see Context management.