Giving the AI hands: from chatbot to agent

1 Why a plain LLM isn't enough

Let's recall exactly why a raw LLM is limited. Every limitation here comes straight from Session 1, and each one is a reason agents exist.

The four walls of the locked room

So what would fix this?

Notice that three of the four problems are really the same wish: "let the model reach outside its room." If we could let the LLM look things up, run a calculation, call an API, or write to a file — and then read the result and decide what to do next — almost all of those walls fall down. The model stays a text-predictor, but now its text can trigger real actions, and the actions' results flow back in as new text. That bridge is exactly what an agent is.

2 What is an AI agent?

Here's a clean definition we'll use all session:

The three ingredients

• The brain (LLM) — the same next-token predictor from Session 1. Its job in an agent is to reason about the goal and choose actions. It never magically gains new powers; it just decides which tool to use and what to say.
• The tools — functions the agent is allowed to call: search the web, run code, query a database, send an email, read a file. Each tool is a real piece of code you write or provide. (Full detail in Topic 3.)
• The loop — the controller code that runs the brain, executes whichever tool the brain asked for, feeds the result back to the brain, and runs it again. Without the loop you just have a one-shot answer; with it, the agent can take many steps. (Full detail in Topic 4.)

Chatbot vs agent — the key contrast

3 Tools & function calling — how an LLM "uses" a tool

A tool is just a function the agent is allowed to call — for example get_weather(city) or calculator(expression). The mechanism by which the LLM requests one is called function calling (also known as tool use). Let's build it from scratch.

Step 1 — You describe the tools to the model

Before the agent runs, you give the model a list of available tools. Each tool has a name, a description (what it does and when to use it), and a schema of its inputs (which arguments it takes, and their types). The description is basically a tiny instruction manual — the model reads it to decide whether and how to use the tool.

{
  "name": "get_weather",
  "description": "Get the current weather for a given city.",
  "parameters": {
    "city":  { "type": "string", "description": "City name, e.g. 'Paris'" },
    "units": { "type": "string", "enum": ["celsius", "fahrenheit"] }
  }
}

Step 2 — The model outputs a structured tool request

Here's the crucial bit, and it ties straight back to Session 1: the model still does only one thing — it outputs text/tokens. When it "decides" to use a tool, it produces a structured request (usually JSON) that names the tool and fills in the arguments. It does not run anything. It's the note slipped under the door.

{
  "tool_call": {
    "name": "get_weather",
    "arguments": { "city": "Paris", "units": "celsius" }
  }
}

Step 3 — Your code runs the tool

Your surrounding program (the agent's loop) sees this request, recognises the tool name, and actually calls the real get_weather("Paris") function — which might hit a weather API over the internet. This is the step that breaks out of the locked room: real code, real network, real fresh data.

Step 4 — The result is fed back to the model

The tool returns a result (e.g. {"temp": 18, "condition": "rain"}). Your code appends that result to the conversation and sends the whole thing back to the model. Now the model can read the live answer and continue — maybe answering you, maybe calling another tool.

The full handshake as a flow

4 The reasoning loop — ReAct (Reason → Act → Observe)

The most common pattern for an agent's loop is called ReAct, short for Reason + Act. Each turn of the loop has three beats:

Then it loops: reason again using the new observation, act again, observe again — until the agent decides it has enough to give a final answer (and stops calling tools).

5 Planning agents vs reactive agents

The ReAct loop in Topic 4 is the reactive style: decide one step at a time. But there's another flavour where the agent makes a plan first. Let's compare.

Reactive agents (decide step-by-step)

A reactive agent chooses its next action based only on the current situation, one step at a time — exactly the ReAct loop. It has no long-term plan; it just keeps asking "given what I know right now, what's the best next move?"

Planning agents (plan, then execute)

A planning agent first asks the LLM to break the goal into an ordered list of sub-steps — a plan — and then executes that plan step by step. This is often called plan-and-execute. Some planning agents also re-plan: if a step fails or surprises them, they go back and revise the remaining plan.

Pros and cons

6 Deterministic vs non-deterministic behavior

Something is deterministic if the same input always produces the same output. It's non-deterministic if the same input can produce different outputs on different runs. Agents are often non-deterministic, and it's important to know why.

Why agents wander

Recall temperature from Session 1: it controls how randomly the model samples its next token. At higher temperature the model sometimes picks a less-likely token, so it can word things differently — or, in an agent, decide differently. Because an agent's whole path is a chain of these decisions, a small difference early on can snowball into a completely different route: a different tool chosen, a different search query, a different number of steps.

When you want determinism

• Testing & debugging — if every run differs, you can't tell whether your change helped or you just got a different roll of the dice (this echoes the prompt-testing advice from Session 1).
• Critical, repeatable tasks — financial calculations, compliance steps, anything where "the same input must give the same output" is a requirement.
• Reproducibility — when a user reports a bug, you want to reproduce the exact run.

How to push an agent toward determinism

7 Failure modes & guardrails

Because an agent makes its own decisions and takes real actions, it has more ways to go wrong than a plain chatbot. Knowing the common failure modes — and the guardrails that contain them — is essential before you let one loose.

Common failure modes

Guardrails — how we contain the damage

★ Putting it all together

You just turned a locked-in text-predictor into something that can act in the world. Here's the one-paragraph story that connects all 7 topics:

Quick self-check

📚 References & Further Reading

Class material

• 📄 Original course notes / handout (source sheet) — open the shared GenAI class material for this session.
• Class handout: "AI Agents — tools, function calling, the ReAct loop & guardrails".
• 📝 Assignment 02 — Website Cloner Agent — the assignment shared for this session.

Papers, docs & deep dives

• "ReAct: Synergizing Reasoning and Acting in Language Models" (Yao et al., 2022) — the paper behind the Reason → Act → Observe loop.
• Lilian Weng — "LLM Powered Autonomous Agents" — a thorough survey of agent planning, memory, and tool use.
• Anthropic — "Building effective agents" — practical patterns for agentic systems, from workflows to autonomous agents.