AI Agent Beginner Tutorial: 01 - Concepts, Examples, and Technical Background

Run one model call first

Create a virtual environment, install the OpenAI Python SDK, and provide the model name and API key through environment variables. The code makes one request with no tool and no loop.

import os
from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model=os.environ["OPENAI_MODEL"],
    input="Explain the difference between an AI agent and a chatbot in three sentences.",
)

print(response.output_text)

Observe three pieces of data during the run: user input, model output, and whether the program continues. Here the program prints text and exits. No next step exists.

User input ──▶ Model ──▶ Text output ──▶ Program exits

This is a chat path. The model generated content, but the program did not let it alter control flow.

Compare three control models

The same technical-brief requirement can become three different programs.

A workflow is not an inferior agent. Fixed flows are often cheaper and easier to test. Model-driven decisions are useful only when intermediate observations change the action and code cannot reasonably enumerate every path.

Identify the roles inside an agent loop

At its smallest, an agent has five positions.

                 ┌───────────────┐
                 │   Task goal    │
                 └───────┬───────┘
                         ▼
┌──────────┐      ┌───────────────┐      ┌──────────┐
│ Result   │ ───▶ │ Model selects │ ───▶ │ Tool runs │
└────▲─────┘      │ an action     │      └────┬─────┘
     │            └───────┬───────┘           │
     └────────────────────┘◀───────────────────┘
                          │
                          ▼
                   Stop condition passes

• The goal states what must be completed.
• The observation contains user input, tool results, and errors.
• The decision lets the model select from allowed actions.
• A tool reaches files, databases, or external APIs.
• The application checks stopping conditions for success, failure, and budget exhaustion.

The model occupies one box in the diagram. Permissions, tool implementations, state persistence, and exit conditions remain application code.

Classify three requirements

The first requirement rewrites meeting notes as an email. The input is complete and one call is sufficient, so chat fits.

The second requirement classifies a support ticket and assigns a team through fixed rules. The categories are finite and code can express every branch, so a workflow fits.

The third requirement investigates a new framework. The first search may find no official source or reveal conflicting versions, so evidence determines whether the system searches again, changes terms, or stops. This task has the shape of an agent loop.

For each classification, write three lines: which actions are allowed, which observation changes the next step, and what lets the program stop. If those lines cannot be written, the requirement is not yet ready for implementation.

From one model call to an agent loop

One model call and a boundary map do not yet form an agent. The relationships in the map continue through the later code: the model generates decisions, the application constrains them, tools change the environment, and stopping conditions close the loop.

This loop depends on LLMs, structured output, and function calling. The next section follows that technical progression and separates the responsibilities of the model, tools, and agent runtime.

LLMs began as next-token generators

A large language model receives tokens and generates more tokens. One chat request can rewrite, summarize, classify, and answer knowledge questions, but the model itself does not open files, query databases, or observe what the program does after text generation.

Prompt ──▶ LLM ──▶ Tokens

Early applications encoded actions in natural language, such as SEARCH: agent loop. Those formats drift easily and spread string-parsing logic through business code.

Structured output lets a model request an action

JSON Schema adds fields and types to model output. Function calling goes further by providing function names, descriptions, and parameter schemas, allowing the model to return a structured call.

User question + tool schema
          │
          ▼
         LLM
          │
          ├──▶ Final text
          └──▶ function_call(name, arguments)

A function_call remains model output. The application checks the tool allowlist and arguments before executing a real function. The model gains no server permission from producing the call.

Tools connect the model to an external environment

Tools can read files, search sources, query databases, call business APIs, or create side effects. When a tool result returns, the model receives a new observation and can choose another step.

LLM decision ──▶ Tool executes ──▶ Environment change / data
     ▲                                      │
     └──────────────────────────────────────┘

This loop turns one generation into a multi-step task. As tool count grows, the application also needs schemas, permissions, timeouts, retries, output limits, and auditing.

The context window is a short-term workspace

On each turn, the model sees only content supplied in the current request. User goals, message history, tool results, and retrieved evidence all occupy the context window. The window is finite, and its contents have different priority and trust levels.

RAG retrieves material, while context engineering selects, orders, compacts, and labels it. A session continues a thread, while a checkpoint saves application control state. Stage three implements them separately.

The agent runtime manages loops and boundaries

A model API does not automatically provide a complete agent system. A runtime handles at least these responsibilities:

• Send current state to the model.
• Parse final text, tool calls, or control transfer.
• Execute allowed tools and record results.
• Check turns, cost, time, and permissions.
• Persist state, pause for approval, and resume tasks.
• Record traces and send outcomes to evaluators.

┌──────────────── Agent Runtime ────────────────┐
│  State ─▶ Model ─▶ Decision ─▶ Tool ─▶ State │
│    │                                   │      │
│    └──── Budget / Permission / Trace ──┘      │
└───────────────────────────────────────────────┘

Frameworks such as the OpenAI Agents SDK and LangGraph provide different runtime abstractions. The later code writes a small runtime first and then migrates to frameworks, matching each abstraction to an implementation.

See how each technical layer changes capability

Chapter 2 applies this agent-loop diagram to typical cases and defines the inputs, outputs, tool allowlist, and prohibitions for brief-agent.