Can a model do things, not just talk?

1Can a model do things, or only write text?

A model only writes text. By itself, it cannot check today's weather, send an email or book a ticket.

• 🌦️It has no live data. Everything it knows comes from the text it read in training (lesson 2). Ask "What's the weather in Delhi right now?" With no help, it can only guess from old text about Delhi.
• 📧It cannot act. It only writes words. Ask it to email your manager. It writes the email, but the email stays in the chat. Nothing is sent.
• 🧮It does not calculate. It writes digits that have a high chance of coming next, one token at a time (lessons 1 and 6). A drawing in one book shows a model asked to calculate 47 ÷ 12 × 3.14. It answers 7.34. The right answer is 12.2983.

To check, send or calculate anything, the model needs help from your code.

2What is tool calling?

Tool calling is how a model asks your app to run a tool for it.

The model never runs anything itself. Your code does.

It works in five steps:

1. Your app tells the model which tools exist: each tool's name, what it does, and what it needs.
2. When a tool would help, the model writes a tool request instead of an answer.
3. Your code runs the tool.
4. Your app sends the result to the model.
5. The model reads the result and writes the answer.

The messages are written in JSON, a plain-text format of names and values inside curly brackets. Example: one weather question, from your question to the answer. Use the buttons to go through it one step at a time.

{
  "tools": [{
    "name": "get_weather",
    "description": "Get current weather for a location",
    "input_schema": {
      "type": "object",
      "properties": {
        "location": {"type": "string"}
      },
      "required": ["location"]
    }
  }],
  "messages": [{
    "role": "user",
    "content": "What's the weather in Delhi right now?"
  }]
}

{
  "stop_reason": "tool_use",
  "content": [{
    "type": "tool_use",
    "id": "toolu_abc123",
    "name": "get_weather",
    "input": {
      "location": "Delhi"
    }
  }]
}

"messages": [
  (your question, step 1),
  (the tool request, step 2),
  {"role": "user",
   "content": [{
     "type": "tool_result",
     "tool_use_id": "toolu_abc123",
     "content": "31°C, haze"
   }]}
]

{
  "stop_reason": "end_turn",
  "content": [{
    "type": "text",
    "text": "It's 31°C and hazy in Delhi right now."
  }]
}

Three things to know about tool calling:

• 📝A tool request is only text in a fixed shape, like a filled-in form. "input": {"location": "Delhi"} is just characters. When the model writes it, no weather service has been called.
• 🧑‍💻Your code reads the request and decides whether to run it. It can refuse a tool, or ask you before it sends an email.
• 📋The result goes into the prompt as text. Your app pastes "31°C, haze" into the prompt, the same way RAG pasted chunks of the PDF (lesson 9).

A tool also fixes the maths question from section 1. In the same drawing in the book, the model is given a calculator tool, and it answers 12.2983, which is right.

3What is an agent?

An agent is an LLM with tools, running in a loop until a goal is done.

Take one goal: "Book the cheapest train from Mumbai to Pune tomorrow." One tool can't do it. It needs a search, a comparison and a booking, in that order.

Each round of the loop has three parts:

• 💭Think: the model decides the next step.
• 🛠️Act: the model asks for a tool, and your app runs it. This is the tool calling from section 2.
• 👀Look: the model reads the result that your app put in the prompt.

Your app can also add its own check between Act and Look. Round 3 below shows one.

When the loop continues, and when it stops:

• 🔁The model starts a new round as long as it asks for a tool.
• 🏁The loop stops when the model writes a normal answer instead of a tool request.

Example: the train goal, round by round. Use the buttons to go through it one step at a time.

Tool or agent?

• 🛠️A tool does one job when it is asked. get_weather returns the weather for one city, and nothing more.
• 🧭An agent chooses which tools to use, and in what order, to reach a goal. For the train, the model chose search, then seats, then booking. No code set that order.

The risk with an agent:

• ⚠️No person checks the agent's steps, unless your code adds a check. A wrong booking costs real money, so in round 3 your app asks you before book_ticket runs.

4What is MCP?

MCP, the Model Context Protocol, is a standard way to connect tools and data to AI apps.

A program that offers tools through MCP is called an MCP server. It is written once, and every app that supports MCP can use it.

Think of a USB-C port. One plug shape fits phones, laptops and chargers from many companies. MCP is one plug shape between AI apps and tools.

• 🔌Without a standard, every app writes its own code for every tool. 4 AI apps and 3 tools need 4 × 3 = 12 connections, each written by hand.
• 🧩With MCP, each tool is written once, and each app learns MCP once. 3 tools, each written once as an MCP server, + 4 apps that support MCP = 7 pieces of work, and all 12 pairs connect.
• 🖥️One MCP server can offer several tools. The example server in the MCP docs offers two: calculator_arithmetic and weather_current.
• 📨An app uses an MCP tool with the same steps as section 2. The app asks the server for its tools (tools/list) and puts them in the tool list. The model writes a tool request. The app sends it to the server (tools/call) and pastes the result into the prompt.

MCP does not change the model, which still only writes a tool request. MCP sets the shape of the plug between the app and the tool.

5Why does a model make things up?

A model writes words that have a high chance of coming next, not checked facts. A likely word is usually the true one, but not always (lesson 2), and a wrong answer sounds just as sure as a right one.

Hallucination is when a model writes something false and says it as if it were true.

• 🌍For a common fact, the likely answer is the true one. After "The capital of France is", the word "Paris" has by far the highest chance, and it is right.
• ❓For a rare fact, the model has no page it can open and read, because it keeps no copy of what it read (lesson 2). Ask for the birthday of a person who is barely mentioned online. It may write a real-looking date that is wrong.
• ⏳It doesn't know what happened after its training. Ask for tomorrow's trains from Mumbai to Pune with no search tool, and it may write train times that look real.
• 💻In code, a name can look likely and not exist. products.sortBy("price") in the chat below looks like real JavaScript, but JavaScript arrays have no sortBy.

const products = [
  { name: "Pen", price: 20 },
  { name: "Bag", price: 500 },
];
products.sortBy("price");

TypeError: products.sortBy is not a function

6How do you reduce made-up answers?

You cannot stop a model from making things up, but you can make it rarer and find it when it happens. Each fix below does one of two things: it makes a made-up answer less likely, or it catches one before it does harm.

• 📚Use RAG, and show the sources (lesson 9). The store's chatbot answers from the policy text your code pasted in, and names the page: "You can return phones, laptops and headphones within 7 days of delivery … (page 12)." A person can open page 12 and check.
• 🛠️Use tools for facts and maths. With search_trains, the agent reads tomorrow's real trains instead of guessing them.
• 🌡️Use a low temperature for facts, if you can set it (lesson 6 says where). In lesson 6, temperature 0.5 makes mat 3.6 times as likely as floor, not 1.9 times. The top word wins more often. For a common fact, the top word is the true one (Paris, section 5), so the true word wins more often. It does not help with a rare fact, where the top word itself can be wrong.
• 🤷Let it say "I don't know". Add to the prompt: "If the policy text does not answer the question, reply: I don't know."
• 📏Check its output in code. Before book_ticket runs, your code checks that Train B was in the search results.
• 🧑‍⚖️Keep a person checking where a mistake costs a lot. An airline's chatbot told a customer a wrong policy, and a court made the airline follow that wrong policy.
• 🔄Or let the LLM check the person. A support person writes the reply, and the LLM checks it. If they disagree, the person looks at the reply again before it is sent.

7What have you learned in these ten lessons?

The course had ten lessons. Here is what each one taught, in one line.

1. Lesson 1: a language model guesses the next word, adds it to the text, and guesses again, until it has written a whole answer.
2. Lesson 2: training sets a model's parameters, billions (hundreds of crores) of dials, by guessing, checking and nudging again and again.
3. Lesson 3: a tokenizer cuts your text into tokens, pieces of text that each have a number, before the model sees it.
4. Lesson 4: a model keeps a list of numbers for every token, called its embedding, and words used in the same places get similar lists.
5. Lesson 5: attention lets each word look at the words before it and mix in their lists, so "bank" after "river" gets different numbers from "bank" after "money".
6. Lesson 6: the model gives every possible next token a chance, and a program draws one by those chances, so the same question can get different answers.
7. Lesson 7: after pre-training, two more rounds of training, first on good answers and then on the answers people prefer, turned a text-finisher into an assistant.
8. Lesson 8: every token you send and every token the model writes is work for a GPU, so every token costs money.
9. Lesson 9: with RAG, your code finds the few chunks of your documents that match the question and puts them into the prompt.
10. Lesson 10: a model can ask your code to run tools, but it can still make things up, so give it real facts and check its work.

Rahul's next course covers agents and MCP in more detail.

← Lesson 9  ·  All lessons