What is an AI agent?

The smallest useful agent

A plain model call has one transition: context in, generated content out. An agent adds a feedback path. Generated content may contain a structured tool request; ordinary software validates and executes an allowed request; the result becomes a new observation; the model is called again.

flowchart LR
  G[Goal + current evidence] --> M[Model proposes next output]
  M -->|final response| Z[Candidate stop]
  M -->|tool request| H{Harness gate}
  H -->|deny| O[Denial observation]
  H -->|allow| T[Tool changes or inspects environment]
  T --> O[Result, error, or uncertain outcome]
  O --> G
  Z --> V{Completion rule}
  V -->|not satisfied| G
  V -->|satisfied| F[Terminal result]

The model never becomes the tool. Its tool request is generated, untrusted data until the runtime parses it, resolves the target, checks current authority, and dispatches an operation.

Four layers often get called “the agent”

Precise language prevents design mistakes:

1. Model: turns one supplied context into text or structured proposals. Its weights do not normally change during the run.
2. Tool protocol: defines how tools are described and how requests and results are represented. Function calling and MCP live at this interface.
3. Harness: runs the loop, constructs context, stores state, validates proposals, mediates tools, applies budgets and permissions, records events, and decides whether another iteration is allowed.
4. Host product and environment: own the user interface, principal, business rules, files, services, accounts, approvals, and real-world effects.

An “agent” is the working combination, not a new kind of model. Swapping the model can change proposal quality. Changing the harness can change available evidence, actions, safety, cost, and reliability even when the model stays the same.

One turn can contain many model calls

Suppose a coding agent receives “fix the failing formatter test.” A realistic turn may look like this:

1. the harness combines the goal with repository instructions, current working state, available tools, and remaining budget;
2. the model requests a search or file read;
3. the harness validates the request and the tool returns content;
4. that observation is appended to the next context;
5. the model proposes a patch, then a test command;
6. the environment returns a failing test, so the model revises the change;
7. the model emits a final message;
8. the runtime or workflow checks the diff and required evidence before accepting the terminal state.

The conversation turn is the outer unit visible to the user. Inside it, the agent loop may perform many model–tool round trips. Each round grows or reconstructs context, consumes budget, and can fail independently.

What actually changes between iterations

The model's learned weights usually stay fixed. The run changes because the harness adds evidence: file contents, search results, command output, browser state, a permission denial, a human clarification, or a compacted summary of earlier events.

That distinction separates training from inference. It also explains agent memory: durable facts live in application state or artifacts and must be selected back into context. The model does not preserve canonical state by remembering it internally between API calls.

When the loop earns its cost

Use an agent when the next step genuinely depends on what the system discovers during the run: investigating a failure, navigating an unfamiliar repository, researching evidence, or operating across tools whose results cannot be predicted in advance.

Use a deterministic workflow when the transitions are already known. A fixed parser, policy check, or deployment pipeline is easier to reason about than asking a model to rediscover the same sequence on every run. Many good systems combine both: deterministic code owns policy and irreversible effects, while the model chooses among bounded information-gathering or drafting steps.

Completion is an application decision

A model can propose “done,” but it cannot make the claim true by saying it. The terminal contract might require a schema-valid artifact, a passing test, persisted state, no unresolved operation, a human approval, or an observed external effect. The harness and host application own that evidence.

Failure can occur at different layers: a poor model proposal, missing context, malformed arguments, policy denial, tool error, lost result, exhausted budget, or incorrect stop condition. Record proposals, policy decisions, operations, observations, and terminal reasons separately; “the agent failed” is not a diagnosis.

Three implementation views

Unrolling the Codex agent loop is a first-party walkthrough of prompt construction, inference, tool calls, observations, and turns. Build Your Own Coding Agent reduces the inner loop to a small readable program. Claude Code Unpacked visualizes a much larger product from source, but it is unofficial, version-specific, and explicitly warns that some details may be wrong or outdated.

Read all three with the same invariant in mind: the model requests; the harness decides and executes; the environment supplies new evidence.