Talha Jalvi

Module 1 · Lesson 1

What Is an AI Agent?

An AI agent is an application in which a model does more than generate text: it can decide what action to take next, use tools, inspect the result, and continue until it reaches a stopping condition.

Updated August 2026 · AI agents · Developer fundamentals

The word agent is used loosely, so it helps to start with an engineering definition. OpenAI's current Agents SDK describes an agent as an LLM configured with instructions and tools, optionally extended with handoffs, guardrails, structured outputs and runtime behavior. LangGraph draws a similar line between workflows, which follow predetermined paths, and agents, which dynamically decide their process and tool usage.

Practical definition: an AI agent is a software control loop in which an LLM can choose among available actions, observe the results and decide what to do next.

The minimum pieces of an agent

1. A model

The model interprets the user's goal, chooses actions and produces intermediate or final outputs. The model is not the whole agent. It is the decision-making component inside a larger application.

2. Instructions

Instructions define the agent's role, constraints and expected behavior. Good instructions reduce ambiguity, but they do not replace application-level validation or authorization.

3. Tools

Tools give the agent capabilities beyond text generation. A tool can query a database, call an API, search files, execute code or ask another service to perform an action. OpenAI's Agents SDK currently supports hosted tools, local/runtime tools, function tools, agents-as-tools and MCP-backed tools.

4. A loop

The runtime repeatedly asks the model what should happen next. If the model requests a tool, the application executes that tool, returns the result to the model and continues. The loop ends when the model produces a final answer, a configured limit is reached or the application interrupts execution.

5. State or memory

Many agents need context from previous turns or previous runs. State may be as simple as the current conversation or as sophisticated as short-term checkpoints plus long-term storage. Memory is useful, but it should be added only when the product needs it.

6. Guardrails and permissions

Agents can take actions, so safety boundaries matter. Input checks, output checks, tool validation, human approvals and permission checks help prevent a model decision from becoming an unsafe application action.

Agent vs chatbot

A basic chatbot often follows a simple path:

User message → model → text response

An agentic application can look more like:

User goal
  ↓
Model decides next step
  ↓
Tool call → result
  ↓
Model inspects result
  ↓
Another tool call or final answer

The important difference is not the UI. A chat interface can sit in front of either architecture. The difference is whether the model is allowed to influence the execution path and use external capabilities.

A concrete example

Suppose a customer asks, “Can you check whether my order has shipped and, if it has not, tell me whether I can cancel it?” A plain chatbot might only explain the company's policy. An agent could:

  1. extract or request the order identifier;
  2. call an order-status tool;
  3. inspect the returned status;
  4. if the order is still cancellable, call a cancellation-policy or eligibility tool;
  5. ask for approval before a destructive action;
  6. return the final answer.

The sequence is partly determined by runtime data. That is the core reason to consider an agent.

Does an agent have to be autonomous?

No. Autonomy is a spectrum. Some systems let the model choose one tool and then return. Others let it execute multiple steps, delegate to specialists or wait for human approval. A useful architecture often keeps deterministic boundaries around an agentic core.

Where developers get confused

Three common mistakes are worth avoiding. First, not every application with an LLM is an agent. Second, adding more tools does not automatically make an agent better; tool quality and clear descriptions matter. Third, multi-agent architecture is not inherently more advanced or more capable than a well-designed single agent.

A useful mental model

Think of the model as a probabilistic planner operating inside deterministic software. Your code decides what tools exist, what each tool is allowed to do, what state is stored, what limits apply and when a human must approve an action. The model chooses among those possibilities.

Design principle: keep irreversible actions, authorization and critical business rules in deterministic code. Do not rely on the model to enforce them by prompt alone.

When agents are a good fit

Agents are most useful when the task has meaningful variation: the correct sequence of steps depends on what the agent discovers, the number of steps is not known in advance, several tools may be relevant, or human language must be translated into a series of application actions.

If the sequence is already known and reliable, a normal workflow is usually easier to test and operate. That distinction is the subject of Lesson 3.

Official references