|
| 1 | +--- |
| 2 | +title: Design your GPT-Live assistant |
| 3 | +subtitle: Plan the conversation and choose how your assistant speaks |
| 4 | +description: Design GPT-Live conversations with speaker and reasoner roles, outcome-based delegation, useful overlap during tools, flexible pacing, and personality packs. |
| 5 | +slug: gpt-live/design |
| 6 | +--- |
| 7 | + |
| 8 | +With GPT-Live, the conversation can continue while work happens in the background. A caller can add a preference during a lookup, ask a question halfway through scheduling, or ask the assistant to slow down. |
| 9 | + |
| 10 | +The design task is to make those moments feel connected. Decide what the assistant is trying to accomplish, how it should guide the caller, and which decisions need help from your services. |
| 11 | + |
| 12 | +This guide uses scheduling as an example. The same approach applies to support, intake, and other conversations that combine questions with actions. |
| 13 | + |
| 14 | +**Jump to:** [Architecture](#speaker-and-reasoner-roles) · [Squads](#start-with-one-assistant) · [Conversation flow](#questions-and-changes-of-topic) · [Voice design](#speaking-style) · [Testing](#testing-conversations) |
| 15 | + |
| 16 | +## Speaker and reasoner roles |
| 17 | + |
| 18 | +The **speaker** carries the spoken interaction: listening, responding, asking questions, and deciding when to delegate. The **reasoner** takes a delegated task, follows its instructions, and calls tools. A tool connects the assistant to information or actions in your service. |
| 19 | + |
| 20 | +Both models belong to the same assistant. The caller stays in one conversation while the reasoner works behind it. |
| 21 | + |
| 22 | +| Give the speaker | Give the reasoner | |
| 23 | +| --- | --- | |
| 24 | +| The assistant's role and the caller's goal | The procedure for completing each task | |
| 25 | +| Tone, language, and pacing | Required information and confirmation rules | |
| 26 | +| When to clarify or delegate | Which tools to use and in what order | |
| 27 | +| How to explain results to the caller | How to interpret tool results and failures | |
| 28 | + |
| 29 | +For example, the speaker needs to know that it can help find an appointment. The reasoner needs to know which service returns availability, what information that service requires, and when booking is allowed. |
| 30 | + |
| 31 | +This separation lets you keep the speaker's instructions focused. Put detailed business procedures in the reasoner prompt. Your services remain responsible for enforcing permissions and validating actions. |
| 32 | + |
| 33 | +### When to delegate |
| 34 | + |
| 35 | +Give the speaker a clear reason to ask for help: “Delegate requests to find an appointment that fits the caller's preferences.” Give the reasoner the steps needed to produce that result. |
| 36 | + |
| 37 | +| Layer | Example instruction | |
| 38 | +| --- | --- | |
| 39 | +| Speaker | “Help the caller find a suitable appointment. Delegate availability checks and booking requests.” | |
| 40 | +| Reasoner | “Confirm the date and time zone. Look up available slots. Book only after the caller confirms a specific slot.” | |
| 41 | +| Service | Validate the requested slot and create the booking only when the request meets your requirements. | |
| 42 | + |
| 43 | +Keep the conditions for delegation concrete. A greeting or a request to repeat an already confirmed time may stay with the speaker. A fresh lookup, changed booking request, or end-call request needs the reasoner and its tools. |
| 44 | + |
| 45 | +The reasoner's result gives the speaker information for its next response. The speaker can explain that information in the context of what the caller just said. See [Configure GPT-Live](/gpt-live/configuration#create-an-assistant) for an assistant with both prompts and a lookup tool. |
| 46 | + |
| 47 | +## Start with one assistant |
| 48 | + |
| 49 | +Early testing suggests GPT-Live handles many of the needs that previously led builders to squads out of the box. The speaker maintains the conversation while the reasoner handles detailed instructions and task sequencing. You may be able to cover the full use case with one assistant. |
| 50 | + |
| 51 | +Suppose your scheduling squad has separate assistants for intake, availability, and booking. Start by carrying those responsibilities into one GPT-Live assistant: |
| 52 | + |
| 53 | +```mermaid |
| 54 | +flowchart TD |
| 55 | + A[One scheduling conversation] |
| 56 | + A --> B[Speaker guides the caller] |
| 57 | + B --> C[Reasoner manages the task] |
| 58 | + C --> D[Collect required details] |
| 59 | + D --> E[Look up availability] |
| 60 | + E --> F[Book after confirmation] |
| 61 | +``` |
| 62 | + |
| 63 | +This diagram shows responsibilities, not a fixed script for every call. The caller may supply several details at once or ask a question between stages. |
| 64 | + |
| 65 | +Preserve the outcomes and business rules you need. Test whether the new architecture still needs the divisions you created for the old one. Pay attention to missed steps and recovery from errors before consolidating a production flow. |
| 66 | + |
| 67 | +Existing squad configurations and assistant handoffs are [currently unsupported](/gpt-live/limitations#can-i-use-an-existing-squad). The early finding is that some use cases need fewer assistants, not that every squad can be converted automatically. |
| 68 | + |
| 69 | +## Questions and changes of topic |
| 70 | + |
| 71 | +Give the conversation a destination and a few meaningful stages: understand the request, find suitable options, confirm the choice, and explain the result. The caller doesn't need to answer questions in the order you wrote them. |
| 72 | + |
| 73 | +Consider this opening: |
| 74 | + |
| 75 | +> **Caller:** I need something Friday afternoon. I've been there before. |
| 76 | +
|
| 77 | +The caller has already supplied a day, a preference, and a useful detail. Design the assistant to acknowledge those details and ask for the next missing piece, such as the exact date or time zone. Repeating questions the caller has answered makes even responsive speech feel mechanical. |
| 78 | + |
| 79 | +A detour can help the caller make the next decision: |
| 80 | + |
| 81 | +> **Caller:** Before we pick a time, how long does the appointment take? |
| 82 | +> |
| 83 | +> **Assistant:** Let me check that for you. Then we can find a time that works. |
| 84 | +
|
| 85 | +If the duration is already available in trusted context, the speaker can explain it. If it needs a fresh lookup, delegate that question. Then return to scheduling with the caller's earlier preferences intact. |
| 86 | + |
| 87 | +A useful speaker instruction is: |
| 88 | + |
| 89 | +```text title="Keep the conversation connected" |
| 90 | +Use details the caller has already provided. Ask one question for the |
| 91 | +next missing piece. If the caller asks a related question, address it |
| 92 | +and then return to the unfinished task. Delegate questions that need |
| 93 | +new information from our services. |
| 94 | +``` |
| 95 | + |
| 96 | +## Talking while tools run |
| 97 | + |
| 98 | +A lookup doesn't always need to bring the conversation to a stop. While it runs, the speaker can collect information that doesn't depend on the result. |
| 99 | + |
| 100 | +For example, if your service can retrieve a whole day's availability, the speaker can ask about morning or afternoon while that request is running. If the lookup requires that preference as an input, ask first. |
| 101 | + |
| 102 | +```mermaid |
| 103 | +sequenceDiagram |
| 104 | + participant C as Caller |
| 105 | + participant S as Speaker |
| 106 | + participant R as Reasoner and tools |
| 107 | + C->>S: What is available on Friday? |
| 108 | + S->>R: Look up Friday availability |
| 109 | + S->>C: Morning or afternoon? |
| 110 | + C->>S: Afternoon, ideally after two |
| 111 | + R-->>S: Available times |
| 112 | + S->>C: Explain matching options |
| 113 | +``` |
| 114 | + |
| 115 | +This illustrates a conversation to design and test, not a guarantee of exact event timing. Your prompts and tool requirements determine which work can overlap. |
| 116 | + |
| 117 | +Keep updates proportionate. One short “I'm checking” can be enough. A forced acknowledgment before every tool call, repeated status updates, or unrelated small talk can make the wait feel longer. |
| 118 | + |
| 119 | +### Confirming results |
| 120 | + |
| 121 | +The assistant can acknowledge the request before the work finishes. Its confirmation should follow the result: |
| 122 | + |
| 123 | +| Moment | What the caller can hear | |
| 124 | +| --- | --- | |
| 125 | +| The request is understood | “I'll check Friday afternoon.” | |
| 126 | +| The lookup finishes | “There are openings at two and four.” | |
| 127 | +| A booking tool confirms success | “Your two o'clock appointment is booked.” | |
| 128 | + |
| 129 | +The [example assistant](/gpt-live/configuration#create-an-assistant) only looks up availability. Add a booking tool before teaching it to offer the final step. |
| 130 | + |
| 131 | +### When callers change the request |
| 132 | + |
| 133 | +If the caller says “Actually, Thursday” during the lookup, the speaker should acknowledge the new request. Your application should match each result to the request it answers so Friday's result doesn't drive Thursday's booking. |
| 134 | + |
| 135 | +Interrupting speech doesn't cancel an action already sent to a service. Keep changes and cancellations explicit in your application. The [limitations FAQ](/gpt-live/limitations#does-an-interruption-cancel-a-tool-call) explains this boundary. |
| 136 | + |
| 137 | +## Speaking style |
| 138 | + |
| 139 | +Choose both a voice and a way of speaking. The voice establishes a starting sound. Speaker instructions shape pacing, warmth, emphasis, and how much the assistant says at once. |
| 140 | + |
| 141 | +Write a short voice brief alongside the task brief. Describe behavior someone could hear and evaluate: |
| 142 | + |
| 143 | +```text title="Example voice brief" |
| 144 | +Sound warm and conversational. Keep routine answers brief. |
| 145 | +Move briskly through familiar information, but slow down when reading |
| 146 | +appointment dates and times. Give one instruction at a time when |
| 147 | +explaining a process. Follow requests to speed up, slow down, or |
| 148 | +explain more. Leave room for the caller to respond. |
| 149 | +``` |
| 150 | + |
| 151 | +These are prompted behaviors, not precise speed or pause controls. Test the spoken result. [Programmatic speech control](/gpt-live/limitations#can-i-inject-commentary-or-control-speech-during-a-call) is currently unsupported in Vapi's GPT-Live integration. |
| 152 | + |
| 153 | +### Pacing |
| 154 | + |
| 155 | +A consistent personality doesn't require a constant pace. The same assistant can move quickly through familiar information and become more measured when a caller needs help. |
| 156 | + |
| 157 | +| Moment | Delivery to try | |
| 158 | +| --- | --- | |
| 159 | +| Caller knows what they want | Short questions and concise answers | |
| 160 | +| Caller is choosing between options | A few options at a time, with room to respond | |
| 161 | +| Assistant reads a date or unfamiliar name | Slower delivery and clear articulation | |
| 162 | +| Caller asks “Can you walk me through it?” | One step at a time | |
| 163 | +| Caller says “Just the short version” | A brief summary with an offer to explain more | |
| 164 | + |
| 165 | +Treat those requests as part of the conversation design. Test “slow down,” “a little faster,” and “say that another way” alongside your business scenarios. |
| 166 | + |
| 167 | +### Personality packs |
| 168 | + |
| 169 | +Vapi's personality packs add speaking-style guidance to your speaker prompt: |
| 170 | + |
| 171 | +| Pack | What its guidance encourages | |
| 172 | +| --- | --- | |
| 173 | +| **Active listening** (`eager-listener`) | Brief acknowledgments at natural openings, with room for the caller to continue | |
| 174 | +| **Humming** (`idle-hummer`) | Soft humming or wordless sounds during quiet moments while waiting for tools | |
| 175 | +| **Bouncy** (`bouncy`) | More expressive pitch, emphasis, and rhythm, adapting to the caller's mood | |
| 176 | +| **Unhurried** (`unhurried`) | A slower pace, clear articulation, and space between ideas | |
| 177 | + |
| 178 | +Choose a pack because it suits the experience. Humming might fit an informal concierge and feel out of place during a serious support issue. Expressiveness and speed are separate choices: an animated assistant can still speak slowly and clearly. |
| 179 | + |
| 180 | +Start with one pack, listen, and adjust the speaker prompt. Packs add guidance. They don't guarantee identical delivery on every call. See [personality configuration](/gpt-live/configuration#personality-and-language) and [voice previews](/gpt-live/configuration#voices). |
| 181 | + |
| 182 | +## Testing conversations |
| 183 | + |
| 184 | +Review a short set of conversations before expanding the prompt. Include a direct request, a detour, information supplied out of order, a slow lookup, and a request to change speaking style. |
| 185 | + |
| 186 | +Ask whether the assistant used what the caller had already said, delegated at the right moment, and returned naturally to unfinished work. Listen for whether its pace helps the caller make progress. |
| 187 | + |
| 188 | +Keep a few representative calls as a baseline. Repeat them when either prompt changes. Use [post-call analysis](/gpt-live/configuration#review-and-monitor-calls) to track outcomes, while reviewing audio for timing and delivery. Check [testing limitations](/gpt-live/limitations#can-i-run-simulations-and-evals) before choosing an automated test method. |
| 189 | + |
| 190 | +For additional model-level examples, see OpenAI's [GPT-Live prompting guide](https://developers.openai.com/api/docs/guides/live-prompting). Use Vapi's fields when applying that guidance to your assistant. |
0 commit comments