Unmute makes voice-agent behavior portable by putting steps, tools, data flow, policies, and failure handling into a compiled package.
2
Splitting a salon agent into focused steps used more total prompt text but reduced per-turn token usage, turns, and latency compared with one large prompt.
3
Typed variables and declared transitions can make invalid actions impossible, such as booking before a customer phone number has been confirmed.
Summary
Luke and Nico introduce Unmute, an open declarative standard for voice agents from SLNG.ai. They argue that current agents are tied to platforms and that their behavior is scattered across prompts, framework code, integrations, and runtime decisions. Unmute moves execution into a compiled package that declares steps, tools, data flow, transitions, variable rules, and failure handling. The LLM remains an optional resource rather than the call's decision-making spine. Nico compares two salon agents. A single prompt exposes the model to ten tools and every rule on every turn. A split design gives a concierge and a complaint specialist only the context they need. The split design uses more text when all prompts are combined, but less text reaches the model on each turn. The example shows more than double token usage for the single prompt, along with more turns and higher latency. Unmute also pre-fetches data, injects typed variables, and rejects invalid references at build time. The release includes an MIT-licensed standard, an open-source CLI, and targets for Pipecat Cloud, LiveKit Cloud, and SLNG.ai.
Voice agents need a portable definition of behavior
Luke says voice-agent platforms each define agents differently, so work built on ElevenLabs, Vapi, Retell, Bolna, Pipecat, or LiveKit stays tied to that stack. Behavior is spread across prompts, framework code, provider integrations, and runtime decisions. Changing the stack means rebuilding the agent, while changing a model can change its behavior. Unmute puts behavior, resources, integrations, and compliance boundaries into one package that can be recompiled for different infrastructure.
Luke rejects the idea that a voice agent is a sequential turn-taking pipeline. Listening, reasoning, retrieval, speaking, and interruption can happen at the same time. The agent should choose the resource needed at a particular point, which might be a frontier model, cached audio, a compliance-approved disclosure, or compute in a particular region. This lets infrastructure change without rewriting the agent around a fixed model sequence.
Declared execution removes call control from the LLM
Unmute declares and enforces tool calls, data flow, step transitions, and failure handling in the compiled project. The LLM becomes an optional resource that has to earn its place. Luke says the same package can compile to Pipecat Cloud, LiveKit Cloud, or SLNG.ai, with cascade or speech-to-speech architectures and a selected region. The package holds the rules while the runtime and cloud infrastructure can change.
Luke describes a middle ground between rigid IVR and a long prompt followed by hope. Unmute treats determinism as a setting for each turn. A regulated disclosure can be locked down, while an objection can remain open-ended and generative in the same call. This makes non-determinism one resource available to the system instead of the foundation for every decision.
Large prompts fail because every turn carries every rule
Nico says teams commonly build one prompt and keep adding new requirements to its bottom. The model reads every rule at every turn, can go off topic, and may follow some rules while ignoring others. When a call fails, the team cannot tell which part of the prompt caused it. His approach is to split the work into steps and give each step only the context it needs, reducing what the model must decide at one time.
The split salon design gives each step a smaller context
Nico compares two versions of the same salon agent. The single-prompt version has ten tools and includes rules for identifying callers, booking, complaints, and salon questions. The model reads all ten tool descriptions on every turn. The split version has a concierge with one salon-information tool and a separate complaint specialist. A verification step confirms the customer and passes the phone number to booking. The booking step is not given to the model until that number exists.
Per-turn context matters more than total prompt text
The single-prompt salon agent uses more than double the tokens of the split version in the Langfuse comparison, even though the number of steps is roughly the same. The split version also uses fewer turns and lower latency. When the four split prompts are combined, they contain nearly twice as much text as the single prompt. Nico explains that the model receives only the active step on each turn, so a caller asking opening hours does not also pay for the phone or refund policy.
Prefetching and typed variables prevent avoidable model work
Nico shows how data can be collected before the greeting. The system can read the clock, use the number supplied by the carrier, and look up the matching record before the agent says hello. He also declares variables once with a type and a default, then specifies where each value may appear. If a phone number is allowed in only one prompt, putting it in the greeting creates a build error. Tools receive the injected value directly instead of asking the model to reproduce it.
The package is compiled and released under an open license
Nico demonstrates a coding agent that builds an Unmute agent from a paragraph describing the problem. The compile command turns the package into running code, checks agent.yaml, wires up tools, and validates the project before execution. The release includes the Unmute standard under an MIT license, an open-source CLI, and infrastructure targets for Pipecat Cloud, LiveKit Cloud, and SLNG.ai. The intended result is version-controlled agent IP that survives infrastructure changes.
"What I learned is that if you want agents that work at scale, you go towards determinism, not by taking decisions away from the model, but by giving it less to decide at a time."04:42
Who should watch
You are building a voice agent on a platform and want its behavior to remain portable when the runtime, model, or cloud changes.
Your current agent has one large prompt with many tools and rules, and you need to reduce per-turn context and make failures easier to locate.
You work with regulated voice calls and need declared policies, typed data flow, and build-time checks instead of relying only on model instructions.
