Problem
OpenBot has persistent coworkers, per-Agent computers, governed tool use, and auditability, but it lacks a simple way for Agents to respond with audio (text-to-speech) in addition to text.
For users consuming Agent output in hands-free scenarios (e.g., driving, cooking, monitoring dashboards), there is no way to hear an Agent's response as audio without copying text into a separate TTS tool. This limits OpenBot's accessibility and usability in real-world workflows where audio is preferred or required.
Feature request
Add voice responses — a TTS output layer for any Agent's text response. This should be an integration-layer feature, not a new model-serving infrastructure.
Proposed behaviour
- Allow enabling voice responses per Agent (toggle in Agent settings).
- When enabled, stream the Agent's text response through a configurable TTS provider (e.g., ElevenLabs, PlayHT, AWS Polly) and play audio in the UI.
- Support multiple voice profiles per Agent (e.g., "newsletter voice", "monitoring voice").
- Allow downloading the audio as an MP3/WAV file for offline playback.
- Preserve all governance settings (grants, policies) — TTS does not change what the Agent can do.
- Rate-limit TTS calls to prevent abuse (e.g., max 10 minutes of audio per hour per Agent).
Required controls
- Disabled by default; enabled per Agent.
- TTS scope: per-Agent, not per deployment.
- Immutable audit log showing when TTS was triggered and which voice was used.
- Review, edit, and delete controls for TTS configuration (provider, voice, rate limits).
- Clear separation between TTS output and runtime state (no arbitrary code execution from audio).
- Never automatically grant additional tools or permissions for TTS — grants are unchanged.
- Configurable TTS provider allowlist (specific providers or any URL).
Why this matters
This would make OpenBot more competitive for users consuming Agent output in hands-free or accessibility-focused scenarios while preserving its core advantages: per-Agent isolation, gateway policy enforcement, and action-level auditability. It would be particularly useful for a self-hosted team that wants to listen to newsletter briefings, monitoring alerts, or research summaries as audio without manual copy-paste into a TTS tool.
Acceptance criteria
- A user can enable voice responses for an Agent.
- A user can configure a TTS provider and voice profile for an Agent.
- Agent text responses are streamed through TTS and played as audio in the UI.
- Audio can be downloaded as MP3/WAV for offline playback.
- All TTS triggers appear in the existing audit trail.
- Invalid TTS configurations are rejected with clear error messages.
- TTS-enabled Agents respect the Agent's existing grant boundaries.
Suggested name
Voice Responses or TTS Output Layer
Problem
OpenBot has persistent coworkers, per-Agent computers, governed tool use, and auditability, but it lacks a simple way for Agents to respond with audio (text-to-speech) in addition to text.
For users consuming Agent output in hands-free scenarios (e.g., driving, cooking, monitoring dashboards), there is no way to hear an Agent's response as audio without copying text into a separate TTS tool. This limits OpenBot's accessibility and usability in real-world workflows where audio is preferred or required.
Feature request
Add voice responses — a TTS output layer for any Agent's text response. This should be an integration-layer feature, not a new model-serving infrastructure.
Proposed behaviour
Required controls
Why this matters
This would make OpenBot more competitive for users consuming Agent output in hands-free or accessibility-focused scenarios while preserving its core advantages: per-Agent isolation, gateway policy enforcement, and action-level auditability. It would be particularly useful for a self-hosted team that wants to listen to newsletter briefings, monitoring alerts, or research summaries as audio without manual copy-paste into a TTS tool.
Acceptance criteria
Suggested name
Voice ResponsesorTTS Output Layer