Skip to main content
OpenDot is moving toward an open, provider-pluggable platform for voice agents on real devices. The roadmap is organized around one loop:
The current milestone is a complete local prototype. The next milestones make the runtime, providers, agents, devices, and diagnostics more modular. Later work opens deeper local-network, fleet, open hardware, and on-device paths.
OpenDot roadmap layers diagram

The roadmap keeps the current local prototype connected to later provider, transport, fleet, hardware, and edge directions.

​
Current

Current work should make the local loop reliable and understandable:
  • Create, edit, and select agent identities in the platform console.
  • Configure explicit Sandwich VAD, STT/ASR, LLM, and TTS stages.
  • Test Sandwich microphone turns in Browser Test through runtime /voice.
  • Switch Browser Test agents to Speech-to-speech for native browser WebRTC with OpenAI Realtime.
  • Bind Speech-to-speech agents to Dot devices through the runtime /ws Realtime bridge.
  • Pair Dot devices, claim activation codes, and bind active identity configs.
  • Keep Fastify, Drizzle, PostgreSQL, and runtime token boundaries clear.
  • Run ESP-IDF firmware on the Waveshare ESP32-S3-AUDIO-Board reference target.
  • Keep setup docs, diagrams, and verification commands accurate.

​
Next

Next work should make OpenDot easier to extend without hiding the voice-agent model:

​
Later

Later work should move OpenDot from a local prototype into a platform that can operate across cloud, local network, bare-metal, and on-device targets:
  • Fully local or self-hosted VAD, STT/ASR, LLM, and TTS options.
  • Expand realtime media beyond the current browser WebRTC and device bridge paths: SFU-style fleet paths and lower-level WebSocket bridges where needed.
  • MQTT-style device presence, desired/reported state, commands, telemetry, diagnostics, OTA metadata, and multi-device coordination.
  • Purpose-built open Dot hardware with CAD, PCB, BOM, fixtures, acoustic notes, and repeatable firmware flashing.
  • Exploratory MicroPython runtime and on-device inference research with honest memory, latency, model-size, and firmware-impact constraints.
  • Session history, replay artifacts, eval harnesses, and reproducible bug reports across pipeline stages and devices.
  • Production deployment guidance for cloud, local-network, and bare-metal runtime targets.

​
Not yet goals

These are important, but they should not pull attention away from the current voice-agent/device loop:
  • Hosted multi-tenant SaaS infrastructure.
  • Marketplace workflows.
  • Enterprise SSO, billing, and procurement.
  • Broad hardware support before the runtime, firmware, and reference-device path stabilize.
  • A named integration matrix before provider, framework, and transport categories are stable enough to maintain.

​
Public alpha release bar

The first public alpha should be a source-only release with honest prototype framing. It should not imply Docker images, npm packages, firmware binaries, or an OTA release channel. Before publishing, maintainers should verify:
  • Local platform checks pass with Node 24: pnpm run ci.
  • Dependency audit has no known moderate-or-higher vulnerabilities: pnpm audit --audit-level moderate.
  • Docs links pass with cd docs && mint broken-links.
  • docker compose config --quiet passes.
  • Checked-in GitHub issue templates and SVG diagrams parse.
  • ESP-IDF 5.5.2 can build firmware from dot-device/firmware.
  • Firmware logs do not print Wi-Fi passwords, provider keys, runtime secrets, or device credentials.
  • Browser Test completes one full spoken turn with real provider keys before release notes claim the live voice loop works.
  • Existing pushed release tags, including v0.1.0, are not rewritten.

​
Contributing to the roadmap

Useful roadmap proposals explain:
  • the user, operator, or contributor problem being solved
  • the affected contribution area
  • how it fits the real-device, cloud, local-network, or on-device direction
  • the smallest milestone that can be reviewed and tested
Keep proposals concrete. A good first milestone should usually improve one track, one workflow, and one verification path.