This isn’t as exciting as you’re hoping it will be.
It’s really a covert way of explaining a technical concept, how LLMs use functions and tools. Buckle in.
1 The apartment listing looked good, almost too good. Open Chat:
“Can you check if 42 Main St, zip 10001 is a valid address?”
2. Chat’s reasoning:
The model recognizes this isn’t something it can answer from knowledge alone, it needs to actually verify this against real data. It knows a tool called check_house_address exists for this.
3. Model builds the tool call (check_house_address), extracting values from the sentence and placing them into the function’s required schema:
{
“name”: “check_house_address”,
“arguments”: {
“house_number”: 42,
“zip_code”: “10001”
}
}
Note: the schema is defined once, the tool call is the specific instance of when it’s used. E.g., let’s say you’re writing a book, the structure for a table of contents has been defined once (intro, chapters, epilogue), including rules for each section (prologue shorter than the total of all chapters, each chapter needs a title and a body) but each time you write a book (the tool call) it will be a bit different in what is within the table of context.
4. The tool call is sent to the actual function, real code running somewhere, not the model:
def check_house_address(house_number, zip_code):
# Real logic: queries an actual address database (e.g. USPS)
result = usps_api.lookup(house_number, zip_code)
return {
“valid”: result.exists,
“normalized_address”: result.formatted_address
}
5. Function executes real logic:
• Takes 42 and “10001”
• Sends a real query to the USPS database (or similar service)
• Gets back a true answer: does this address exist? What’s its correct formatting?
6. Function returns a real result:
{
“valid”: true,
“normalized_address”: “42 Main St, New York, NY 10001”
}
7. Model receives that result and converts it into a natural-language answer:
“Yes, 42 Main St, 10001 is a valid address — it’s located in New York, NY.”
Look at that, it’s a real place!! Time to move.