Hello Hello,
I haven't written in a few weeks. Part of that is travel, as I'm in India visiting family. The bigger reason is that I've been rebuilding the AI PM Accelerator for the next cohort, which starts on 31st October.
I rebuilt it because I believe AI is changing what it means to be a product manager, and I wanted the course to teach where the job is going, not where it has been.
I believe this because I see it at work every day. I work on AI products at Yelp, most recently launched Yelp reservations and waitlists in ChatGPT. But launches like that are only one part of the change. The much bigger part is that products are now being built with AI at their core. That changes how you decide what to build, how you design it, and how you know it's working.
The PMs who learn to build this way will shape the next decade of products. The PMs who don't will watch from the sidelines and get left behind.
That's why I've put everything I know about AI, PM, building at scale into this cohort.
And because enrolling in a course (and deciding how to learn AI product management) matters so much, I want you to make it with the full picture. Over the next few weeks, I'll send everything: what's inside, who it's for, who it isn't for, and what it unlocks for your career. So you can decide if it actually makes sense for your career goals.
I'd rather you say no with full information than yes without it.
Join the waitlist here to get the details.
Now, on to this week's issue…
How An AI Agent Actually Uses A Tool
An LLM — the large language model behind ChatGPT and Claude — can't send an email. It can't run a database query or click a button either. The only thing it can produce is text.
So when an agent books a meeting for you, the LLM isn't the thing booking it. The LLM writes a request — in plain structured text, like book_meeting, time: 3pm — and hands it off. Separate code reads that request and does the actual booking.
That split — the LLM decides what needs to happen, your code makes it happen — is the whole idea behind every AI agent. It's called function calling (some people say tool use), and it's the same mechanism under every MCP server and "AI that does stuff" demo you've come across.
How tool use actually works: the order-ticket analogy
Picture a waiter at a restaurant. They can talk to you all day and take any order, but there's one thing they can't do: cook. They never touch a pan.
You order the salmon. The waiter writes it on a ticket and hands it to the kitchen. The kitchen cooks it, and the waiter brings the dish back to your table.
That waiter is the LLM. The kitchen is your code. The LLM can't cook — it just writes the ticket, and your code does the work and hands the result back.
The LLM decides what to do. Your code does it. That gap is the whole idea.
How the model knows which tool to pick
A waiter can only ask the kitchen for things it actually does. So before any of this starts, you hand the LLM a menu.
That menu is a list of tools. Each tool comes with three things: a name, a plain-English description of what it does, and the inputs it needs.
An order tool might look like this:
name:
place_orderdescription: "Send a food order to the kitchen."
inputs:
dish(a string, e.g. "salmon")
You send this menu along with the user's message.
Now the LLM has a real option. It doesn't have to fake an answer — it can write a ticket the kitchen will actually act on. When your request matches a tool on the menu, the LLM writes that tool's ticket and fills in the inputs.
How an Agent uses a tool with example
The LLM picks tools based mostly on their descriptions.
So if two tools do similar things and the descriptions are vague, the LLM picks the wrong one. Or it fills in the wrong inputs.
A lot of "our agent is not doing the right job" comes down to badly written tool descriptions. That's not really an engineering problem. It's a writing problem. The words you use to describe a tool are part of the product.
Take two tools on the same menu: place_order and book_table.
If both just say "help the customer," the LLM can't tell them apart. Someone asks to book a table for tonight, and the LLM puts in a food order instead.
Now sharpen the descriptions. One becomes "send a food order to the kitchen." The other becomes "reserve a table for a given time and party size." The mix-ups stop.
Nothing about the LLM changed. The menu just got clearer. And that fix lives entirely in plain English.
What happens in a single tool call: the 5 steps
Put it together, and every agent action follows the same five steps. It doesn't matter how fancy the agent is.
Anthropic's own tool-use docs lay it out like this. OpenAI and Google work the same way. Only the labels differ.
You define the tools. This is the menu of what the LLM is allowed to ask for.
You send the message and the menu together. "I'll have the salmon" — with the tools attached.
The LLM replies with a ticket, not an answer. It hands back a structured request:
place_orderwith{"dish": "salmon"}. It hasn't cooked anything yet.Your code runs the function. Your software reads the ticket, sends the order to the kitchen, and gets back "one salmon, ready."
You feed the result back. The LLM turns it into a normal reply: "Your salmon is on its way."
So the LLM runs twice: once to write the ticket, and once more to give you the final answer. Your code does the one real bit of work in between — the actual cooking. That's the whole loop.
Now scale it up. Add more tools. Let the LLM make several calls in a row, reading each result before it decides the next step. That's an agent. An agent is just this loop, running over and over until the job is done.
One request, from question to answer. The LLM never touches the Weather API itself. It just asks for the tool, and the backend makes the real call.
Function calling vs tool use vs MCP
First, some relief: three of these words mean the same thing. OpenAI calls it "function calling," Anthropic calls it "tool use," Google calls it "function declarations." It's the same loop you just saw, with three different labels. Learn one and you've learned all three.
MCP is the odd one out. It's not another name for tool use — it's a layer that sits on top of it.
Here's what it's for. Every tool you give an LLM has to be wired up by hand: you write its description, connect it to the real service, and handle what comes back. Ten tools means ten custom integrations. MCP is a shared standard for that wiring — a tool built for MCP plugs into any app that supports MCP, with no custom code each time.
So they're not rivals. Function calling is how the LLM asks to use one tool. MCP is how you hand it a whole shelf of tools without wiring each one up yourself. You'll almost always see them together — but only function calling is the actual mechanism.
Why this changes how you build agents
Here's what changes once this clicks. When an agent does the wrong thing, "the AI messed up" stops being the answer. The problem is almost always one of three specific, fixable spots: the tool's description was too vague, so the LLM picked the wrong one; the LLM filled in a bad input; or your code sent back a result it couldn't use.
It also settles who's in charge. The LLM only decides what should happen — your code does every real action. So every guardrail, every permission, every safety check lives with you, not the model. The agent never sent that email on its own; it wrote a ticket, and something you built chose to honour it.
So the LLM is a decision-maker, not a doer. Everything that actually matters — the bugs and the safety both — sits in your code, not the model. That's not a limitation. It's control.
That’s it for today,
Sid