When most people talk about “voice AI orchestration,” they’re usually describing a cloud workflow: audio comes in, gets sent to the server, runs through ASR, an LLM, and TTS, then gets streamed back to the user. That model has been good enough for a first generation of voice products, and it’s what most of the market still assumes by default.

But that framing is already starting to break.

Because increasingly, the best voice systems are not entirely cloud-based. Parts of them are running directly on the device: speech recognition, wake word detection, turn detection, audio preprocessing, lightweight models, even text-to-speech. And once that becomes possible, orchestration stops being just a backend workflow problem. It becomes a real-time audio routing problem that spans the device and the cloud together.

That’s what we mean by hybrid audio graph orchestration.

At a high level, hybrid orchestration means some components of your voice stack run locally, while others run remotely, and the system can intelligently route between them. A simple version might run ASR and TTS on-device, while sending only text to a cloud-hosted LLM. That alone can reduce latency, lower bandwidth, improve privacy, and cut cloud cost. But the more interesting version is when the graph becomes adaptive.

For example, you might run ASR locally by default, but if transcription confidence falls below a threshold, automatically fall back to a cloud model like Deepgram. Or you might keep a lightweight model on-device for fast interactions, but route more complex reasoning to a larger cloud model only when needed. The exact routing logic depends on the use case, but the architectural pattern is the same: local-first when possible, cloud when useful.

That’s a very different way to think about voice infrastructure than what most orchestration tools are designed for today.

Platforms like Vapi, LiveKit, or Pipecat are useful for cloud-side coordination. They help developers chain models together, manage streaming sessions, and structure real-time interactions. But they largely presume that orchestration happens in the cloud. They don’t really help you build and run on-device audio graphs, or manage the messy, real-time coordination between local execution and remote execution that hybrid systems require.

And that gap matters more than it sounds.

Voice products are unusually sensitive to bad architecture. A text product can often hide latency, recover from interruptions, or tolerate a little sloppiness in how requests move through the stack. Voice can’t. If the timing is off, the experience feels bad immediately. If the audio path is brittle, users notice immediately. If every utterance has to round-trip to the cloud before anything useful can happen, the whole product starts to feel heavy and fragile.

That’s why hybrid orchestration isn’t just an optimization. It’s increasingly the right default architecture.

Take a simple voice assistant inside a mobile app. In a cloud-only setup, every utterance gets streamed upstream for transcription, reasoning, and speech generation. In a hybrid setup, the device can detect speech locally, transcribe locally, route only text to the server, and even fall back to local-only behavior if the connection gets weak. To the user, it just feels faster and more reliable. To the engineering team, it’s a radically different system.

And once you start building these systems seriously, linear “pipelines” stop being the right abstraction. Real products are not just mic → ASR → LLM → TTS. They branch. They fork. They degrade gracefully. They make decisions. They run multiple things in parallel. One path might feed a recorder, another might run VAD, another might do speaker identification, another might choose between a local or remote model based on context, confidence, or network quality.

That’s why we think audio graphs are the right abstraction.

A graph lets you think in terms of nodes, routing, fallbacks, and conditions rather than pretending every voice experience is just a neat little chain of APIs. And once you think in graphs, hybrid architecture starts to feel obvious. Some nodes belong on the device. Some belong in the cloud. Some should be able to move between the two over time. The important thing is that developers can actually compose, test, and evolve that logic without rebuilding the whole stack every time the product changes.

That’s the missing layer.

At Switchboard, this is exactly how we think about voice AI. Not primarily as a sequence of model calls, but as a real-time audio graph that may span local and remote execution. The job of orchestration is not just to call APIs in order. It’s to make it easy to build systems where some nodes run on-device, others run in the cloud, routing can change dynamically, and the whole thing still behaves like one coherent real-time runtime.

That’s what hybrid audio graph orchestration actually is.

And over time, we think it’s where the market is headed.

Cloud orchestration was the first chapter of voice AI.

Hybrid audio graph orchestration is the next one.