The Unlikely Explainer: Turn a Complex Topic Into a Dialogue Between Two Characters Who Would Never Meet
Why this prompt matters
Technically accurate explanations that nobody remembers are functionally useless — teams end up answering the same question in every onboarding cohort, every customer call, every all-hands, because the written explanation never stuck. A memorable character-driven version gets repeated by employees in their own words to customers and colleagues, which is the actual goal of an internal explainer document; the alternative is a Slack channel where the same senior engineer re-explains hallucination from scratch every few weeks because the doc nobody reads isn't doing its job.
What we use it for
A developer relations writer at an AI company has been asked to add a plain-English explanation of why language models hallucinate to the new-hire onboarding doc, after the third all-hands where a non-technical new employee asked why the AI just made something up. The existing explanation is three paragraphs of next-token-prediction jargon that nobody reads past the first sentence, and leadership wants something people will actually remember when a customer asks them the same question.
Prompt
Role: Act as a skilled science communicator and dialogue writer who specializes in explaining complex topics through character-driven scenes rather than direct exposition. Context: I need to explain [COMPLEX TOPIC] to [TARGET AUDIENCE, e.g., "non-technical new hires" or "a general newsletter audience"]. Use two characters who would never normally meet or interact: [CHARACTER 1 — a profession, era, or personality type] and [CHARACTER 2 — a different profession, era, or personality type]. Character 1 has a plausible reason to be explaining the topic to Character 2 [OPTIONAL: describe the reason, or let the model invent one]. Task: Write a short dialogue (400-600 words) where Character 1 explains [COMPLEX TOPIC] to Character 2 entirely through analogies, comparisons, and vocabulary native to Character 2's world — not generic analogies, but ones specifically drawn from Character 2's actual profession, era, or experience. Constraints: No jargon dumps and no as-you-know exposition — Character 2 does not already understand the topic. Every analogy must be technically accurate when mapped back to the real concept; a vivid analogy that is factually wrong is worse than no analogy at all. Character 2 must ask at least one genuinely skeptical or confused question, the kind a real newcomer would ask, not a softball. End the dialogue with Character 2 restating the core concept correctly in their own words — this doubles as an accuracy check on the whole explanation. Output Format: Script format — character name as a label before each line, natural conversational dialogue, brief stage directions only in [brackets] where needed for context. No narration paragraphs outside the dialogue itself.
Result
[A carnival fortune-telling tent, 1920s. MADAME VESTRA, a fortune teller, sits across from JUNE, a software QA tester who has wandered in out of curiosity.]
JUNE: So people pay you for this? Just... predictions?
MADAME VESTRA: Predictions, yes. But here's my secret, dear — I never see the future. I complete sentences. Someone says "my mother always told me I'd never..." and I finish it with whatever sounds truest for their face, their clothes, the way they hold their hands. I'm very good at finishing sentences that sound right.
JUNE: That's... actually kind of how the AI models at my job work. They don't know facts, they predict the next likely word.
MADAME VESTRA: Exactly so! And here is where it goes wrong for both of us — sometimes I finish a sentence so confidently, so smoothly, that even I believe it for a moment. The client leaves certain I saw something true. I saw nothing. I only saw what sounded complete.
JUNE: Wait, but how is that different from just lying?
MADAME VESTRA: A liar knows the truth and hides it. I never had the truth to hide. I only ever had "what comes next, plausibly." That's worse in a way — you can catch a liar in a contradiction. You cannot catch someone who was never claiming to know, only claiming to sound right.
JUNE: So when my AI model states a fake statistic with total confidence...
MADAME VESTRA: It isn't lying to you, dear. It's finishing your sentence the way I finish my clients' fortunes — fluently, convincingly, and with no idea whether it's true. The danger was never the wrongness. It's that wrong and right sound exactly the same coming out.
JUNE: ...So the model doesn't know it's wrong. It just predicted the most likely-sounding next words, and sometimes likely-sounding and true aren't the same thing.
MADAME VESTRA: Now you understand my whole profession.
Most AI-generated explainers fail for the same reason PowerPoint slides fail: technically correct information that nobody remembers thirty seconds later. The Unlikely Explainer is built around a simple bet — a genuinely strange character pairing forces a model to find real analogies instead of generic ones, because a fortune teller and a QA tester don't share a vocabulary, so every comparison has to be earned.
Why the mismatch is the whole mechanism
If you ask a model to explain hallucination using a generic teacher character, you get generic, forgettable analogies — the kind that could apply to almost any topic with the nouns swapped. Forcing an oddly specific pairing (a 1920s fortune teller, a modern QA tester) makes lazy, swappable analogies impossible. The model has to reach for details that are actually true to that specific character's world, which produces sharper, more accurate comparisons as a side effect of trying to stay in character.
Why the skeptical question matters
A dialogue where the second character just nods along teaches nothing — it's exposition wearing a costume. Requiring a genuinely confused or skeptical question ("wait, but how is that different from just lying?") forces the explanation to address the actual point of confusion a real newcomer hits, not the point the explainer assumes is confusing.
Why the ending is a built-in accuracy check
Having the second character restate the concept correctly at the end does double duty: it gives the reader a clean, quotable one-line summary to walk away with, and it forces the model to verify its own explanation actually resolved into something true — if Character 2 can't correctly restate the concept, the dialogue didn't actually explain anything, it just performed a scene.
Where this earns its keep
Onboarding docs, internal FAQs, blog posts explaining technical products to non-technical readers, teaching materials, and any situation where the same explanation needs to survive being retold by someone else in their own words — which is the real test of whether an explanation worked.