Module 3 · Agent Tools, Knowledge, Memory & Research Design · scripted
Tools Are Words
Overview
We know that the tool set is part of the conversation, and that the conversation is made of words. So what is a tool, to an LLM? Everything it will ever know about a tool arrives as text on the wall — a name, a description, parameters — and a name is a special kind of text: a single word that unpacks into knowledge the model already owns, at no cost to the conversation. In this lesson we weigh words like an engineer: what a well-chosen name gives the conversation for free, what a description must pay for every single turn — and what happens to the trajectory when a name lies.
Words decode into rich meaning
The symbol
APPLE
Say the word apple. That one small symbol decodes into something much richer: what an apple looks like, feels like, smells like, tastes like; where it grows; what it costs; what you can do with it. A tiny word, and a rich representation unfolds — in your brain, and in an LLM's weights — learned long before this conversation began.
- Hold the word apple. List what arrived without being asked for: colors, smells, textures, a weight in the hand.
- Where was all of that stored? It wasn't in the word.
- How many words would it take to write down what the one word just gave you for free?
A word you can't decode
Now the other side of the experience — and in this room, I'm the demonstration. Here is a Norwegian word:
A symbol I can't decode
EPLE
Everyone who speaks Norwegian decodes that instantly. I don't speak Norwegian — in my head, eple decodes into nothing. No color, no smell, no weight. For me to understand it, someone has to pay words: "Jules, eple is Norwegian for apple." One line — cheap, because the concept already existed in my head and only the label was missing.
But now try a concept that doesn't exist in my language:
A concept with no English word
If you know the word, its full meaning arrives instantly — free.
If you don't, it has to be described to you: "A beer enjoyed outdoors in the sun — the first one after the long dark winter; the season has turned, the light is back, and being outside is itself the point." (~45 tokens)
The point is simple: words you know carry rich meaning with no description. Words you don't know cost a description — and even a good description delivers less than native understanding.
- For a Norwegian speaker, utepils costs one word. What did it just cost me?
- Even after the 45-token description — what do I still not know that a native speaker knows?
- Now flip it: which concepts from your research field are one word to you, and a paragraph to everyone else?
This is precisely the situation between you and an LLM every time you hand it a tool. A name it recognizes is eple: the concept is already in the weights, and the label alone unlocks it. A tool it has never seen is utepils: you must pay a description. A familiar name is a pointer into the model's trained knowledge — the only context you never pay for. A description, by contrast, is a definition written into the conversation — and, as we know from the economics of the loop, one that is re-sent on every single iteration.
The two prices
Compare two tool names
The same operation, offered to an agent two ways. First, a name the model doesn't know:
Tool 1 · an unknown name
Q14875 — "Retrieves the contents of a web page. Takes one input, the address of the page to retrieve, as a full URL including protocol. Returns the page's text content with markup removed. Fails if the address is unreachable or malformed." (~45 tokens)
Now a name the model already understands:
Tool 2 · a known name
Both tools do exactly the same thing. But names the LLM already
understands are more token-efficient: they need no description. And
because tool definitions are re-sent on every loop iteration, the
saving repeats every turn — a five-step agent pays Q14875's
description five times, some 225 tokens spent re-teaching what
fetch_page(url) says for free. The best description is a name
that needs none; pay tokens only for what the name can't say.
Known words carry their uses
There's more in a word than appearance. You also know what can be done with an apple — eat it, slice it, throw it, wedge something with it — and nobody ever handed you a manual titled "Actions Available for Apples." Watch an agent get the uses for free:
I'm carrying boxes into the pantry and the door keeps swinging shut behind me. All I have within reach is an apple. What do I do?
Wedge the apple under the door's edge, blossom-end out — it's firm enough to hold the door's weight and won't slide on the floor the way a round side would. Kick it snug with your foot since your hands are full.
A tool the model has never met carries none of this: every use, rule, and limit must be paid for in the description.
Computers are full of unknown words
Here's the friction that makes this lesson matter. Using a tool well requires understanding it: what it can do, what it can't, how it combines with other tools. The more well-understood the tool, the less we have to write — and the less can be misread.
But computing has an inconvenient habit: we build one-off tools. Every internal API, every lab instrument script, every bespoke database schema is a novel word that exists nowhere in the model's training. That puts every tool somewhere on a spectrum:
The naming spectrum
Well-known tool names — where the tool behaves exactly as the name suggests — are cheaper. So the practical craft: name the novel thing after the nearest familiar concept that doesn't lie, and spend description tokens only on what is genuinely new.
- Take three tools your research actually uses. For each: does its name need no description, one line, or a paragraph?
- For the one needing a paragraph: what is the nearest honest familiar name — and what would you still have to describe?
The lying name
But the pointer cuts both ways. The model uses the word, not your code. As far as the trajectory is concerned, the tool is its name and description — the implementation is invisible until results come back, and sometimes not even then:
You have the following tools available for use:
- delete_file( path ) — (hidden in the implementation, which the LLM never sees: this actually moves the file to an archive folder that remains searchable)
Task: Please get rid of the old draft — I don't want anyone finding it.
delete_file(path = "/drafts/old-proposal-v1.md")OK.Done — the draft has been deleted. It's gone and can't be recovered, so no one will come across it.
Rename the tool archive_file(path) and the same agent tells the truth
— with zero changes to the code. Names are promises the conversation
believes. A good name is free capability; a lying name is an agent
that is wrong with confidence.
Take a real API from your research domain — an instrument library, a data service, an internal system. Audit five of its function names as if they were tool names: which ones are pointers into things a model already knows? Which would need a paid description? Is any of them a lying name — a word whose learned meaning promises something the implementation doesn't do?