Introduction
A good voice interaction is designed, not improvised. The way you phrase a spoken request, and the way you steer the agent toward speakable replies, decides whether voice feels fluid or frustrating. This lesson is about shaping the conversation itself.
Key Concepts
- Voice flow: The back-and-forth rhythm of a voice conversation, shaped by how requests and replies are phrased.
- Framing: Wording a request so the agent's reply is naturally suited to being spoken.
- Brevity: Keeping spoken turns short enough to hold in working memory without scrolling back.
- Speakable reply: A reply made of prose, not dense code, tables, or long lists.
Real World Context
A developer in voice mode asks "show me the auth module" and the agent dumps a 200-line file that TTS dutifully starts reading aloud. The interaction collapses. The same developer asking "summarize what the auth module does in three sentences" gets a reply that is a pleasure to hear. The agent did not change. The framing did.
Deep Dive
Two levers shape every voice flow: brevity and framing.
Brevity. Spoken conversation lives in working memory. A listener cannot scroll back through audio the way a reader scrolls through text. So both halves of the exchange should stay short. Your requests should be one clear idea at a time, not a paragraph of compound instructions. And you should steer the agent toward short replies, because a long spoken reply overflows what you can hold in mind. If you need depth, ask for it in stages: a summary first, then "tell me more about the second point."
Framing. The agent will answer the question you actually asked. In text mode a sprawling reply is fine, you can skim it. In voice mode the reply becomes audio, so you must frame requests so the natural answer is speakable. Compare:
- "Show me the config file" invites a raw dump, terrible as audio.
- "Tell me what the config file is responsible for" invites prose, good as audio.
Framing for voice means asking for explanations, summaries, comparisons, and decisions (all naturally prose) rather than asking for code, files, or tables (all naturally visual). When you genuinely need the visual artifact, that is your signal to drop back to text for that turn.
There is a rhythm that works well: short request, speakable reply, short follow-up. You ask one thing, hear a digestible answer, and refine. This iterative loop suits voice far better than one giant request followed by one giant reply. It also limits the damage of any single misrecognition, because each turn is small.
Designing the flow is your job, not the agent's. The agent responds to what you give it. Give it short, well-framed prompts and the voice conversation flows. Give it long, visual-output prompts and it fights the modality.
Common Pitfalls
- Asking for visual artifacts in voice mode: Requesting code, files, or tables produces replies that are painful as audio. Frame for prose, or switch to text for that turn.
- Packing multiple instructions into one spoken turn: Compound requests are hard to phrase and hard to recover from if misheard. One idea per turn.
Best Practices
- Frame for speakable replies: Ask for summaries, explanations, and decisions rather than dumps of code or data.
- Work in short iterative turns: Prefer short request, digestible reply, short follow-up over one large exchange.
Summary
- Voice flows are designed through brevity and framing, not improvised.
- Spoken conversation lives in working memory, so keep both requests and replies short.
- Frame requests so the natural reply is prose, not code, files, or tables.
- Work in short iterative turns; switch to text when you genuinely need a visual artifact.
Code Examples
# Poorly framed for voice: invites a raw dump that TTS reads aloud
# (spoken) "Show me the entire auth module"
# Well framed for voice: invites a short, speakable prose reply
# (spoken) "In three sentences, what does the auth module do?"
# (spoken) "Now tell me more about the token refresh part"