Words do not win wars. Deeds do.

— Imperial maxim, Imperial Armour — Imperial Vehicles for Warhammer 40,000, p. 60

An agent calls to confirm an appointment. The person asks for Saturday instead of Friday. We want it to handle that change naturally, make the right update, and keep the call within budget.

That small example brings together three Cs: control, conversation, and cost. I call the tension between them the Vox trilemma.

The trilemma helps us assess design choices. It doesn’t mean we can only have two of the three. A change can improve one goal, help another, and make the third harder to achieve.

A triangle connects control, conversation, and cost around one agent design. No scores or pick-two rule.
Every design choice can pull on all three corners.

Back to the appointment

Control means checking Saturday’s availability and getting agreement before changing the appointment. It must not invent a slot or claim the booking changed when it didn’t. The scheduling integration must confirm what it actually saved.

Conversation lets the caller explain the change naturally. Long pauses while checking availability interrupt the exchange. Intent, names, and dates need to stay accurate in each supported language.

Cost includes model usage, building and maintaining the calendar integration, and testing different requests in each supported language.

More freedom can help the agent handle unusual requests. It also gives us more possible responses to evaluate. Consider three ways to design this call:

The tradeoffs come from these particular choices. They don’t follow automatically whenever we improve one C.

Every implementation has a profile

Ideally, we’d have reliable control, natural conversation, and predictable spending. For appointments, I’d focus control on booking accuracy and conversation on handling changes naturally. Fixed wording matters less. I’d accept extra checks and longer calls, giving cost less weight. The profiles illustrate priorities, not measured performance.

The dashed outline is the ideal. The filled illustrative appointment profile gives control and conversation more priority than cost. Outward means greater emphasis on each C, not higher spending.

How we’re approaching it

In Vox, this is a dance between agent design, runtime, integrations, and infrastructure.

Agent design targets conversation. The prompt and tool definitions help the agent decide when to check availability or change a booking. Tool schemas describe the information those requests need.

Stages enable progressive disclosure: detailed instructions arrive when the agent reaches the relevant task. An agent can cover appointments, billing, and support without putting every branch’s instructions into its opening prompt.

The runtime targets control and conversation. It matches the agent’s route choice to a defined stage and supplies that stage’s instructions. Earlier dialogue and the declared tool schemas remain available. For control, it enforces tool policy: which tools a stage permits, how often each may be used, and whether calls to the same tool may overlap. For conversation, voice-specific LLM drivers coordinate streaming audio, turn signals, and tool exchanges. Voice activity detection (VAD), resampling, and audio codecs sit on this latency-sensitive path. Shared resamplers and codecs adapt browser audio, telephony μ-law, and model-specific PCM rates across supported transports and speech providers.

Integrations target control through server-side validation and execution. Validation checks the request before execution. A rejected request comes back with guidance the agent can use to clarify or correct it. Execution attempts the business update. The appointment agent needs a successful execution result before confirming the change.

Infrastructure reuse targets engineering cost. Vox’s runtime is built in Rust. Reusing audio adapters avoids rebuilding conversions for each integration. Shared components have adapters for VPS services, browsers, and Cloudflare, so we can reuse their core logic across hosts. The full live-call runtime still needs a native host. Today, that portability applies to individual components.

The three Cs depend on how these parts work together.

A better prompt won’t speed up a slow calendar service. More server capacity won’t resolve unclear instructions. We have to design these parts together.

Where IVR++ fits

IVR++ is a proposed direction for routine collections calls. It favours control and cost discipline over open-ended conversation.

Against the dashed ideal, the filled illustrative IVR++ profile gives control and cost discipline more priority than conversational range. Outward means greater emphasis on each C, not higher spending.

Under control, prepared replies use fixed, reviewed wording. No new text is generated for those replies. The chosen reply still needs to fit the request and reflect confirmed integration results.

For conversation, prepared audio skips live synthesis for covered replies. Other sources of delay remain. Each supported language needs accurate understanding and reviewed wording, pronunciation, and audio. The tradeoff is less freedom to rephrase or adapt tone.

For cost, speech reuse avoids repeated synthesis. More languages and response variants add preparation and upkeep, so savings depend on reuse.

Payment reminders and callback requests often involve repeatable exchanges. That makes this a useful tradeoff for routine collections.

I’ve explored the design further in Discipline before cleverness, currently a draft.