AI Agent — Module 15.1

How This Lesson Fits the Module & Volume

Volume 14 closed with orchestration: Haystack pipelines, LangChain chains, and LangGraph graphs that retrieve, prompt, and generate. Those systems mostly follow a fixed path. Volume 15 opens when the model itself must decide the next step—plan, call tools, remember, and loop until the goal is done or a halt condition fires.

This lecture defines the AI agent as the unit of that shift. Everything else in Module 15.1—planning, reasoning, memory, tool calling, the agent loop, and human-in-the-loop—is a subsystem of this definition. Module 15.2 then specializes memory types; Module 15.3 standardizes tools via MCP.

Learning Objectives

By the end of this lesson, students should be able to:

Define an AI agent in engineering terms (goal, perception, plan, tools, loop, halt).
Contrast a chatbot, a RAG chain, and an agent on control flow and side effects.
Name the core agent components used throughout Module 15.1.
Sketch a minimal tool-using agent in Python (OpenAI-style function calling).
Explain why Vol. 14 orchestration is necessary but not sufficient for agents.
Map upcoming lectures (autonomy, memory, multi-agent, HITL, MCP) onto the agent diagram.

Definition

An AI agent is a software system that pursues a goal by repeatedly (1) observing context, (2) reasoning or planning, (3) optionally taking actions through tools or APIs, and (4) updating state until a success, failure, or halt condition is met. The language model is the decision component—not the whole product.

From Orchestration to Agency

A LangChain RAG chain is usually linear: retrieve → prompt → generate. A Haystack pipeline is an explicit DAG of components. Both are powerful, testable, and often the right production shape. An agent appears when the next hop is not hardcoded—when the model may search, then calculate, then write a ticket, then stop.

LangGraph, CrewAI, and AutoGen already previewed this. Module 15.1 teaches the concepts those frameworks implement so you can choose—or build a thin loop—without treating “agent” as a marketing label.

System	Who chooses the next step?	Typical side effects	Best fit
Chatbot / completion	None (one shot)	Text only	Q&A, drafting
RAG chain / Haystack pipeline	Developer graph	Reads a knowledge base	Grounded answers
Tool-using agent	Model + halt rules	APIs, files, tickets, code	Multi-step work
Multi-agent system	Roles + handoffs	Same, plus internal chatter	Divided labor

Anatomy of an Agent

Goal & constraints

User intent + policy
Budget, time, permissions
Success / failure criteria

Perception & memory

Messages + tool results
Working context window
Optional long-term store (15.2)

Plan, reason, act

Planning decomposes work
Reasoning chooses a move
Tools change the world

Loop & governance

Agent loop iterates
Max steps / timeouts
HITL for high risk

Minimal Tool-Using Agent

The smallest honest agent is not a framework—it is a loop: call the model with tool schemas, execute any requested functions, append results, repeat until the model returns a final message or you hit a step limit. Later lectures deepen schemas (function calling) and the loop itself.

from openai import OpenAI

client = OpenAI()
TOOLS = [{
    "type": "function",
    "function": {
        "name": "get_order_status",
        "description": "Look up an order by ID in the commerce API.",
        "parameters": {
            "type": "object",
            "properties": {
                "order_id": {"type": "string", "description": "e.g. ORD-1042"},
            },
            "required": ["order_id"],
        },
    },
}]

def get_order_status(order_id: str) -> str:
    # Replace with a real API / DB call
    catalog = {"ORD-1042": "Shipped; ETA Friday"}
    return catalog.get(order_id, "Unknown order")

messages = [
    {"role": "system", "content": "You are a support agent. Use tools for facts. Stop when the user has an answer."},
    {"role": "user", "content": "Where is order ORD-1042?"},
]

for _ in range(5):
    resp = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=messages,
        tools=TOOLS,
        tool_choice="auto",
    )
    msg = resp.choices[0].message
    messages.append(msg)
    if not msg.tool_calls:
        print(msg.content)
        break
    for call in msg.tool_calls:
        result = get_order_status(**eval(call.function.arguments))  # demo only; use json.loads
        messages.append({
            "role": "tool",
            "tool_call_id": call.id,
            "content": result,
        })

In production, parse arguments with json.loads, validate against a schema, enforce allowlists, and log every tool invocation. Module 15.3’s MCP tools will later standardize how those capabilities are discovered across apps.

What Makes an Agent “Good”?

Strengths of agency

Handles unknown step counts
Composes APIs without a giant DAG
Can recover via reflection
Fits ops, research, coding assistants

Costs and risks

Unpredictable latency and token spend
Tool misuse / over-calling
Harder eval than a RAG pipeline
Needs halt rules and observability

Common Misconception

“Any LLM chatbot is an agent.” A chat completion that only emits text has no action loop and no external effects. Agency requires a goal plus the ability to act (tools) and/or iterate (a loop) under explicit stop conditions. A well-designed Haystack/LangChain RAG app is often better than an under-governed agent.

Knowledge Check

Short Answer: Name the four repeated steps in the agent definition. Answer: Observe context, reason/plan, optionally act via tools, update state until halt.
True/False: A linear RAG chain is usually an agent because it uses an LLM. Answer: False—the next step is typically hardcoded.
Multiple Choice: In the sketch, the model requests tools via: (a) CSS, (b) tool_calls, (c) SQL triggers. Answer: (b).
Short Answer: Which Vol. 14 framework is the closest control-plane preview of agent loops? Answer: LangGraph (stateful graphs with cycles).
True/False: Halt conditions (max steps, timeouts, success criteria) are part of agent design, not optional polish. Answer: True.
Multiple Choice: Memory in this module is previewed before: (a) Module 15.2 types, (b) CUDA kernels, (c) CNNs. Answer: (a).
Short Answer: Why parse tool arguments with JSON validation instead of eval? Answer: Security and schema safety—eval can execute arbitrary code.
Short Answer: What Volume 14 capstone does this lecture explicitly bridge from? Answer: Haystack (and LangChain orchestration more broadly).
Multiple Choice: Multi-agent systems mainly add: (a) extra GPUs, (b) roles/handoffs, (c) new tokenizers. Answer: (b).
True/False: MCP (Module 15.3) is about standardizing how tools/resources are exposed to models. Answer: True.

Key Takeaways

An AI agent pursues a goal by observing, planning/reasoning, acting with tools, and looping under halt rules.
Vol. 14 orchestration (Haystack, LangChain, LangGraph) is the substrate; agency is who chooses the next hop.
Chatbots and RAG chains are not automatically agents—side effects and iterative control matter.
Start with a tiny tool loop; add memory, reflection, and multi-agent only when eval justifies it.
Next: autonomous agents—how much freedom you actually grant.

Trainer’s Guide

Whiteboard: Draw chatbot vs RAG DAG vs agent loop. Mark where Vol. 14 components (retriever, generator) become tools inside the loop.

Lab: Implement the order-status sketch with json.loads + a step counter. Fail closed if the model requests an unknown tool name.

Recap: Agents add goal-directed looping and tools on top of Vol. 14 orchestration. Continue with Autonomous Agent.