---
name: podcast-dialogue-writing
description: How to turn a paper analysis into a two-host script someone can follow while running, and the hard limits the audio API imposes.
when_to_use: You are writing the script phase of a Continuous Research mission, turning analysis.md into script.md and episode.json.
tags: [research, writing]
---

# Writing for someone on a treadmill

The listener is not at a desk. They cannot scroll back, they cannot see a table,
and they are half-listening. Everything follows from that.

## Structure

Lead with the conclusion, then support it. A paper-by-paper walk is the wrong
shape: the listener does not know which papers matter until you tell them, and
by then the first one is gone.

```
COLD OPEN   one sentence: the single thing that changed today
THE MAIN    the paper that actually matters, 3-4 minutes
THE REST    two or three, a minute each
NOTHING     what you looked at and dismissed, 20 seconds
```

"Nothing" is not filler. Knowing that eleven papers were read and eight did not
matter is what makes the three that did credible.

## Two hosts, with a reason to be two

HOST carries the thread and asks what the listener would ask. GUEST has read the
paper and answers. The reason for a second voice is that disagreement and
"wait, why?" are easier to follow than monologue — not that alternating names
looks like a script.

Bad, because these are one voice cut in half:

> HOST: The paper introduces a new pruning method.
> GUEST: Yes, and it improves recall by 12%.

Good, because the second voice is doing work:

> HOST: Twelve percent recall — is that on a benchmark we'd care about?
> GUEST: That's the catch. It's on SIFT1M, which is a million 128-dim vectors.
>        Our embeddings are 1536-dim and we're at about 40,000. So the shape of
>        their win might not survive at our dimensionality.

## Say numbers the ear can hold

"Roughly a third faster" beats "34.7% faster". "About a million vectors" beats
"1,000,000". Read every line aloud in your head; if you stumble, the TTS will
too.

Never write anything the listener cannot hold: no URLs, no arXiv ids, no table
references, no "as shown in Figure 4". If they need the citation it is in the
vault note.

## Hard limits, not style preferences

`episode.json` is consumed by the audio API, and these bounds are enforced by it:

```json
{ "title": "<one line, under 80 characters>",
  "highlights": ["<each 10-70 characters>", "..."] }
```

- **At most 5 highlights**, each **10–70 characters**. Outside that range the
  request is rejected, not truncated.
- Target **seven minutes of speech, roughly 1,000 words**. Audio quality
  degrades on long single generations, so a sprawling script produces a worse
  episode, not just a longer one.

## Cut rather than pad

If only one paper mattered, write a four-minute episode about one paper. An
episode padded to length with work that did not matter trains the listener to
skip, and once they skip, the whole pipeline is worthless.