Voice, TTS, and multimodal input

Hands-busy and eyes-busy workflows:

• Voice-to-task: dictate briefs, corrections, or approvals on the go.
• TTS readback of summaries, diffs, or alerts when reading text is awkward.
• Accessibility: same workflows for people who prefer speech.

Community stories often mention not typing—the product goal is parity of control, not novelty.

• Channels (where supported) already meet users on mobile-first surfaces.
• Structured outputs still matter—voice is input; artifacts remain text or files for audit.
• Approvals can require explicit spoken or typed confirmation for sensitive actions—configure to policy.

1. Define what may be spoken vs what must be typed (financial, legal).
2. Normalize STT output: trim filler, confirm numbers and names.
3. Log redacted transcripts if retention policy allows—never raw secrets.
4. Test TTS for clarity on technical terms (repos, hashes, IDs).
5. Fallback to text when the ASR confidence is low.

• Provider or local stack for STT/TTS compatible with your privacy bar.
• Locale and accent coverage expectations—document limitations.
• Consent if voice is stored or reviewed for quality.

1. Ship read-only TTS summaries first.
2. Add voice capture for short commands with confirmation.
3. Measure error rate on domain vocabulary; maintain a custom lexicon if needed.
4. Review a sample of transcripts weekly.
5. Expand only where accuracy holds.

• “Repeat back entities you understood: names, amounts, dates.”
• “Refuse to act if confidence on this transcript is below threshold—ask one clarifying question.”
• “Give a 30-second TTS-friendly summary.”

• Mis-hearing path tested for top ten commands.
• Mute and stop behaviors are obvious in the UI or channel.
• Data handling matches privacy policy and regional law.

• Over-trusting STT for passwords or one-time codes.
• Leaking private speech to the wrong channel.
• TTS reading secrets aloud in shared spaces.
• Accessibility theater—voice without real control parity.