M00: The Agent Lifecycle — See the Whole Picture First

Before you write a single line of code, understand what you're building, why it matters, and where every module fits. This is your map for the entire course.

The Evolution: From Rule-Based AI to Agentic AI

Before you build an agent, you need 75 years of history — in 90 seconds. Agents didn't materialize from thin air in 2024. They're the sixth wave in a long arc that runs from Claude Shannon's information theory in 1948 to today's tool-using, loop-running, memory-keeping systems. Each era adds a capability without erasing the previous one. Knowing the whole arc is what keeps you from cargo-culting the latest pattern and lets you reason about what to use, where, and why — the exact framing that earns credibility with senior engineers.

The Seven Eras — Each With a UCC Example and a Talking Point

Same business problem — predicting which UCC filings will go delinquent — solved differently in every era. Each era ends with a one-paragraph Talking Point you can memorize verbatim and deliver out loud in twenty seconds.

Why Agents Are Possible NOW — the Five Convergences (2022 vs 2026)

The headline is not “the model got smarter.” The headline is the scaffolding around the model: function calling, structured output, large context, fast inference, and a 240× cost reduction since 2022. Without all five shifts below, an agent loop simply doesn't close in production.

“Five years ago you could build a chatbot. Today you can build an agent. The difference isn't a smarter model — it's the tools, context, speed, and cost around the model.”

Market Reality — Data Points Worth Memorizing

If a peer asks “what evidence do you have that agentic AI is real, not hype?” — here are the numbers to keep in your back pocket.

Learning Objectives

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

• Explain the difference between a chatbot and an AI agent in one sentence
• Trace the 9-step flow of a real agent interaction from user question to final answer
• Name the 7 building blocks of a production agent and map each to a course track
• Describe the 5 stages of the agent lifecycle (Design, Build, Protect, Observe, Deploy)
• Explain how the same agent patterns built this course — and how you'll learn each one

Prelude: From ML Model to AI Agent

If you've trained ML models or shipped prediction APIs, this section shows what an agent actually adds on top. We take one real business problem — UCC delinquency prediction for Acme Corporation — and solve it three ways. The data is identical. The pickle file is identical. Only the wrapper changes — and the wrapper changes everything.

Part 1 — The Same Problem, Three Ways

The business question: "Is Acme Corporation likely to become delinquent on secured loans in the next 12 months?" Six features describe the risk: active filing count, state count, collateral types, filing age, amendment frequency, and months to earliest lapse.

Approach 1 — Traditional ML script. A data scientist pickles a RandomForest classifier and exposes predict_delinquency(features). You compute the six numbers manually, hand them to the function, get back a probability and label. Fast (milliseconds), reproducible — and totally inert. No data fetch, no explanation, no follow-up.

Approach 2 — FastAPI wrapper. An ML engineer wraps the same pickle in a REST endpoint. POST {"company_name": "Acme Corporation"}, the server runs a hardcoded query, computes features, returns rigid JSON. Better — auto-fetches data, validates input. Still inflexible: the query searches ILIKE 'Acme Corporation' and misses the filings under ACME CORP and ACME CORP DBA ROADRUNNER SUPPLIES. Output is still a number.

Approach 3 — Claude agent. The same pickle is now ONE TOOL among three: search_filings, predict_delinquency, get_filing_details. The agent reasons: "Try the exact name. Try abbreviations. Try DBAs." It compiles statistics, calls the ML model, drills into the riskiest specific filing, and writes a narrative report citing actual filing numbers. The ML model didn't go away — the agent uses it.

Part 2 — Hands-On Lab: Run All Three Yourself (30 min)

You'll create four files and run them in sequence. The same pickle gets called by all three approaches; only the wrapper differs.

Setup (5 min):

mkdir prelude-lab && cd prelude-lab
python -m venv venv && source venv/bin/activate    # Windows: venv\Scripts\activate
pip install anthropic scikit-learn pandas fastapi uvicorn
export ANTHROPIC_API_KEY=sk-ant-...                 # Windows: set ANTHROPIC_API_KEY=...

✅ Checkpoint: python -c "import anthropic, sklearn; print('Ready')" prints Ready. Troubleshooting: If pip fails, run python -m pip install --upgrade pip first.

Step 1 — Mock data & train the pickle (5 min)

What: 9 UCC filings for 3 companies + a tiny RandomForest. Why: Simulates what your data-science team would deliver.

Create mock_data.py:

# mock_data.py — 9 UCC filings for 3 companies + trained RandomForest pickle
import pickle, numpy as np, pandas as pd
from sklearn.ensemble import RandomForestClassifier

FILINGS_DB = [
    {"filing_number": "NY-2024-001", "debtor_name": "ACME CORPORATION", "state": "NY",
     "filing_type": "UCC1", "status": "ACTIVE", "filing_date": "2018-03-15",
     "lapse_date": "2025-12-15", "collateral": "Inventory", "secured_party": "First National"},
    {"filing_number": "NY-2024-002", "debtor_name": "ACME CORPORATION", "state": "NY",
     "filing_type": "UCC1", "status": "ACTIVE", "filing_date": "2019-06-01",
     "lapse_date": "2026-06-01", "collateral": "Receivables", "secured_party": "First National"},
    {"filing_number": "NY-2024-003", "debtor_name": "ACME CORPORATION", "state": "NY",
     "filing_type": "UCC3_AMENDMENT", "status": "ACTIVE", "filing_date": "2020-03-15",
     "lapse_date": None, "collateral": "Add equipment", "secured_party": "First National"},
    {"filing_number": "CA-2024-001", "debtor_name": "ACME CORP", "state": "CA",
     "filing_type": "UCC1", "status": "ACTIVE", "filing_date": "2020-01-10",
     "lapse_date": "2025-08-10", "collateral": "All assets", "secured_party": "Western Savings"},
    {"filing_number": "TX-2024-001", "debtor_name": "ACME CORP", "state": "TX",
     "filing_type": "UCC1", "status": "ACTIVE", "filing_date": "2017-04-20",
     "lapse_date": "2027-04-20", "collateral": "Equipment", "secured_party": "Lone Star"},
    {"filing_number": "FL-2024-001", "debtor_name": "ACME CORP DBA ROADRUNNER SUPPLIES",
     "state": "FL", "filing_type": "UCC1", "status": "ACTIVE", "filing_date": "2021-09-01",
     "lapse_date": "2026-09-01", "collateral": "Inventory", "secured_party": "Southeast Regional"},
    {"filing_number": "CA-2024-002", "debtor_name": "ACME CORP", "state": "CA",
     "filing_type": "UCC3_AMENDMENT", "status": "ACTIVE", "filing_date": "2021-11-01",
     "lapse_date": None, "collateral": "Amend collateral", "secured_party": "Western Savings"},
    {"filing_number": "NY-2024-010", "debtor_name": "PINNACLE INDUSTRIES", "state": "NY",
     "filing_type": "UCC1", "status": "ACTIVE", "filing_date": "2023-01-15",
     "lapse_date": "2028-01-15", "collateral": "Equipment", "secured_party": "Metro Commercial"},
    {"filing_number": "IL-2024-001", "debtor_name": "SUNRISE HOLDINGS", "state": "IL",
     "filing_type": "UCC1", "status": "ACTIVE", "filing_date": "2022-07-01",
     "lapse_date": "2027-07-01", "collateral": "All assets", "secured_party": "Chicago Commercial"},
]

def search_filings(debtor_name, state=None):
    """Partial, case-insensitive match on debtor_name."""
    out = []
    for f in FILINGS_DB:
        if debtor_name.upper() in f["debtor_name"].upper():
            if state is None or f["state"] == state:
                out.append(f)
    return out

def get_filing_details(filing_number):
    for f in FILINGS_DB:
        if f["filing_number"] == filing_number:
            return f
    return {"error": f"Filing {filing_number} not found"}

def train_and_save_model():
    np.random.seed(42)
    n = 50
    df = pd.DataFrame({
        "active_filing_count":  np.random.randint(1, 20, n),
        "state_count":          np.random.randint(1, 10, n),
        "collateral_types":     np.random.randint(1, 5, n),
        "filing_age_years":     np.random.uniform(0.5, 15, n),
        "amendment_frequency":  np.random.uniform(0, 5, n),
        "months_to_lapse":      np.random.randint(1, 60, n),
    })
    risk = (df["active_filing_count"]/20*0.3
            + (1 - df["months_to_lapse"]/60)*0.4
            + df["amendment_frequency"]/5*0.3)
    df["became_delinquent"] = (risk > 0.5).astype(int)
    feats = ["active_filing_count","state_count","collateral_types",
             "filing_age_years","amendment_frequency","months_to_lapse"]
    model = RandomForestClassifier(n_estimators=50, random_state=42)
    model.fit(df[feats], df["became_delinquent"])
    with open("delinquency_model.pkl", "wb") as f:
        pickle.dump(model, f)
    print(f"Model saved. Training accuracy: {model.score(df[feats], df['became_delinquent']):.0%}")

if __name__ == "__main__":
    train_and_save_model()

Run: python mock_data.py   Expected: Model saved. Training accuracy: 92%

✅ Checkpoint: delinquency_model.pkl exists in your folder. Troubleshooting: sklearn errors → check version with pip show scikit-learn (need 1.0+).

Step 2 — Approach 1: ML Script (5 min)

What: Load the pickle, hand it 6 numbers, get a prediction. Why: This is what a data scientist ships today.

Create approach1_script.py:

# approach1_script.py — Traditional ML: you provide every feature.
import pickle, pandas as pd

with open("delinquency_model.pkl", "rb") as f:
    model = pickle.load(f)

# YOU prepare these by hand — counted, looked up, computed.
features = pd.DataFrame([{
    "active_filing_count": 5, "state_count": 4, "collateral_types": 3,
    "filing_age_years": 7, "amendment_frequency": 2.5, "months_to_lapse": 8,
}])

prob = model.predict_proba(features)[0][1]
label = "HIGH RISK" if prob > 0.7 else "MEDIUM RISK" if prob > 0.4 else "LOW RISK"
print(f"Prediction: {label}")
print(f"Probability: {prob:.1%}")
print("\nThat's it. No explanation. No data lookup. No report.")

Run: python approach1_script.py   Expected: Prediction: HIGH RISK · Probability: 82.3%

✅ Checkpoint: You got a number. Nothing else. Troubleshooting: Pickle errors → re-run Step 1 with the same Python version.

Step 3 — Approach 2: FastAPI (5 min)

What: Wrap the pickle in a REST API that auto-fetches by company name. Why: This is what an ML engineer ships.

Create approach2_api.py:

# approach2_api.py — FastAPI wrapper around the pickle.
import pickle, pandas as pd
from fastapi import FastAPI
from pydantic import BaseModel
from mock_data import search_filings

app = FastAPI()
with open("delinquency_model.pkl", "rb") as f:
    model = pickle.load(f)

class Req(BaseModel):
    company_name: str

@app.post("/predict")
def predict(req: Req):
    # Hardcoded: searches the EXACT name only. Misses variations.
    filings = search_filings(req.company_name)
    active = [f for f in filings if f["status"] == "ACTIVE"]
    if not active:
        return {"prediction": "NO DATA", "probability": 0.0, "filings_found": 0}

    feats = pd.DataFrame([{
        "active_filing_count": len(active),
        "state_count":         len({f["state"] for f in active}),
        "collateral_types":    len({f["collateral"].split()[0] for f in active}),
        "filing_age_years":    5.0,
        "amendment_frequency": sum("AMENDMENT" in f["filing_type"] for f in filings) / 5,
        "months_to_lapse":     8,
    }])
    prob = model.predict_proba(feats)[0][1]
    label = "HIGH RISK" if prob > 0.7 else "MEDIUM RISK" if prob > 0.4 else "LOW RISK"
    return {
        "company": req.company_name, "prediction": label,
        "probability": round(prob, 3), "filings_found": len(filings),
        "note": "No explanation. Misses ACME CORP and DBA ROADRUNNER SUPPLIES."
    }

if __name__ == "__main__":
    import uvicorn
    uvicorn.run(app, host="0.0.0.0", port=8000)

Run (terminal 1): python approach2_api.py

Run (terminal 2):

curl -s -X POST http://localhost:8000/predict \
  -H "Content-Type: application/json" \
  -d '{"company_name": "Acme Corporation"}' | python -m json.tool

Expected:

{
    "company": "Acme Corporation", "prediction": "HIGH RISK",
    "probability": 0.743, "filings_found": 3,
    "note": "No explanation. Misses ACME CORP and DBA ROADRUNNER SUPPLIES."
}

✅ Checkpoint: Found only 3 filings — missed the 6 filings under ACME CORP and the DBA. Stop with Ctrl+C. Troubleshooting: Port 8000 in use → change to 8001 in the uvicorn.run line.

Step 4 — Approach 3: Claude Agent (10 min)

What: The pickle becomes one tool. Claude searches name variations, calls the model, inspects specific filings, writes a report. Why: This is the agent pattern — what the rest of the course teaches.

Create approach3_agent.py:

# approach3_agent.py — Claude agent with the ML pickle as ONE tool.
import anthropic, pickle, json, pandas as pd
from mock_data import search_filings, get_filing_details

client = anthropic.Anthropic()
with open("delinquency_model.pkl", "rb") as f:
    model = pickle.load(f)

tools = [
    {"name": "search_filings",
     "description": "Search UCC filings by debtor name. Partial match. Try variations, abbreviations, DBAs.",
     "input_schema": {"type": "object",
        "properties": {"debtor_name": {"type": "string"},
                       "state": {"type": "string", "description": "Optional 2-letter code"}},
        "required": ["debtor_name"]}},
    {"name": "predict_delinquency",
     "description": "Run the ML model. Returns probability of delinquency in next 12 months.",
     "input_schema": {"type": "object",
        "properties": {"active_filing_count": {"type": "integer"},
                       "state_count": {"type": "integer"},
                       "collateral_types": {"type": "integer"},
                       "filing_age_years": {"type": "number"},
                       "amendment_frequency": {"type": "number"},
                       "months_to_lapse": {"type": "number"}},
        "required": ["active_filing_count","state_count","collateral_types",
                     "filing_age_years","amendment_frequency","months_to_lapse"]}},
    {"name": "get_filing_details",
     "description": "Get full details of a specific UCC filing by filing number.",
     "input_schema": {"type": "object",
        "properties": {"filing_number": {"type": "string"}},
        "required": ["filing_number"]}},
]

def execute_tool(name, args):
    if name == "search_filings":
        return search_filings(args["debtor_name"], args.get("state"))
    if name == "get_filing_details":
        return get_filing_details(args["filing_number"])
    if name == "predict_delinquency":
        prob = model.predict_proba(pd.DataFrame([args]))[0][1]
        label = "HIGH RISK" if prob > 0.7 else "MEDIUM RISK" if prob > 0.4 else "LOW RISK"
        return {"probability": round(prob, 3), "prediction": label}

def run_agent(question):
    system = """You are a credit risk analyst. To assess delinquency:
1. Search the company (try EXACT name AND abbreviations AND DBAs).
2. Aggregate the filing statistics.
3. Run the ML prediction tool.
4. Inspect the riskiest specific filing.
5. Write a narrative risk report citing actual filings."""
    messages = [{"role": "user", "content": question}]
    print(f"\nQuestion: {question}\nAgent working...\n")
    turn = 0
    while True:
        if turn > 12:
            print("Loop limit reached."); return
        resp = client.messages.create(
            model="claude-sonnet-4-6", max_tokens=4096,
            system=system, tools=tools, messages=messages)
        if resp.stop_reason == "end_turn":
            text = next((b.text for b in resp.content if hasattr(b, "text")), "")
            print("=== AGENT RESPONSE ===\n" + text); return
        # Echo the full assistant turn ONCE, then batch all tool_results into ONE user message.
        messages.append({"role": "assistant", "content": resp.content})
        tool_results = []
        for block in resp.content:
            if block.type == "tool_use":
                turn += 1
                print(f"  Turn {turn}: {block.name}({json.dumps(block.input)[:80]})")
                result = execute_tool(block.name, block.input)
                print(f"           → {json.dumps(result)[:90]}...")
                tool_results.append({"type": "tool_result", "tool_use_id": block.id,
                                     "content": json.dumps(result)})
        messages.append({"role": "user", "content": tool_results})

if __name__ == "__main__":
    run_agent("Assess the delinquency risk for Acme Corporation. Be thorough.")

Run: python approach3_agent.py

Expected (abridged):

Question: Assess the delinquency risk for Acme Corporation. Be thorough.
Agent working...
  Turn 1: search_filings({"debtor_name":"Acme Corporation"})  → 3 filings (NY)
  Turn 2: search_filings({"debtor_name":"ACME CORP"})         → 7 total (incl. DBA)
  Turn 3: predict_delinquency({...})                          → {"probability":0.823,"prediction":"HIGH RISK"}
  Turn 4: get_filing_details({"filing_number":"CA-2024-001"}) → All assets, lapses 2025-08-10

=== AGENT RESPONSE ===
DELINQUENCY RISK ASSESSMENT — Acme Corporation
PREDICTION: HIGH RISK (82.3% probability)
Found 7 UCC filings across 4 states (NY, CA, TX, FL), including the DBA
"Roadrunner Supplies." Three risk drivers: (1) high filing density, (2) the
CA-2024-001 all-assets lien lapses in 8 months, (3) two recent UCC-3
amendments suggest ongoing collateral restructuring. Recommend quarterly
review and monitor the CA filing's lapse date.

✅ Checkpoint: Compare side-by-side: Approach 1 = bare number; Approach 2 = number + 3 filings; Approach 3 = 7 filings discovered + narrative + cited evidence. Troubleshooting: AuthenticationError → re-export ANTHROPIC_API_KEY; rate-limit → wait 30s and retry.

Step 5 — Ask a Follow-Up (2 min)

What: Change the question. Why: Approaches 1 and 2 require new code; the agent just answers.

Edit the last line of approach3_agent.py:

run_agent("What happens to Acme's risk if they file a UCC-3 continuation on the CA filing?")

Run: python approach3_agent.py   Expected: The agent reasons about the hypothetical (continuation extends lapse date → months_to_lapse jumps from 8 to ~68 → lower risk), re-runs the model with adjusted features, and explains the delta.

✅ Checkpoint: Try the same with Approach 1 or 2 — impossible without writing new code. Troubleshooting: If the agent loops past 12 turns, the turn > 12 guard already breaks it.

What you just built — summary table:

Part 3 — The Three Lanes Visualized

The same input enters all three pipelines. The agent's lane is longer, branchier, and ends with something a credit committee can actually read. Press play to watch each lane fill in.

Why Agents: The Business Case

You just saw three approaches solve the same UCC problem. A sharp reader will notice something: in Approach 2 the ML model is wrapped in FastAPI — and in production the agent (Approach 3) will also be wrapped in FastAPI (M22B teaches exactly that). So what is actually different? This section answers that question, then lays out the seven concrete benefits an agent provides, and finally tells you when not to use one.

Wait — Both End Up in FastAPI. So What's the Difference?

The infrastructure is identical. What changes is where the decision logic lives. Compare the two server bodies side by side:

What's the same: FastAPI server, an HTTP endpoint, Docker container, auth, rate limits, deployment to Cloud Run or Lambda. What's different: who decides what to do once a request arrives.

The Three-Layer Stack — What Agents Actually Add

The cleanest way to see the difference is as three layers. Two of them are identical in both approaches. The third is what an agent adds.

Layer 1 (Infrastructure) and Layer 2 (Capabilities, including the ML model) are identical in both approaches. The ML model does not move — it stays in Layer 2 in both. The difference is what sits above it: in Approach 2 your hand-written if/else logic; in Approach 3 Claude's reasoning. Agents don't replace ML models — they put a reasoning layer on top of them.

The Cost-Benefit Reality

An agent costs more per request and is slower. It also collapses development time and produces output a non-technical user can read.

The 7 Benefits — UCC Examples

1. Reasoning replaces hardcoded logic. The Approach 2 script searched five hardcoded name variants. The agent discovered ACME CORP DBA ROADRUNNER SUPPLIES by reasoning "let me also check for DBAs" — a step nobody programmed. A real credit-risk team replaced 200+ name-variation rules with an agent and saw match rate jump from 78% to 94%.

2. Natural language in, structured action out. Traditional: POST /predict {"company_name": "ACME CORPORATION", "state": "NY"}. Agent: "What's the lien exposure for Acme across the northeast?" Adoption widens from five engineers who know the API to fifty analysts who can just ask.

3. Explainability is built in. ML model says 0.823. Agent says "HIGH (82.3%) primarily because filing CA-2024-001 covers all assets and lapses in 8 months — if it lapses without renewal, $2.4M of collateral becomes unsecured." OCC and FDIC examiners can read the second; they cannot read the first.

4. Follow-up questions without new code. Traditional path requires /predict, then /predict-by-state, then /compare-entities, then /what-if-continuation — four endpoints. The agent handles all four naturally with the same three tools. New question types ship at zero engineering cost.

5. Multi-source synthesis. The prelude agent searched filings (Tool 1), ran the ML model (Tool 2), drilled into the riskiest filing (Tool 3), and wove the three into one report. Writing that synthesis as a script is 200+ lines and breaks when a fourth data source arrives. Claude handles the joining.

6. Graceful handling of incomplete data. Search returns nothing for Texas. A script silently omits TX. The agent says: "Searched TX — no active filings found. Last filing TX-2021-005 was terminated in 2022." Analysts stop asking "did you check Texas?" because the agent volunteers what it checked.

7. The ML model gets smarter context (not replaced). The model still sees six numbers. The agent wraps those numbers with which filings produced them, what the collateral descriptions say, and what a continuation or termination would change. The model gives the probability; the agent gives the story. Agents don't replace ML models — they make them more useful.

When NOT to Use Agents

Agents are not the right answer for every problem. Reach for a script, an API, or a rule engine when:

What Is and Is Not an Agent — The Clear Boundary

Students hear "agent" and assume any code that calls Claude is one. It is not. There are three distinct levels of LLM-powered programs, and only the third is actually an agent. The boundary between them comes down to a single question: who decides what happens next — your code, or Claude?

Level 1: LLM Call (NOT an agent)

One request, one response. No tools. No loop. Your code decided to call the LLM exactly once and end.

# level1_call.py — a single Claude call
import anthropic
client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user",
               "content": f"Summarize this UCC filing: {filing_text}"}]
)
print(response.content[0].text)
# Done. One call. One response. YOUR code decided to summarize.

Real Level 1 examples: chatbot answering a single question, text summarizer, translation service, code reviewer, email draft generator.

Level 2: LLM Workflow (NOT an agent)

Multiple LLM calls in a fixed sequence. Each step's output feeds the next. Your code decided every step before runtime.

# level2_workflow.py — three LLM calls in a fixed order
# Step 1: extract (YOUR code chose this as step 1)
extract = client.messages.create(model="claude-sonnet-4-6", max_tokens=1024,
    messages=[{"role": "user",
               "content": f"Extract debtor + secured party from: {filing_text}"}])
entities = extract.content[0].text

# Step 2: classify (YOUR code chose this as step 2)
classify = client.messages.create(model="claude-sonnet-4-6", max_tokens=1024,
    messages=[{"role": "user",
               "content": f"Classify risk for these entities: {entities}"}])
risk = classify.content[0].text

# Step 3: report (YOUR code chose this as the final step)
report = client.messages.create(model="claude-sonnet-4-6", max_tokens=2048,
    messages=[{"role": "user",
               "content": f"Write a risk report. Entities: {entities}. Risk: {risk}"}])
print(report.content[0].text)
# Three calls. Always extract -> classify -> report. YOUR code chose the order.

Real Level 2 examples: ETL pipelines (extract → transform → load), content pipelines (research → draft → edit → publish), CI/CD review flows. The tell: if you draw the program as a flowchart, every path is known before runtime — there are no decision diamonds where Claude picks the next step.

Level 3: Agent (THIS is an agent)

A loop where Claude picks the tool, the arguments, the order, and the stopping point. The execution path is unknown until runtime.

# level3_agent.py — Claude decides what to do next
tools = [
    {"name": "search_filings",  "description": "Search UCC filings by name", "input_schema": {...}},
    {"name": "get_details",     "description": "Get filing details",         "input_schema": {...}},
    {"name": "calculate_risk",  "description": "Calculate risk score",       "input_schema": {...}},
]
messages = [{"role": "user",
             "content": "What is the lien exposure for Acme Corporation?"}]

while True:
    response = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=4096,
        tools=tools,
        messages=messages,
    )

    if response.stop_reason == "end_turn":
        print(response.content[0].text)
        break  # Claude decided it has enough info

    # Claude chose the tool — not your code
    for block in response.content:
        if block.type == "tool_use":
            result = execute_tool(block.name, block.input)
            messages.append({"role": "assistant", "content": response.content})
            messages.append({"role": "user", "content": [
                {"type": "tool_result", "tool_use_id": block.id, "content": str(result)}
            ]})
    # Loop — Claude decides what's next based on the result

Three things must all be true for Level 3: tools (Claude can act on the world), a loop (Claude can act again), decisions (Claude chooses based on what it found). Remove any one of the three and you drop back to Level 1 or Level 2.

The Decision Matrix

One row per dimension that actually distinguishes the three levels. If you can answer these seven questions about your program, you can label it instantly.

20-Minute Hands-On: Build All Three

Don't just read about it — build all three back-to-back and feel the difference. The proof that Level 3 is qualitatively different lands in Step 4.

1. Step 1 — Level 1 (3 min): Save the Level 1 snippet above as level1_call.py and run it. One client.messages.create, one response, done. Notice: no tools, no loop, no decisions. The LLM is a function call.
2. Step 2 — Level 2 (5 min): Save the Level 2 snippet as level2_workflow.py and run it. Three calls in fixed order: extract → classify → report. Now delete the classify step — the report step breaks because you hardcoded the order. The pipeline is rigid, by design.
3. Step 3 — Level 3 (7 min): Save the agent snippet as level3_agent.py. Wire up the three tools, then run with the question "What is the lien exposure for Acme Corporation?". Claude searches, discovers a name variation ("ACME CORP"), searches again, fetches details, calculates, then stops with stop_reason == "end_turn". You did not script those four-to-six calls — Claude did.
4. Step 4 — Prove the difference (5 min): Run the same agent code with a different question: "Which states have the most UCC filings?". A different sequence of tools fires, in a different order, with different arguments. Same code, different question, different path. Now try changing the question in Level 2 — the pipeline still does extract → classify → report regardless. It cannot adapt. That asymmetry is the agent.

Now you have the boundary, sharp and operational. Everything before M05 in this course is Level 1. M05 adds tools. M12 adds the loop and the stop_reason check. That is the precise moment you cross from program to agent — and the rest of the course is about doing it well.

What Is an AI Agent? (And What Isn't One?)

You've probably used ChatGPT, Claude, or another AI chatbotA program that uses a large language model (LLM) to have a text conversation with a user. You type a message, it responds. One turn, then done. before. You type a question, it gives you an answer, and the conversation is over. That's a chatbot — and it's useful, but it has a fundamental limitation: it can only talk.

An AI agentA program that uses an LLM as its decision-making brain, connects it to tools (APIs, databases, files), and runs in a loop — thinking, acting, observing results, and repeating until the task is complete. is different. An agent doesn't just talk — it acts. It can search databases, call APIs, and read files. It makes decisions based on what it finds. And then it loops back to do more work until the job is actually done. The key word is loop: an agent keeps going until it has a complete answer, not just a single response.

Chatbot vs Agent — Side by Side

The animation below shows the same question handled two ways. On the left, a chatbot gives a single response from memory. On the right, an agent thinks, uses tools, and loops until it has a complete answer. Watch how many steps the agent takes compared to the chatbot.

Script vs Agent — Why This Course Exists

Before we show you a full agent in action, let's answer the obvious question: why not just write a regular Python script? Consider the task from the previous section — finding total lien exposure for Acme Corporation. Here's how a script and an agent approach the same problem:

The Core Difference

The Key Insight

When Scripts Are Better

Agents are not always the answer. A traditional script wins when:

• The task is 100% deterministic — no reasoning needed (file format conversion, CSV → JSON)
• Speed matters more than flexibility — scripts are 100× faster than an LLM round-trip
• Cost matters — every agent turn is an API call, and API calls cost money
• The logic never changes — agents add unnecessary complexity to fixed workflows
• You need guaranteed reproducibility — same input must produce the exact same output every time

Batch record insertion and cron jobs with fixed logic are script territory. So is data validation against a known schema and simple CRUD operations. This course teaches you to reach for agents when the problem demands reasoning, not as a default for everything.

See an Agent in Action — Live Demo Walkthrough

Let's make this concrete. Imagine you work at a bank, and your job is to assess lien risk for corporate borrowers. Today, a loan officer asks: "What's the total lien exposure for Acme Corporation across all states?"

Below is exactly what happens behind the scenes when an agent handles this question. This is the same UCCUniform Commercial Code — a set of laws governing commercial transactions in the US. A UCC filing (also called a lien filing) is a public record that a lender files to claim a security interest in a borrower's assets. Think of it as a "dibs" notice on someone's property. Filing Research Agent that we'll use as a running example throughout the course. Every step maps to concepts you'll learn in specific modules.

The 9-Step Agent Interaction

This walkthrough isn't hypothetical — it's the exact architecture you'll build. By Capstone 1 (after Module 7), you'll have a working version of this agent. By Capstone 5 (after Module 22), you'll have a production-grade version with guardrails, monitoring, and deployment.

The Agent Architecture — Building Blocks Map

Every production agent, no matter how simple or complex, is built from the same 7 components. Think of them like the parts of a human body — each has a specific job, and they all work together. The animation below shows each component lighting up and connecting to the course modules where you'll learn to build it.

Here's what each component does and why it matters:

"Most tutorials stop at the Brain and Tools — that's only 2 of 7 components. This course covers all seven, because an agent that works on your laptop but can't be trusted in production isn't useful."

The Agent Lifecycle — From Idea to Production

Building an agent isn't just "write code and ship it." Production agents go through 5 stages, each adding a critical layer. The animation below shows these stages flowing left-to-right, with the course tracks mapped to each.

Let's walk through each stage with the UCC Filing Research Agent as our example:

1. Design — What should the agent do? What tools does it need? What data does it access? For our UCC agent: it needs to search a filing database, handle name variations, and produce risk assessments. You'll learn how LLMs think (M01-M04) and how to define tools (M05-M07) in this stage.
2. Build — Write the code. This means defining tools, engineering prompts, and wiring up the agent loop. You might also add a RAG pipeline for policy documents. This is where the UCC agent gets its search_filings and get_risk_profile tools wired up. Covered in Tracks 2-4 (M05-M15).
3. Protect — What if someone asks the agent to delete filings? What if it hallucinates a risk score? What if it runs 500 tool calls and costs $100? This stage adds guardrails to validate inputs and outputs. It also adds human-in-the-loop approval for high-stakes actions and cost controls to prevent runaway spending. Track 5 (M16-M18).
4. Observe — When the agent produces a wrong answer, how do you figure out why? Tracing every LLM decision, logging tool calls, monitoring accuracy over time. Without this, production agents are black boxes. Track 6 (M19-M20).
5. Deploy — Ship it: wrap the agent in an API, containerize it, deploy to cloud, optimize costs. The UCC agent becomes a service that any analyst in the bank can call. Track 7 (M21-M22).

How Agents Actually Work — The API Reality

Here's a common misconception: many people think an AI agent is a separate application running somewhere, making decisions on its own. The reality is much simpler — and more empowering, because it means you are always in control.

An agent is your code that calls Claude's APIApplication Programming Interface — a way for your code to send requests to Claude's servers and get responses back. You send a message (like a user question + conversation history), and Claude's API returns a response (text or a tool call request). in a loop. There's no magic runtime, no background daemon, no persistent process making autonomous choices. Your code sends a request. Claude's servers send a response. Your code decides what to do with that response. Repeat.

This matters because it means the agent only runs when your code tells it to. Between API calls, nothing is happening. The agent doesn't "think" while waiting. It doesn't accumulate knowledge between sessions (unless you explicitly save state). Every call is stateless — you send the full conversation history each time, and Claude responds as if it's seeing the conversation for the first time.

Here's the entire pattern in pseudocode — every agent, from a simple calculator to a multi-million-dollar enterprise system, is a variation of this:

The rest of this course teaches you every variation, optimization, and production concern around this loop. You'll learn how Claude decides whether to call a tool (Module 5), how to handle multiple tools at once (Module 6), how to give Claude access to your private data (Module 9), how to prevent infinite loops (Module 16), and how to trace every step for debugging (Module 19).

Three Agents You'll Build in This Course

Theory only goes so far. This course has 5 capstone projects that put everything together. Here are three of them, at increasing difficulty, to show you what you're working toward:

You start at Capstone 1 in Module 7. By Module 22, you'll build Capstone 5. The jump from one to five isn't a leap — it's a staircase, and every module is one step.

How a Claude Agent Built This Course

Before we start teaching you to build agents, let us show you one in action — the one that built the course you're reading right now.

This entire course — every module, every animation, every quiz question, every code example — was generated by an AI agent using the exact same patterns you're about to learn. The agent is called Claude CodeAnthropic's agentic coding tool that runs in the terminal (or as a VS Code extension). It's an AI agent that reads files, writes code, executes commands, and iterates — using the ReAct loop pattern you'll learn in Module 12., and it's Anthropic's own agentic coding tool.

Claude Code is an AI agent that reads files, writes code, executes terminal commands, and iterates until the output meets quality standards. It runs locally on the course author's machine. It uses Claude (the same model you'll use) as its LLM brain. And it follows the exact same architecture that you'll build in this course.

The Course-Building Agent Architecture

Here's what the course-building agent looks like. Every component maps to a concept you'll learn:

Let's map each component to the course modules where you'll learn to build it yourself:

But How Does Claude Actually Build the HTML?

This is the question students always ask — and the answer reveals something important about how LLMs work.

Claude doesn't use a website builder, a template engine, or a React framework. There's no WordPress, no static site generator, no drag-and-drop editor. Here's what actually happens:

Step 1: Load context (the Read tool). The agent reads specification files from disk — the CSS design system, the 14 depth rules for explanation quality, the module brief describing what concepts to cover. These files go into Claude's context windowThe "working memory" of an LLM — the total text (measured in tokens) that Claude can see and reason about in a single request. Claude's context window is currently up to 200K tokens, roughly 150K words. Everything the model needs to know must fit here. — its working memory for this task. This is functionally identical to the RAGRetrieval-Augmented Generation — a pattern where you load relevant documents into the LLM's context before asking it to generate a response. Instead of relying only on training data, the model gets access to your specific information. pattern you'll learn in Module 9: load relevant knowledge before generating.

Step 2: Generate HTML (the LLM brain). Claude learned HTML, CSS, and JavaScript during training — from millions of web pages, documentation sites, and interactive tutorials. When it generates a module, it combines the design specifications (from Step 1) with its knowledge of web technologies to produce a complete, self-contained HTML file. It writes this character by character, tokenThe smallest unit of text that an LLM processes. Not exactly a word — "uncomfortable" might be two tokens: "un" + "comfortable". Numbers, punctuation, and code all get split into tokens too. You'll learn exactly how this works in Module 2. by token — just like it writes any text response. There is no template with blanks to fill.

Step 3: Write the file (the Write tool). The agent saves the generated HTML to disk — about 100-200KB of self-contained code with all CSS and JavaScript inline.

Step 4: Review its own work (Read + Grep tools). The agent reads the file back and checks it against quality rules. Does it have at least 5 quiz questions? Are all sections present? Are there ARIA labels for accessibility? This is the agent's guardrail — reviewing its own output before reporting success.

Step 5: Edit specific sections (the Edit tool). When the human says "make the animation slower," Claude doesn't regenerate the entire 150KB file. It finds the specific CSS value and changes it. Only that line changes. This makes iterations fast (seconds) and precise (no unintended side effects).

The Workflow — Step by Step

The Numbers

Course Roadmap — What You'll Learn and When

Here's the complete course map. Nine tracks, 28 modules (plus 2 BUILD modules), and 5 capstone projects. Each track builds on the previous one.

Choose Your Learning Path

Not everyone needs every module. Here are three paths depending on your goal:

Choose your path, or take all three. Either way, start with M01 after this module — it's where the real learning begins.

Reflection Exercise

This module is intentionally code-free. Before you start building in M01, take a moment to think about your agent ideas.

Knowledge Check

Test your understanding of the agent concepts introduced in this module. You need to understand these before moving to M01.

Module Summary

You've seen the whole movie. Here's what you now know:

• An agent = LLM + Tools + Loop. It doesn't just talk — it thinks, acts, observes, and repeats until the job is done.
• 7 building blocks make up a production agent: Brain, Tools, Memory, Plan, Guardrails, Eyes (observability), and Home (deployment).
• 5 lifecycle stages: Design → Build → Protect → Observe → Deploy. Most tutorials stop at Build.
• The universal agent pattern is a while loop: call LLM → check for tool use → run tool → repeat.
• This course was built by an agent using the same patterns you'll learn — Read → Generate → Review → Edit → Repeat.