Two versions of the classroom-escalation demo, one difference between them.
The voice-only version: the coach describes the classroom. “Imagine a seventh-grade social studies class. There’s a bright student named Mia, sitting near the back, and she keeps…” Forty seconds of setup that the user half-retains, because voice evaporates as it goes.
The tool version (the actual demo): one image call paints the room, one MCQ frames the choice, and the user is inside the scenario in ten seconds. The conversation spends its minutes on judgment instead of exposition.
Same content. The tools bought back the attention budget. Which suggests the test this chapter applies to everything: a tool earns its slot when transcripts with it show different user behavior than transcripts without it. Not more impressive demos. Different behavior. Everything else is decoration.
The core five
The proven set for conversational agents. For each: the job, the trigger, the instruction pattern (all in Chapter 8’s when/interpret/how-often grammar).
Image generation: the scene-setter. Job: replace paragraphs of verbal description with one visual, Chapter 1’s rule (“more than two sentences to say → show it”) made mechanical. Trigger: every new scenario, every location change, any user confusion with a verbal description. Frequency: “at least once per scenario.” One craft note: instruct the agent on what images should contain (mood and situation, not text-heavy diagrams), because image models render text poorly and a diagram full of garbled labels breaks immersion instead of building it.
MCQ and cards: the decision crystallizer. Job: pin a decision point, and bypass voice’s working-memory ceiling, because the options stay on screen while the user thinks. Trigger: comprehension checks, branch points, self-assessment. And always attach the demo’s follow-through rule: never reveal the answer; make them justify the pick. The MCQ is not the assessment. The justification is.
Slides: the structured-content rail. Job: walk an existing deck (a training, a pitch) with the agent navigating and discussing per slide. Trigger: content that already lives in deck form. Don’t rebuild a deck as prompt text; per Chapter 9’s sorting rule, it is referential content that happens to have a presentation layer.
Memory search: Chapter 12’s tier-two retrieval. Search when the user references history that isn’t in super memory; weave results in, never recite them.
End session: Chapter 20’s deliberate close. Exactly once, only after the wrap-up summary. Also the enforcement mechanism for Chapter 19’s third strike.
On Tough Tongue: all five ship built-in, alongside a longer tail (whiteboard, Mermaid diagrams, Google Slides navigation, timers, notepads, a cloud browser), each enabled per scenario via
tools_config. The tool reference documents the full list; theadd_to_system_promptflag injects starter instructions you should then tailor, exactly per Chapter 8.
Custom tools: reaching into real workflows
The core five make a great practice experience. Custom tools are where agents graduate to production utility: check a real calendar, create the CRM lead, file the support ticket, send the follow-up email.
The Chapter 8 discipline applies unchanged: you implement the endpoint, register the schema, and write the instructions everyone forgets. Take scheduling as the canonical example: a calendar integration isn’t built into most platforms. There has to be an endpoint, and the implementation is yours to take care of. The platform’s job is calling it at the right moment with the right arguments.
The design reminders, compressed from Chapter 8 because they matter double in production: small structured results, idempotent endpoints (agents occasionally double-call, and two calendar invites is a bug you built), and a speakable error shape: “I couldn’t reach the calendar; tell me your preferred time and I’ll note it.”
On Tough Tongue: custom tools are HTTP functions (name, description, method, URL, headers, and a JSON Schema for parameters); the agent decides when to invoke them mid-conversation and speaks the result. The custom tools guide covers setup and testing, and webhooks cover the reverse direction: your systems reacting to session events.
And when your custom-tool list starts looking like a subscription list, MCP tool servers are the scaling path: same mental model, externally hosted and maintained.
The subtraction pass
Tool lists only grow, so the discipline has to push the other way.
Every registered tool costs twice: context tokens for its schema on every turn, and decision load, one more option the model weighs every time it acts. Chapter 5’s dilution argument applies to tool registries exactly as it applies to prompts. A fourteen-tool agent is not seven times more capable than a two-tool agent; it is measurably more confused.
So, quarterly ritual: pull ten transcripts. Any tool unused in all ten faces a choice: either its trigger instruction gets sharpened (Chapter 21’s loop, applied to the tool layer) or it gets unregistered. No sentimental exceptions.
The demo agent that opened this playbook used four tools, not fourteen. Its power was instruction quality, not registry size, and that ratio is worth carrying into every build.
Patterns, loop, tools: all of it replicable by any competent builder in a weekend. The one input nobody can give you is what your agent should actually know. That is last, because it is the moat.