Introduction to AI agents

Define an agent by how it observes and acts in an environment. Compare models with complete agent systems, distinguish several operating environments, and decide when an LLM-controlled workflow is worth its added complexity.

An LLM can generate an answer from a prompt. An agent application can use that answer to choose a tool, observe the result, and decide what to do next. This control loop supports tasks whose next step depends on what earlier steps discover.

This course focuses on agentic system design: how models, tools, state, and control logic work together. Some systems use one agent; others divide work among several. Multiple agents introduce additional decisions about communication, shared state, and who resolves conflicting results. More components are useful only when they improve the task outcome.

By the end of this lesson, you will be able to:

• Define what makes a system an AI agent.

• Distinguish between AI models and agents.

• Identify different types of agents and their roles.

• Understand the evolution from rule-based to LLM-powered agents.

• Evaluate when to use an agent instead of a simpler solution.

What is an AI agent?

In AI, an agent observes an environment and selects actions within it. Classical agent definitions include simple reactive systems as well as systems that plan or learn. The phrase “perceive-reason-act” is a useful guide for the LLM-based systems studied here, but explicit multistep reasoning is not a requirement for every kind of agent.

For an LLM-based agent, separate three responsibilities:

1. Perception: Obtain and interpret observations, such as a user message, an image, a sensor reading, or a database result. An observation may be incomplete or stale.

2. Reasoning and planning: Use the available information to select an action or a plan. An LLM may propose several steps; a reactive policy may map the current observation directly to an action.

3. Action execution: Execute a permitted operation, such as returning a reply, calling an API, moving a robot, or updating a record. Observe whether the action succeeded before relying on its expected result.

The application determines how much autonomy the agent has. It may permit some operations directly and require review for others. A successful model prediction does not by itself authorize an external action.

Consider a hypothetical reminder assistant:

You say, “Remind me to call mom at 6 PM.” The system interprets the request, resolves the date and time zone, and creates a reminder. It should report success only after the scheduling service confirms the reminder exists.

A travel example requires more decisions:

A cancelled flight prevents you from reaching Berlin tonight. A travel agent could compare replacement flights and trains, check your constraints, and prepare an itinerary. Booking tickets or messaging the hotel requires the relevant permission, and availability can change between searching and booking.

The reminder may fit a mostly fixed workflow. The travel task may need a loop because a failed booking or unavailable connection changes the next useful action.

The following properties describe common agent-design choices; not every agent implements all of them:

Agent-design properties

These properties concern system behavior. They do not establish biological intelligence, awareness, or a particular internal experience.

AI models vs. AI agents

A model and an agent system operate at different levels. A model supplies predictions; the surrounding application determines how those predictions affect a task.

Start with the model’s role:

An AI model represents a learned or specified mapping used by a program. A trained model often consists of parameters plus the architecture needed to use them. For example:

• A classification model predicts whether an email is spam or not.

• A text generation model completes a sentence or writes a poem.

• A speech recognition model converts audio into text.

A model invocation computes an output from the information supplied to it. Its training objective and architecture influence that output, but an external runtime determines when it runs, what history it receives, and whether an output causes an action.

An AI agent system adds action selection and interaction with an environment. An LLM-based agent can use one or more models, tools, and stored task state. Persistent memory is a design option rather than a universal property of agents.

An agent might:

• Use a language model to understand instructions.

• Call a search tool to gather information.

• Store conversation history in a vector database to reuse facts or preferences later.

• Monitor its success and adapt its behavior over time.

To understand the distinction, trace control: what invokes the model, what executes a proposed action, and what causes another decision? Those responsibilities belong to the complete system.

Comparing models and agent systems

The distinction is visible in support work. A classifier may predict “refund request.” The agent application then determines which policy to retrieve, whether information is missing, and whether to route the case for review.

Three categories of AI agents

One useful way to describe agents is by the environment in which they act. The three groups below overlap; they are not an exhaustive or mutually exclusive taxonomy.

Software agents

Software agents operate through digital interfaces, including APIs, web pages, files, and databases. A sandbox is an isolation mechanism that can restrict their access; operating in software does not automatically mean the environment is sandboxed.

Examples include:

• A chatbot that provides customer service on a retail website.

• An email triage agent that categorizes and replies to messages.

• A trading bot that monitors financial news and executes trades.

Although these agents are not embodied in the physical world, they can still carry out meaningful actions, such as updating records, sending alerts, or triggering automated workflows.

Key characteristics:

• Act through code, interfaces, and digital data.

• May use web search, file access, and language models.

• Can receive sensor-derived information through software interfaces, even without controlling physical hardware directly.

Physical agents (embodied systems)

Physical agents interact with the physical world through sensors and actuators. They obtain observations through hardware and act by changing their surroundings.

Examples include:

• A domestic robot that cleans your home and responds to voice commands.

• An autonomous vehicle that navigates traffic and avoids obstacles.

• A robotic arm on a factory floor that assembles products.

These agents require a complex integration of perception (e.g., cameras, microphones, LiDAR), real-time reasoning, and precise control mechanisms.

Key characteristics:

• Sense the physical world using embedded sensors.

• Act using motors, arms, wheels, or other actuators.

• Must handle uncertainty, delay, and safety in real environments.

Hybrid systems

Hybrid systems combine digital services with physical observations or actions. Combining those domains does not automatically make a system adaptive: updating state, changing a plan, and retraining a model are separate operations.

Examples include:

• A traffic-management system that uses camera observations to adjust signal timing.

• A healthcare assistant that gathers wearable readings and prepares information for a clinician to review.

• A warehouse robot that coordinates inventory records with physical movement of goods.

A warehouse example may need both a database record and a sensor observation. If they disagree about whether a shelf is occupied, the system needs a rule for obtaining better evidence before moving an item.

Key characteristics:

• Operate across digital and physical domains.

• Combine text, images, or sensor readings as required.

• May use feedback to revise a plan; learning from logged data requires an explicit training process.

The environment determines the relevant failure modes. Software actions can still have substantial consequences, while physical actions add constraints such as sensing delay, control precision, and contact with people or objects.

Evolution from rule-based systems to LLM-powered agents

Agents predate LLMs. Rule-based systems, learned policies, and language-model-based controllers offer different ways to select actions. They can also be combined in one application.

Rule-based agents: explicit logic

Rule-based or expert systems, such as MYCIN and XCON, were prominent in the 1970s to 1980s. In rule-based systems, human developers explicitly define all the rules.

For example:

• If the user says “I forgot my password,” then show a password reset form.

• If the temperature exceeds 30°C, turn on the fan.

Fixed rules can be straightforward to inspect when the rule set is small. As exceptions accumulate, interactions become harder to maintain. A fixed rule system does not learn new rules from data unless a separate learning or update mechanism is added.

Learning-based agents: training from feedback

Machine learning can support different parts of an agent. Supervised models can recognize objects or interpret speech, while unsupervised methods can learn useful representations. Reinforcement learning (RL) trains a policy using a reward signal associated with interaction. The reward specifies what optimization favors; it is not automatically a complete measure of good behavior.

The 2016 AlphaGo system combined supervised learning from expert games, reinforcement learning through self-play, and tree search. This illustrates a complete decision-making system using several methods together.

For example:

• AlphaGo used learned policy and value networks together with search to select moves.

• A robot-control policy can be trained to grasp objects from observations. It still needs suitable perception and feedback; RL does not remove the need for information about the object and environment.

RL can discover useful strategies, but its cost and reliability depend on the reward, observations, action space, and training environment. It is not guaranteed to find an optimal policy or to transfer safely to new conditions.

LLM-powered agents: instructions and tools

LLMs such as GPT-4, Claude, and Gemini introduced another way to interpret language and propose actions. Their role in an agent depends on the model version, tools, and control loop.

Pretrained LLMs can sometimes handle a new task from instructions or examples without updating their weights. That capability differs from learning a new policy through interaction rewards, although an LLM itself may also undergo reinforcement learning. Evaluate generalization on the actual task rather than assuming broad pretraining guarantees it.

Within an agent, an LLM can support:

• Tool selection: Propose a tool name and arguments, which the application validates and executes.

• Task planning: Decompose a goal and revise the proposed next step after an observation.

• Conversation handling: Interpret the history supplied by the application.

• Task transfer: Attempt a new task through prompting, subject to its learned capabilities and evaluation.

For example, a modern LLM-powered agent can handle a request like:

“Summarize this research paper and email the key points to my team.”

For this request, the application must retrieve the paper, produce a source-faithful summary, resolve the intended recipients, and send the message only within the authorized workflow. The exact sentence-level summary need not be hard-coded, but the email integration, permissions, error handling, and completion checks still need implementation.

The flexibility comes from allowing some decisions to depend on model output. That also makes the quality of each decision and the reliability of the surrounding control logic important to the final result.

LLM-based agents can make unsupported claims, choose unsuitable actions, or repeat a failed step. They also introduce latency, cost, and security concerns. This course examines how to observe those failures and design checks and recovery paths around them.

---

---

When should you build an agent?

Scope note: The case studies focus on LLM-powered agents. The broader definitions above also cover agents built with rules or other learned policies.

Not every problem needs an agent. Sometimes, a simple script or rule-based automation is enough. Agents introduce complexity, cost, and often uncertainty, so it’s important to be strategic about when to use them.

Consider an LLM-controlled loop when the next step depends on interpreting new information and a fixed workflow becomes difficult to specify. The following signals are starting points for evaluation, not proof that an agent is the best solution:

The task requires contextual decision-making

An agent can be useful when an action depends on ambiguous input, competing constraints, or earlier observations. Compare its decisions with a simpler workflow on representative cases.

In a hypothetical refund workflow, a model might extract the reason for return and identify missing information. Eligibility rules and authority to issue a refund should remain explicit. The tone of a customer’s message is not, by itself, a sound substitute for those rules.

The rules are too complex to maintain

A large set of exceptions may be difficult to maintain. A model can help interpret information that feeds those rules, but moving decisions into prompts also creates new testing and debugging work.

For a hypothetical vendor security review, an agent could locate evidence in unstructured documents and flag unanswered questions. The organization still needs defined requirements and a review process for the resulting judgment.

The workflow relies on unstructured or natural language data

LLMs can extract and summarize information from documents, emails, and conversations. A single model call may be sufficient; an agent loop becomes useful when the system must gather additional evidence or ask follow-up questions.

For example, consider an insurance claim intake process where customers describe events in their own words. An agent can extract relevant entities, ask follow-up questions, and route the case accordingly.

Before committing to an agent, define a baseline and a small evaluation set. Compare task success, missed constraints, latency, cost, and review effort. Use the results to decide whether more autonomy is justified.

From definition to design

An agent’s defining relationship is with its environment: it observes and selects actions. LLM-based systems add language-model predictions to that loop, while the application supplies execution, state management, and controls.

Software, physical, and hybrid environments create different engineering constraints. Rules, learned policies, and LLMs can contribute to any of them; they are design choices rather than a ladder in which each new approach replaces all earlier ones.

The next lesson separates the model, tools, and instructions so each can be designed and evaluated for its role in the task.