Exercise: Give the Agent Tools

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.

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 tool format

Tools are written in a simple, typeable form:

Where to run it

• The Tool Playground → — 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, a block appears — the tool name and the exact arguments — with a box for you to type what happened. Your result can be in any format you like. The run pauses until you answer; a template menu offers ready-made tool sets to start from. If your tool text doesn't parse, you'll be offered an LLM-assisted repair — approve it or keep your own. Name and save your agents as you work: every save adds a new version (v1, v2, …, with optional notes) to that agent's history, and you can reload any earlier version, edit it, and save again — the history only ever grows.
• An LLM of your choice — put the tool list (same format) in your first message, tell it to respond with exactly one tool call at a time and wait, and type each result yourself.

Step 1 · Play the computer

Load the Filesystem explorer template and start the run. Answer each call honestly, as a real filesystem would — invent a plausible project and keep your answers consistent. Let the run finish.

Step 2 · Your domain, your tools

Now build your own: 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. Write the task prompt so the agent drives. Run it, playing the computer.

Then 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?

Step 3 · The generic tool set

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.) Give your generic set two very different tasks and play both runs.

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.

Deliverable

Three captures (plus any creative-combination trophies). We will 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 — including every time you had to invent an answer because the agent asked your world a question you hadn't designed.