> ## 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. # Orchestration > Three ways to split one agent into parts, and where each is taught. Orchestration is how you split one agent into parts. There are three shapes, and the difference that matters is whether control comes back. On this page: * [The three shapes](#the-three-shapes) - task, task group, handoff * [What each shape does to the call](#what-each-shape-does-to-the-call) - one diagram each * [Read one example against the other](#read-one-example-against-the-other) - the same salon, built two ways * [Read them in order, then choose](#read-them-in-order-then-choose) - where to go New here? Read [How a package fits together](/build/how-a-package-fits-together) first. It is one page, it answers "I want two agents, each with tasks, where do I start?", and everything below assumes it. ## The three shapes | Shape | What it is | Where it is taught | | -------------- | ----------------------------------------------------------------- | ----------------------------------------------- | | **Task** | one step the agent runs, which saves typed values and returns | [Tasks](/build/orchestration/tasks) | | **Task group** | several tasks in a fixed order, sharing what they learn | [Task groups](/build/orchestration/task-groups) | | **Handoff** | one agent gives the caller to another, and does not get them back | [Handoffs](/build/orchestration/handoffs) | The difference that matters most is whether control comes back. A task returns. A handoff does not. These shapes need a code target, Pipecat or LiveKit. SLNG compiles one agent with one prompt, so it refuses tasks, task groups and handoffs today. `unmute validate` says so and names the way out: fold the step into the agent's instructions, or compile to LiveKit or Pipecat. Tasks on SLNG are coming. None of these is how you reach a person: that is an [escalation](/transfers/overview), and what it can do depends on the phone route. Whichever shape you reach for, you write it the same way: as a name in one of the agent's five lists. [The five things an agent can do](/build/how-a-package-fits-together#the-five-things-an-agent-can-do) shows the lists and which ones come back. ## What each shape does to the call Each picture answers two questions: who is talking to the caller, and does control come back to the agent that started. ### A tool The agent stays in charge. It calls the tool, reads the result, and keeps talking. ```mermaid theme={null} sequenceDiagram participant Caller participant Owner participant Tool Caller->>Owner: asks a question Owner->>Tool: calls the tool Tool-->>Owner: result Owner->>Caller: answers, and keeps the call ``` ### A task The owner enters the task. The task talks to the caller with its own prompt and tools. When the model calls `finish`, the values in `assign:` are saved and the owner continues, reading them through its own placeholders. ```mermaid theme={null} sequenceDiagram participant Caller participant Owner participant Task Caller->>Owner: asks for something the task covers Owner->>Task: enters the task Task->>Caller: talks with its own prompt and tools Caller->>Task: answers Note over Task: the model calls finish Task-->>Owner: status, values saved Owner->>Caller: continues, reading the saved values ``` ### A task with `finish:` The same, except the tool decides. When the tool's result matches `success:`, the task saves and ends by itself. The model makes no `finish` call, and the owner speaks next. ```mermaid theme={null} sequenceDiagram participant Caller participant Owner participant Task participant Tool Owner->>Task: enters the task Task->>Caller: asks what it needs Caller->>Task: answers Task->>Tool: runs the tool Tool-->>Task: result matches success Note over Task: the task saves and ends, no finish call Task-->>Owner: status Owner->>Caller: acknowledges, and keeps the call ``` ### A handoff The first agent hands the caller to a second agent. The second agent owns the rest of the call. Nothing comes back. ```mermaid theme={null} sequenceDiagram participant Caller participant Owner participant AgentB as Agent B Caller->>Owner: asks for something Agent B owns Owner->>AgentB: hands the caller over AgentB->>Caller: takes the rest of the call Note over Owner: nothing comes back ``` ## Read one example against the other Two shipped packages are the same salon, built two ways. [`examples/salon-concierge-single-prompt`](https://github.com/slng-ai/unmute/tree/main/examples/salon-concierge-single-prompt) is one agent with one prompt: no tasks, no handoffs, no variables. [`examples/salon-concierge`](https://github.com/slng-ai/unmute/tree/main/examples/salon-concierge) is the structured one, with tasks, a task group, handoffs and saved values. Read one against the other to see what the structure bought. ## Read them in order, then choose Start with the first page: it adds one task to the package you already have, one key at a time. The next three pages are one shape each, with the example package that uses it. The last page is the one to come back to when you are deciding: it pairs the symptom you have with the shape that fixes it, and says what each shape costs. From no task to a task that says what success looks like, on your own package. Run a step, keep the answer. A fixed order, and shared context. Two agents, two sets of rules. Which split to reach for, and what it costs.