> ## Documentation Index
> Fetch the complete documentation index at: https://unmute.ai/llms.txt
> Use this file to discover all available pages before exploring further.
> ## Agent Instructions
> Unmute compiles to exactly three targets. Pipecat and LiveKit are code targets: compile writes a Python project you run. SLNG is a hosted target: compile writes a deployment body and SLNG runs the agent, so it has no `unmute dev`. Those three are the only values `provider` accepts in `targets.yaml`. Deepgram and ElevenLabs appear in these docs as model vendors, which is not the same thing as a target, and `slng` is both.
> The Go structs in `internal/spec` and `internal/ir` are the schema truth. Check a field against them, or run `unmute validate`, rather than against what you remember.
# The SLNG deployment body
> What unmute compile writes for a slng target, what SLNG runs for you, and what the package may not ask for.
SLNG hosts the agent. The compiler writes a deployment body and a runbook
instead of Python. This page describes those files and the target's settings.
Start here to create a package, select the organisation, supply credentials,
and deploy or update the agent.
SLNG creates no tool from your package. A `local:` or `webhook:` block is
refused on this target: reference a tool your organisation already has with
[`slng:`](/build/tools/hosted) instead, or compile the package to pipecat or
livekit, where your own handler or endpoint runs. The rest of this page
describes the target in full, including the tool shapes.
On this page:
* [The trade](#the-trade) - what you give up, and what you get back
* [What compiling writes](#what-compiling-writes) - the three files
* [targets.yaml](#targets-yaml) - every key this target takes, and every one it refuses
* [The pushed agent's name](#the-pushed-agents-name) - where the deployed name comes from
* [Model names](#model-names) - how a vendor and a model are joined
* [Push it](#push-it) - deployment and tool resolution
* [Hosted tool dependencies](#hosted-tool-dependencies) - only for a package that also targets code
* [The Vault](#the-vault) - where secrets live, and what a compile can see
* [What a slng package may not ask for](#what-a-slng-package-may-not-ask-for) - the refusals in full
* [If the agent answers with silence](#if-the-agent-answers-with-silence) - where to inspect a failed call
* [There is no unmute dev](#there-is-no-unmute-dev) - how to talk to a pushed agent
* [Where to go next](#where-to-go-next) - the deploy walkthrough
## The trade
You author prompts, models, tools, a greeting, and variables. SLNG runs the
pipeline and owns its capacity and turn taking. There is no generated Python
project or container to maintain.
Some package features need a runtime you control. Check the
[target limits](#what-a-slng-package-may-not-ask-for) before choosing SLNG.
## What compiling writes
To stop at the files:
```sh theme={null}
unmute compile my-agent --target slng
```
```text theme={null}
my-agent/build/slng/
├── agent.json # the agent create body
├── README.md # the runbook: what to create, what to run, what to watch
└── compile-report.json # what was compiled, and which checks were left to deployment
```
This target writes no `tools/` directory. Every tool reference in
`agent.json`, whether a curated capability, a hosted tool, or an MCP server,
resolves by name against your organisation, so there is never a body of your
own to write beside it. A `slng:` reference needs no mirror to reach even
this point: `agent.json` carries the name, and nothing else about the tool.
Validation and compilation run offline. Follow the
[deployment guide](/deploy/slng) to install `voiceai` and push the generated body.
## Targets YAML
```yaml targets.yaml theme={null}
targets:
slng:
provider: slng
deployment_region: eu-north
```
Write these inside `targets.`. The name selects this target with
`--target` and names its output folder under `build/`.
Use `slng` for this target. Omission is refused.
Accepts `us-east`, `us-west`, `br`, `eu-west`, `eu-north`, `gb`, `za`, `il`, `jp`, `sg`, `id`, `in`, `au`. Exactly one region is
required; omission, an unknown name, and multiple regions are refused.
The retired `any` value is refused. These are the same names speech and the router use.
Overrides keyed by existing model names from `agent.yaml`, using the
[model fields](/reference/agent-yaml#models). Omit to use the package's models.
An override replaces the entry, except that omitted `pace`, `endpointing_delay`,
`semantic_endpointing`, and `prompt_suffix` carry forward. An override cannot
author `pace` or a different `prompt_suffix`.
No non-empty value is accepted. Omit it: SLNG owns the runtime version.
No non-empty map is accepted. Omit it: there is no generated project whose
dependencies could be pinned.
No non-empty value is accepted. Omit it: this target emits no SDK project.
No non-empty value is accepted. Omit it: configure the carrier route in SLNG
and attach its trunk at deployment, as described in
[phone setup](/deploy/slng#receive-phone-calls).
Positive and negative values are refused. Omit it: SLNG owns capacity.
Zero also emits no setting.
## The pushed agent's name
The deployed name joins the package's [`name:`](/reference/agent-yaml#name) to
its target. A package named `my-agent` with target `slng` becomes `my-agent-slng`.
Deployment resolves an existing agent by name, or uses `--agent-id` when supplied.
Check the dry run before pushing. See [updates and renames](/deploy/slng#every-later-deploy)
for how to keep or replace an existing deployment.
## Model names
SLNG names a model with the vendor and the model joined by a slash. A package
writes them as two fields, and the slng driver joins them when it writes the
body:
```yaml agent.yaml theme={null}
models:
think:
reasoning:
provider: openai
model: gpt-5.6-terra
```
That reaches SLNG as one string. A model name that already carries a slash is
passed through whole rather than joined twice, which is how a SLNG Context
Router model such as `slng/deepgram/nova:3-en` reaches the body unchanged.
Model availability depends on your organisation and the selected region.
Follow [Choose models and their region](/deploy/slng#choose-models-and-their-region)
to check the available bindings before deployment.
## Push it
Follow [Deploy to SLNG](/deploy/slng) to create the package, select an
organisation, preview the changes, and push the agent. That guide also covers
updates, Vault credentials, and testing a complete interaction.
The generated `build/slng/README.md` lists your package's requirements. The
[deploy command reference](/reference/cli/deploy) describes every flag.
Use `unmute deploy` for checked deployment. Running `voiceai agents push`
directly bypasses Unmute's binding checks and resolved staging.
### Where your tools come from
Reference published tools by name with [`slng:`](/build/tools/hosted).
This target needs no local mirror. A package that also targets LiveKit or Pipecat
needs `unmute pull`, because those targets run a local copy of the tool.
### Names, not identifiers
`agent.json` writes each tool and MCP reference as a name, because no compiler
can invent an identifier a server assigns. SLNG's `tool_refs` entries require
`attachment_id`, `tool_id` and `version`, so a name has to become an id before
the body is accepted.
This includes a curated capability. A `builtin:` tool needs nothing *created*,
because SLNG already has it, and it still has a `tool_id` that has to be filled
in.
Resolving those names is the push step's job. It is also why
`voiceai agents create --file build/slng/agent.json` is the wrong command: that
posts the body verbatim, names included, and the API refuses it.
A `local:` or `webhook:` tool never reaches this step: the block is refused
before compiling, for the reason at the top of this page.
An MCP reference resolves the same way, and it needs one thing agent.yaml has to
say up front: which tools you want. Unmute compiles offline, so it cannot expand
"every tool on the server" into a reference list; an `mcp:` tool with no
`mcp.tools` list is refused at validate, naming the tool and pointing at
`mcp.tools`.
Once the list is there, the push looks up the server's name for its
`server_id`, then copies each named tool's schema hash out of the platform's own
stored capability snapshot. A real `unmute deploy` can refresh an unusable
snapshot once through `voiceai mcp run `, then checks it again. A dry
run never refreshes it and reports what needs attention. Discovery does not
execute business tools.
The runbook says which case your package is in.
### A push replaces
Updates replace the agent with what the package declares, including its tool
attachments. Preview the changes with `unmute deploy --dry-run`; follow
[Every later deploy](/deploy/slng#every-later-deploy) for the full sequence.
### Do not push a dashboard export back
A dashboard export is not a deployment request. Compile from the authored
package, then use `unmute deploy` to resolve and push the body.
## Hosted tool dependencies
SLNG installs the dependencies declared by the published tool. An SLNG-only
package needs no local dependency list.
LiveKit and Pipecat refuse hosted tools that declare Python dependencies.
See [Hosted tools](/build/tools/hosted) before sharing a package across targets.
## The Vault
SLNG reads secrets from its own store. With your consent, `unmute deploy` can
fill missing Vault entries through `voiceai`. The runbook lists what compiling
the package could see, grouped by source, above the push command. No secret value reaches any emitted file or
any command in the runbook.
That list is only what a compile can read offline: a tool's declared `auth:`,
a `{{"{{$NAME}}"}}` token in your text, and anything a committed mirror
recorded. A hosted tool or MCP server's own credential is not on it, because
SLNG holds that credential and a compile never asks SLNG anything.
`unmute deploy` reads the account directly and may ask to create an entry the
runbook never named.
Two kinds appear there:
* a **secret** is a credential a tool authenticates with, named in the package
as an environment variable and stored in the Vault under the same name;
* a **variable** is a `{{$NAME}}` token that SLNG substitutes into text at run
time.
A `{{$NAME}}` token passes validation on a slng target and reaches the body
unchanged. On a LiveKit or Pipecat target it is refused, and the message says
what the token is rather than telling you to declare a variable that must not
exist.
A package that needs no Vault entries is told so, rather than shown an empty
list.
## What a slng package may not ask for
Every one of these is refused at validate, by name, with what to do instead.
None is dropped quietly.
| Package feature | Why SLNG cannot take it |
| ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| tasks, task groups, handoffs | the create body carries one prompt and one greeting |
| a `turn:` section, `semantic_endpointing`, `endpointing_delay`, `pace` | SLNG owns its own turn taking |
| an `mcp:` tool with no `mcp.tools` list | unmute compiles offline and cannot expand "every tool on the server" into a reference list: name the tools you want |
| `placement: local` on any model | SLNG runs the pipeline; there is no machine of yours |
| `conversation.inactivity` | SLNG's idle nudges need three spoken texts a package does not carry |
| `conversation.max_duration`, `thinking_audio` | no field on the create body holds them |
| `interruption.minimum_words`, `interruption.ignore_phrases` | interruptions are on or off |
| a missing greeting, or a model-written one | SLNG requires a greeting and speaks the string it is given |
| `tracing:` | unmute instruments no process here, so it can install no exporter |
| a second `deployment_region` | SLNG takes exactly one |
| outbound calling, `on_voicemail` | a package declares no carrier state on SLNG; `unmute deploy` attaches an existing trunk after a push |
| a warm human transfer | SLNG's curated transfer places a single blind transfer |
An MCP tool works when its selected names and discovery snapshot pass the
platform checks. A real deploy may refresh an unusable snapshot once; a dry
run reports it without refreshing.
## If the agent answers with silence
A successful deployment does not prove that each provider answers during a call.
Follow [Verify the agent](/deploy/slng#5-verify-the-agent) to test an interaction
and [Troubleshooting](/deploy/slng#troubleshooting) to inspect a failure.
## There is no `unmute dev`
`unmute dev` runs a generated project locally; this target emits no project.
Use the SLNG dashboard to [test the deployed agent](/deploy/slng#5-verify-the-agent),
or [create a session for your own client](/deploy/slng#create-a-session-for-your-own-client).
## Where to go next
Which vendors each target accepts, and how SLNG fits in.
The walkthrough: what you need first, and every failure message.