Managed vs Self-Hosted Voice Agent Orchestration

Every voice agent needs an orchestration layer. It is the conductor. It listens for the end of a turn, calls the language model, fires the tools, and speaks the reply. It handles interruptions, timeouts, and handoffs. Get it wrong and the agent talks over people or stalls mid-sentence.

You have two ways to get that layer. You can rent it, or you can run it. A managed service hosts the orchestration for you behind a console and an API. A self-hosted) approach means you take an open framework and operate it on your own infrastructure. This post is about that one decision.

It is a narrow decision on purpose. This is not the broader question of which models to buy or whether to assemble your own stack. That larger economics question lives in our build vs buy the voice agent stack guide. Here we stay on one layer: who runs the conductor.

What the orchestration layer actually does

The orchestration layer sits between your telephony and your models. Audio comes in from the caller. Words go out to the caller. In between, a lot happens fast.

It detects when the caller stops speaking. It decides whether that pause is a real turn or a breath. It sends the transcript to the language model. It streams the reply to text-to-speech. It watches for barge-in when the caller interrupts. It manages tool calls, retries, and escalation to a human.

All of this runs on a tight clock. Callers notice delay above roughly a quarter second. The telecom standard for one-way mouth-to-ear delay, ITU-T G.114, sets 150 milliseconds as the comfortable ceiling. Orchestration is where that budget is won or lost.

So the question is not whether you need this layer. You do. The question is who operates it, patches it, and answers the pager when it breaks at 2am.

Managed orchestration: rent the conductor

A managed platform runs the orchestration for you. You describe your agent in a console or a config file. You wire in your models and your telephony. The platform handles the rest: turn-taking, streaming, scaling, and uptime.

The appeal is speed. A small team can ship a working agent in days, not months. There is no cluster to provision. There is no turn-detection logic to tune. The hard, latency-sensitive plumbing is already built and battle-tested.

The other appeal is a lower ops burden. Patching, scaling, and on-call all belong to the vendor. Your engineers write agent logic, not infrastructure. For a team without a dedicated platform group, that trade is often decisive.

The cost shows up in three places. You pay a per-minute or per-seat premium over raw infrastructure. You accept the platform's opinions about how orchestration should work. And your call data flows through someone else's systems, which matters for data residency and regulated workloads.

Self-hosted orchestration: run the conductor yourself

Self-hosting means you take an open framework and operate it. The code runs on your servers, in your cloud account, inside your network boundary. You own the deployment, the scaling, and the upgrades.

The payoff is control. You can tune turn detection for your accents and your noise. You can inject custom logic anywhere in the loop. You can pin versions, run experiments, and change behavior without waiting on a vendor roadmap.

The second payoff is cost at scale. Managed per-minute pricing is convenient at low volume. At millions of minutes a month, running the layer yourself on reserved capacity is often far cheaper. The crossover point is where many teams start the migration.

The third payoff is data residency. Calls never leave your boundary. Transcripts land in storage you control. For healthcare, finance, and government work, that is frequently a hard requirement, not a preference. Open frameworks also let you read the code, which many favor for the same reasons people favor open-source software.

The bill comes due in operations. You now own uptime, patching, capacity planning, and the 2am page. You need engineers who understand real-time audio. That expertise is scarce and expensive, and it never stops being needed.

Managed vs self-hosted: a side-by-side

The trade-off is not about quality. Both approaches can run an excellent agent. The difference is in what you own and what you pay. Here is the contrast across the dimensions that decide it.

Read across any row and the pattern holds. Managed shifts effort and risk to the vendor for a fee. Self-hosted keeps both, and the control and savings that come with them. Neither is right in the abstract.

When to start managed and when to graduate

Most teams should start managed. Early on you are hunting for product-market fit, not optimizing infrastructure cost. Speed to a live agent matters more than a cent per minute. Managed lets you learn from real calls fast.

Managed stays the right answer while three things hold. Your volume is modest. Your data has no strict residency rule. And the platform's orchestration behavior fits your use case without heroics. Break any of those and the math shifts.

You graduate to self-hosted when a specific pressure appears. Volume climbs until the per-minute premium dwarfs an engineer's salary. A compliance requirement demands calls stay inside your boundary. Or you hit a control ceiling the platform cannot lift. Migration is a response to pressure, not a rite of passage.

The mistake is graduating too early. Building your own orchestration before you have volume or a compliance driver spends scarce engineering time on a problem you do not yet have. Our voice agent production readiness bar helps you judge whether that pressure is real.

The hybrid pattern most teams land on

The choice is rarely all or nothing. Many mature teams run a hybrid. They keep managed orchestration for some traffic and self-host the rest. The split follows the pressure.

One common pattern splits by workload. Low-stakes, high-variety flows stay managed, where iteration speed matters. High-volume or regulated flows move to self-hosted, where cost and residency dominate. Each flow lives where its constraints are cheapest to satisfy.

Another pattern uses managed as an on-ramp. New agents launch managed to validate the use case. Once a flow proves its volume and its value, it migrates. The managed platform becomes a staging ground, not a permanent home.

A hybrid only works if switching is cheap. That means an abstraction layer between your app and the orchestration, so a flow can move without a rewrite. It also means avoiding deep coupling to any one platform's proprietary features. Our voice AI vendor lock-in guide covers how to keep that door open.

How to choose your orchestration approach

The decision is answerable in an afternoon if you ask the right questions in order. Work through these six steps before you commit to either path.

1. Size your volume, now and in a year. Estimate monthly minutes today and your realistic twelve-month number. Low volume favors managed. High and growing volume starts to favor self-hosted. Write both numbers down before anything else.

2. Check your data residency rules. Ask whether calls and transcripts may legally leave your boundary. If a regulation says no, that alone can force self-hosted. If there is no such rule, this constraint drops out. Settle it early.

3. Audit your platform team's capacity. Be honest about who will run real-time audio infrastructure at 2am. If you have no such team, managed is far safer. If you do, self-hosting becomes a real option. Do not assume you will hire your way there in time.

4. Estimate total cost of ownership, not sticker price. Compare the managed per-minute bill against self-hosted infrastructure plus the fully loaded engineers to run it. Use total cost of ownership, not the headline rate. Include on-call, upgrades, and the cost of an outage.

5. List the control you actually need. Name the specific behaviors you must customize: turn detection, barge-in timing, custom tool logic. If a managed platform supports them, control is not your bottleneck. If it cannot, that is a concrete reason to self-host.

6. Design for a reversible decision. Whichever you pick, put an abstraction layer between your app and the orchestration. Keep prompts and configs in your own repo. That way starting managed does not trap you, and self-hosting does not lock you out of going back.

Why the decision is reversible only if you evaluate

Every step above assumes you can tell whether a switch improved anything. Most teams cannot. Their only quality signal is the platform they already use. That is the quiet trap in this whole decision.

Consider a migration from managed to self-hosted. You move a flow to save money. Did latency get worse? Did the agent start mishandling interruptions? Without a neutral yardstick, you are guessing. The savings mean nothing if quality quietly dropped and you never saw it.

A vendor-neutral evaluation fixes this. You build one test suite you own: your scenarios, your caller profiles, your scoring rules. You run it against the managed setup and against the self-hosted one. Same test, same scale. Now the comparison is real, and the decision has evidence behind it.

This is why evaluation is not a separate project from the orchestration choice. It is the thing that makes the choice safe. Our voice agent evaluation guide covers how to build that suite, and our voice agent stack guide shows where the layer fits.

Common mistakes on both paths

Managed teams drift into lock-in through convenience. They build call logic in the platform's proprietary console because it is faster than an adapter. A year later there are a hundred flows there and no way to move them. The fix is discipline: keep logic in your repo, treat the platform as a runtime.

Self-hosted teams underestimate the ops tax. They ship the framework, celebrate, then discover that turn detection needs constant tuning and the pager never sleeps. The fix is honesty up front about the standing cost, not just the build cost.

Both paths share one failure. They pick without a way to measure the result. So they cannot prove the choice was right, and they cannot safely reverse it. The voice agent vendor evaluation guide turns that gap into a checklist you can run.

Frequently asked questions

What is voice agent orchestration?

Orchestration is the layer that runs your voice agent in real time. It detects when the caller stops talking, calls the language model, streams the reply to speech, and handles interruptions, tool calls, and handoffs. It is the conductor that keeps a live conversation flowing on a tight latency budget.

What is the difference between managed and self-hosted orchestration?

Managed orchestration is a hosted platform that runs the layer for you behind a console and API. Self-hosted means you operate an open framework yourself on your own infrastructure. Managed trades a per-minute premium for speed and low ops burden. Self-hosted trades operational work for control, cost at scale, and data residency.

Should a startup use managed or self-hosted orchestration?

Most startups should start managed. Early on, speed to a live agent and learning from real calls matter far more than shaving cents per minute. Managed removes the infrastructure work so a small team can ship fast. Revisit the choice only when volume, compliance, or a control ceiling creates real pressure.

When should I move from managed to self-hosted orchestration?

Move when a specific pressure appears. Volume grows until the per-minute premium exceeds an engineer's cost. A regulation demands calls stay inside your boundary. Or you hit a customization limit the platform cannot lift. Migration should answer a concrete constraint, never a general sense that self-hosting is more mature.

Is self-hosted orchestration cheaper than managed?

Not at low volume. Managed per-minute pricing is cheaper when usage is modest, because it has no fixed floor. At high volume, self-hosting on reserved capacity usually costs less. Always compare total cost of ownership, including the fully loaded engineers to run it, not just the headline per-minute rate.

Does managed orchestration cause vendor lock-in?

It can, if you let it. Building call logic in a platform's proprietary console makes migration expensive later. You reduce the risk by keeping prompts and configs in your own repo and putting an abstraction layer between your app and the platform. Then the orchestration layer becomes a runtime you can swap.

Can I use both managed and self-hosted orchestration together?

Yes, and many mature teams do. A common hybrid keeps managed orchestration for low-stakes or fast-changing flows and self-hosts high-volume or regulated ones. Each flow lives where its constraints are cheapest. This only works if an abstraction layer keeps switching between them cheap rather than a rewrite.

How do I compare orchestration approaches fairly?

Build one test suite you own: your scenarios, caller profiles, and scoring rules. Run the identical suite against the managed setup and the self-hosted one at the same scale. Read the results on one scale. Without a neutral evaluation, you have no honest way to tell whether a switch helped, hurt, or changed nothing.

Choosing orchestration with Evalgent

The orchestration decision is only safe if you can measure both options on equal terms. Evalgent gives you that yardstick, owned by you and independent of any platform. Scenarios capture your real calls — happy paths, edge cases, interruptions, adversarial callers — as a fixed, versioned suite you keep. Profiles vary caller accent, pace, and line quality, so managed and self-hosted face the same range. Metrics score each run against pre-defined expected outcomes on one fixed definition, making results directly comparable across setups. Evaluations replay the identical suite against any orchestration layer or version at concurrency, so managed and self-hosted meet on equal terms. Reviews let your team hear the call behind any score. Because the suite is yours and runs against anyone, you can graduate from managed to self-hosted, or run a hybrid, and prove at every step that quality held. To put a neutral evaluation between you and every orchestration choice, book a demo.

The bottom line

Start managed for speed, and self-host when volume, control, or residency forces it. Keep an abstraction layer and a neutral evaluation, so the choice stays reversible and provable.