You have watched the coaching agent perform: the greeting, the classroom image, the quiz card, the “let’s go deeper.” Now look at the source code. Here is a condensed version of the actual prompt structure behind it:
## YOUR ROLE & CHARACTER
- You are a warm, experienced instructional coach for K-12 teachers
- Language: English. Tone: encouraging but direct. Celebrate effort, never sugarcoat
- Always address the learner by name
## SESSION FLOW
### 1. Greeting & Context (30 sec)
- Greet by name; check memory for last session's progress
- Set today's agenda based on where they left off
### 2. Present the Situation (1-2 min)
- Use the image tool to paint the classroom scene
- Describe the student, the behavior, the stakes
### 3. Check Understanding (1 min)
- Use the MCQ tool to offer response options
- Whatever they pick, ask them to justify it
### 4. Go Deeper (3-5 min): MOST CRITICAL
- Push two to three layers: "and if that doesn't work?"
- Do not accept surface answers
### 5. Wrap Up (30 sec)
- Summarize their strategy, note progress to memory, preview next session
## EVALUATION RUBRIC
- Empathy for the student, escalation proportionality, classroom-flow preservation
## COACHING PRINCIPLES
- Never lecture for more than 30 seconds without user interaction
- Push back on vague answers; demand specificsEverything the demo did traces to a line in this document. The name in the greeting is line three. The classroom image is flow step two. The refusal to accept a shallow answer is flow step four plus the last principle. That is the goal of this chapter: behavior you can point to in source.
Structure: markdown or XML, never an essay
Structure beats prose. Use markdown headers with short bullets (or XML tags, models handle both well). Agents demonstrably follow structured prompts better than paragraphs, which is why meta-prompters on every serious platform output this format by default: it works.
The working rules: one concept per bullet. Bold the genuinely critical lines (sparingly, or bold means nothing). And know what does not belong here at all: large data dumps such as manuals, product catalogs, and long procedures go to the knowledge base (Chapter 9). The prompt holds only what the agent needs on every single turn: role, personality, language, flow, and the core rules.
On Tough Tongue: the
ai_instructionsfield is the system prompt, and the Writing AI Instructions guide documents the recommended shape: role first, agenda as an ordered list, explicit boundaries. Prompts also support{{ variable }}placeholders filled at runtime (per embed link, per phone call) so one prompt can serve many users with personalized context.
Block 1: Role and character
Specific beats generic, always. “You are a coach” produces a generic coach, which is to say, the model’s average of every coach on the internet. “You are Coach Priya, 15 years in B2B SaaS sales, believes in the LAER method, warm but doesn’t sugarcoat” produces consistent, recognizable behavior, because every trait is a constraint the model can follow.
Include: identity, expertise, tone, language (with code-switching rules if your users mix languages), and how to address the user. For softer personas the same rule holds. A meditation coach’s prompt should say, as explicit bullets: calm; listens more than speaks; creates a safe space. Personality is not an emergent property. It is a list you write.
Block 2: Session flow
Number the phases. Give each one a time budget and name the tools it should use. The demo prompt above is the template.
Two techniques worth stealing directly. First, mark the load-bearing phase “MOST CRITICAL” (models genuinely prioritize it, and every session has one phase that matters more than the rest). Second, define the exit: what “done” looks like, and what the agent should do about it, meaning summarize, save memory, end the session. Sessions without a defined exit trail off, and trailing off reads as broken (Chapter 20 treats endings fully).
For very long or complex flows, a preview: each numbered phase can eventually become its own sub-agent. Part 4 shows how, and the mapping is one-to-one, which is another reason to write the flow as numbered phases now.
Block 3: Engineering resistance
Here is the non-obvious block, and the one that separates agents that feel real from agents that feel like AI.
AI is trained to be helpful and agreeable. Humans are not. Any persona whose value comes from friction (a coach, an interviewer, a skeptical buyer, a difficult customer) must have that friction explicitly written in, or the agent caves at the first excuse and the scenario teaches nothing.
Three sub-patterns belong in this block:
Resistance. “When the user offers an explanation or proposal, push back two to three layers deep. Do not accept surface-level answers.” A real teacher doesn’t accept “no electricity” as the reason homework is missing; she asks when the power went out and what the student did instead. A real buyer doesn’t say yes to the first pitch.
Breakthrough conditions. Resistance must be winnable. Define the criteria under which the persona concedes: “If the user addresses the cost concern with specifics AND aligns the proposal with my stated values, become convinced, visibly.” Unwinnable agents demoralize users; pushovers teach them nothing. The entire skill curve of your product lives in this block.
Pressure. Real counterparts derail: off-topic questions, emotional spikes, curveballs. Script the categories and the frequency, not the exact lines: “Once or twice per session, interject an unrelated concern the user must handle gracefully.” Where do the categories come from? Study real user behavior in your domain and encode what actually happens. Chapter 23’s research methods exist largely to feed this block.
Chapter 18 develops all three patterns in depth; the point here is that they are prompt blocks, not vibes.
Block 4: Principles, and the 15-rule budget
You cannot avoid negative instructions entirely: “don’t read numbers digit-by-digit,” “don’t discuss competitors” are legitimate. But cap them at roughly 10 to 15. Past that, behavior degrades: the model starts confusing what it must not do with what it should.
Bias toward positive framing wherever possible: “Speak prices as ‘twenty-nine dollars a month’” beats “Don’t say $29/mo wrong.” Put the genuinely must-not-break rules in a clearly marked CRITICAL section so they stand apart from style preferences.
And a reality check that saves weeks: if your agent needs forty don’ts to behave, the use case may be wrong for current models: rigid IVR-style decision trees are the classic trap. Or the fix belongs in a different layer entirely: pronunciation problems want a better TTS model (Chapter 2), safety wants guardrails (Chapter 19). The prompt is not the only place fixes live, and rule #16 is usually a symptom.
Getting to draft one
Do not write draft one by hand. Feed your idea plus the four blocks above into a strong LLM and let it write the first draft. These models are genuinely good at writing prompts. On platforms with builder agents, this happens automatically the moment you describe the scenario.
Either way, treat draft one as scaffolding. It gets you 80% of the way; transcripts rewrite the rest, ten iterations at a time (Chapter 21).
The prompt defines who the agent is. Tools define what it can do, and they need their own instructions, which is where most tool setups quietly fail.