Why it matters in this material Function/tool calling appears in this channel's material as the mechanism that lets a model reach outside plain text generation and invoke a capability — most concretely, the code interpreter that runs inside a custom GPT. ## How it shows up During the live custom-GPT build with OpenAI's Logan Kilpatrick, playtesting revealed a design gap: the game model was always positive, so the builders needed real stakes. The fix was to have the model call a tool — rolling a dice via the code interpreter — to introduce randomness into the scenario. [^01a0f15b-3407-78e4-9a1c-de04fa55d0bf@5912] That example captures the pattern worth understanding: tool calling turns a limitation of the prompt itself into a solved problem. Rather than trying to word a prompt so the model behaves randomly, you give it a tool whose output is genuinely random, and the model incorporates that result into its response. <Section title=“What to take from this”> - A custom GPT is still inherently ChatGPT — no new raw capability — but tools like the code interpreter extend what a well-crafted prompt alone can achieve. [^01a0f15b-3407-78e4-9a1c-de04fa55d0bf@1058] - Reach for a tool when the prompt can't produce the property you need: randomness, computation, or verified data are classic candidates. - In the playtest-and-revise loop, a missing behavior (always-positive outcomes) was diagnosed through play and then fixed by adding a tool call — the eval loop told them what the tool was for. [^01a0f15b-3407-78e4-9a1c-de04fa55d0bf@4807] </Section> <KeyPoints> - Function/tool calling = the model invoking an external capability, such as the code interpreter, instead of relying purely on generated text. [^01a0f15b-3407-78e4-9a1c-de04fa55d0bf@5912] - In the captured build, a dice roll via the code interpreter added stakes the model's own outputs couldn't provide. - Use the playtest loop to discover when a tool call is needed, then wire it in. </KeyPoints>