Module 1 · Foundations of Agentic AI · scripted

Exercise: Give the Agent Tools

35 min
🎤 Talk view← Cockpit

The goal: a driver with a declared vocabulary

In this exercise you extend your flipped interaction prompts with one addition that changes everything: an explicit set of allowed tools, declared up front — each with a name, a description, and parameters. The agent drives the task by calling them; you play the computer, typing what each call returned. You are about to feel, from the computer's side, how a tool set shapes what an agent can and cannot do.

What you are practicing

Declaring a tool is making a promise: "if you say this word, with these parameters, the world will do this."
The agent can only act through the words you declare — so designing the tool set IS designing what's possible.

The exercise at a glance

  1. 1
    Step 1: play the computer for a ready-made tool set.
  2. 2
    Step 2: design your own tools for a problem from your domain — then experiment on the design itself.
  3. 3
    Step 3: design a generic tool set that handles many tasks.
  4. 4
    Bonus: catch the agent combining your tools in a way you didn't anticipate.

The tool format

Tools are written in a simple, typeable form:

The format

tool:set_oven
description:Sets the oven temperature and rack position
parameters:temperature: 0..300 degrees celsius rack: {top, middle, bottom} which rack to use label: string a note for the display

Parameter specs: <string>, <number>, <integer>, <boolean>, {a, b, c} for a fixed choice, N..M for a numeric range. A tool may have no parameters at all.

The exercise playground

For this exercise we have built an exercise playground — the Tool Playground — to help you do it. You paste your tools and your task, hit Start, and the model is given your tools in the form it is trained to call (how that works under the hood gets its own treatment shortly). Each time the agent calls a tool, the run pauses and waits for you — you play the computer.

You can also do the exercise in ChatGPT, Claude, or Gemini instead — if you're going to use one of those tools, click here for the instructions →.

How the playground works

  1. 1
    Open it: /exercises/tool-playground — or scan the QR code on the next card.
  2. 2
    Paste your tools and your task, and hit Start.
    The template menu offers ready-made tool sets; if your tool text doesn't parse, you'll be offered an LLM-assisted repair.
  3. 3
    When the agent calls a tool, a block appears — the name and the exact arguments — with a box for you.
    Type what happened, in any format you like. The run pauses until you answer.
  4. 4
    Name and Save your agents as you work.
    Every save adds a version (v1, v2, …) to the agent's history; reload any earlier version, edit it, and save again.

Scan to open the Tool Playground

Scan to open the Tool Playground
ai-agents-seminar.vercel.app/exercises/tool-playground

Step 1 · Play the computer

Step 1 · What you'll do

  1. 1
    Load the "Filesystem explorer" template and start the run.
  2. 2
    Answer each call honestly, as a real filesystem would.
    Invent a plausible project and keep your answers consistent.
  3. 3
    Let the run finish.

Capture — end of Step 1

💾 Save this before you move on

Copy into your course document and save:

  1. 1The full run: each call, its arguments, your result.
  2. 2The moment the agent's NEXT call depended on your result — the choice a fixed script could not have made.

Step 2 · Your domain, your tools

Step 2 · What you'll do

  1. 1
    Pick an interesting problem from your domain and design the tool set for it.
    Three to six tools, each with a name, description, and parameters in the format above.
  2. 2
    Write the task prompt so the agent drives, and run it — playing the computer.
  3. 3
    Experiment on the design itself, one change at a time:
    rename a tool and rerun — does the agent use it differently? · tighten a parameter from <string> to a {choice} or a range — what happens to the calls? · make one description vaguer — what breaks?

Capture — end of Step 2

💾 Save this before you move on

Copy into your course document and save:

  1. 1Your tool definitions, verbatim.
  2. 2One design change (name, parameter, or description) and the behavior difference it caused, before/after.

Step 3 · The generic tool set

Step 3 · What you'll do

  1. 1
    Design a tool set that isn't for one problem but for MANY.
    The smallest set of general tools you can devise that handles a wide variety of tasks in some territory. (The "one-word language" template shows the extreme case: a single tool that runs any command.)
  2. 2
    Give your generic set two very different tasks, and play both runs.

Capture — end of Step 3

💾 Save this before you move on

Copy into your course document and save:

  1. 1The generic set, and the two unlike tasks it handled.
  2. 2One sentence: what did the generic set do WORSE than a task-specific set would have?

Bonus · Catch it being creative

Watch for the moment the agent combines your tools in a way you did not anticipate — an unorthodox route that is nonetheless valid. Feed it a task that doesn't quite fit the tools and see what it improvises. If you catch a good one, capture the sequence: these unexpected-but-legal combinations are some of the most interesting evidence of the day.

Before we regroup

💾 Save this before you move on

Keep one document for this course. Copy your three captures into it (plus any creative-combination trophies) and save — we compare tool sets together at the end: the naming and parameter changes that most changed behavior, the best generic sets, and what it felt like to be the computer.

Copy into your course document and save:

  1. 1All three captures above, in your course document.
  2. 2Any creative-combination trophy: the unexpected-but-legal sequence, verbatim.

Be ready to discuss:

  • Which mattered more to the agent's behavior in your runs: the tool NAMES or the tool DESCRIPTIONS? What's your evidence?
  • Where did the agent ask your world for something your tools couldn't say? That gap is a design finding — what tool is missing?