Skip to content
How It Thinks

Design preview · Sample content — not a released episode or final script.

AI agents

How an AI agent turns a goal into a loop

A useful way to understand an agent is to follow the cycle between a model, its tools and the software that keeps track of progress.

Sample reading time: 2 minutes

Conceptual illustration: paper ribbons loop through a green frame and return, suggesting an agent's repeated cycle.
Conceptual illustration

Summary

A model proposes a next step. Surrounding software executes permitted actions, records the result and decides whether to continue. The loop makes the system useful; clear limits make it controllable.

Video embed placeholder — no video attached

On this page
  1. The model is one component
  2. Observe, choose, act, check
  3. A loop needs a stopping rule
  4. What the diagram leaves out

Imagine asking an assistant to compare three documents and produce a concise recommendation. One response might be enough if every document is already available. If the system must find the files, read them and check the comparison, the task becomes a sequence. The interesting part is how the next step gets chosen and how its result becomes input to the following step.

The model is one component

In a simple agent architecture, the model receives a goal, relevant context and a description of available tools. It can propose an action or produce an answer. An orchestration layer then interprets that output. The model does not need to directly operate the file system or call an external service: software can perform those actions after checking the request. This division matters because generating a plausible instruction and carrying it out are different operations. A tool call is a proposal until the surrounding system validates and executes it.

Observe, choose, act, check

Each turn updates the information available for the next decision. A search tool might return candidate documents. A reader might return their contents. A comparison step might reveal a missing section. The system feeds these observations back into the model along with the current task state. The cycle can be drawn as four steps: observe the current state, choose a next action, execute that action, then check the result. The labels describe a useful abstraction; implementations can combine or split these steps.

A simplified mechanism

  1. Goal
  2. Model proposes action
  3. Permission check
  4. Tool result
  5. Updated context

Updated context returns to “Model proposes action”

Diagram description: A cycle begins with a goal, moves through a model proposal, permission check and tool result, then updates the context. A return arrow carries that updated context back to the model proposal.

A loop needs a stopping rule

Continuing indefinitely is not evidence of intelligence. A practical system needs conditions for completion, failure and escalation. It might stop when an answer is verified, when a tool fails repeatedly, when the allowed budget is exhausted or when a decision requires a person. The orchestration layer can track these limits independently of the model's own assessment. A useful final response should describe what was completed and what remains uncertain.

What the diagram leaves out

Real systems also need logging, error handling, permission boundaries and ways to recover from partial progress. Some use a single loop; others divide work across several components. This sample explains one general pattern rather than any product's private architecture. The useful question is not simply whether a system is called an agent, but which actions it can take, which evidence it checks and who controls the boundaries.

Design preview

Related sample articles

← Back to all topics