AI Agents

An AI agent is a system that uses a large language model to run a task on your behalf, deciding its own steps and calling tools as it goes, until the task is done. The model is not just answering a question. It is driving a process: choosing what to do next, acting on external systems, reading the result, and deciding whether to continue or stop.

The useful question is not "can the model chat?" Ask who controls the sequence of steps. In a plain application, your code decides the order and the model fills in a blank. In an agent, the model decides the order. That shift — from the model as a component to the model as the controller — is what the word "agent" names.

The mental model

Start with one contrast and three parts.

Workflows versus agents. Anthropic draws the line clearly. A workflow is a system where the model and tools are orchestrated through predefined code paths. An agent is a system where the model dynamically directs its own process and tool use, keeping control over how it reaches the goal. Both are "agentic systems." The difference is who holds the steering wheel. A workflow follows a route you wrote. An agent chooses the route at run time.

OpenAI defines an agent the same way from the other side: a system that independently accomplishes a task on your behalf. An application that calls a model but does not let it control execution — a simple chatbot, a single-turn prompt, a sentiment classifier — is not an agent.

The building block: an augmented model. Every agent is built on one model enhanced with three things it can use itself. Tools let it act on the outside world. Retrieval lets it pull in information it does not hold. Memory lets it keep state across steps. The model generates its own tool calls and search queries and decides what to keep. This augmented model is the atom; everything larger is a way of arranging it.

OpenAI names the three pieces you configure: the model that reasons and decides, the tools it calls to take action, and the instructions that define how it should behave, including its guardrails.

The loop. An agent runs in a loop. The model reads the situation, decides on an action, the action runs, and the result comes back into the model's context for the next decision. The loop repeats until an exit condition: a final answer is produced, the model stops calling tools, an error occurs, or a maximum number of turns is reached. This run loop is the core of how an agent works. The ReAct method (Yao et al., 2023) showed why interleaving reasoning and acting helps: reasoning traces let the model plan and track an action plan and handle exceptions, while actions let it gather information from outside sources instead of guessing.

How the parts fit together

Picture an agent handling a refund request. The model reads the message and instructions. It calls a data tool to look up the order. It reads the result, checks the refund policy in its instructions, and decides the request qualifies. It calls an action tool to issue the refund, then reports back. A guardrail runs alongside, checking the input was in scope and the refund amount is within an allowed limit before the high-risk action executes.

Each capability depends on the others. A model with no tools can only talk. Tools with no model to sequence them are just an API. Instructions with no guardrails leave the agent free to act on a jailbreak or an out-of-scope request. The behavior you want comes from the parts working as one controlled loop, not from any single piece.

Tools are worth as much care as the model. Anthropic reports spending more time on the tool interface than on the prompt in one benchmark agent. A tool needs a clear name, a documented input format, examples, and boundaries against other tools, so the model can pick and call it correctly. The Model Context Protocol (MCP) standardizes this connection: an open protocol that lets an AI application connect to external data sources and tools through one common interface, the way USB-C standardizes a physical port.

Where to be careful

Agents are not the right tool for every task. Use them where a fixed, rule-based path falls short: decisions that need judgment and handle exceptions, rulesets that have grown too tangled to maintain, and work that depends on reading unstructured text. Where you can predict the steps in advance, a workflow — or plain deterministic code — is simpler, cheaper, and easier to test. Start with the simplest thing that works and add autonomy only when the task demands it.

Autonomy also raises the cost of error. An agent that can send email, move money, or change records can do so wrongly. That is why guardrails and human intervention are part of the design, not an afterthought: layered checks on input and output, risk ratings on tools, and an escalation path to a human for high-risk or repeatedly failing actions.

Where this course stops

This is an orientation to what AI agents are, how they are built, and when they fit. It is not a framework tutorial, a prompt-engineering manual, or a production deployment guide. It will not tell you the right architecture for your specific system; that depends on your task, your tools, and your tolerance for error.

A useful next path: read Anthropic's patterns for workflows and agents; read OpenAI's practical guide for the model-tools-instructions foundation and guardrails; study the ReAct paper for the reasoning-and-acting loop; and learn MCP to see how tools and data connect to agents in practice. Then build one small single-agent system with two or three tools before reaching for a multi-agent design.