Objective
What you're building
A basic Vapi assistant configuration and one real test call — no custom voice, no conversation design, no tools yet. Today's entire job is understanding what happens between someone dialing a number and hearing a response.
The pipeline, and where latency actually comes from
Voice AI is 3 separate models chained together, and every hop costs time
Speech-to-text (STT) transcribes what the caller said, an LLM decides what to say back, text-to-speech (TTS) turns that into audio, and it plays back to the caller -- three model calls per turn, not one. A text chatbot can take 2 seconds to respond and feel fine; a voice conversation with 2 seconds of dead air after every sentence feels broken. This is why voice AI platforms like Vapi obsess over latency in a way text-based agent frameworks don't have to.
Vapi's actual job is orchestrating STT + LLM + TTS providers, not being the intelligence itself
Vapi isn't a model -- it's the layer that wires together a speech-to-text provider, an LLM (Claude, GPT, etc.), and a text-to-speech provider (like ElevenLabs, which Lesson 2 configures), handling the phone connection, turn-taking, and interruption logic between them. Understanding this division matters because when something sounds wrong, you need to know which layer to look at: garbled words point to STT, a nonsensical answer points to the LLM, a robotic voice points to TTS.
Your first assistant, and a real call
{
"name": "hello-world-receptionist",
"model": {
"provider": "anthropic",
"model": "claude-sonnet-5",
"systemPrompt": "You are a friendly test assistant. Greet the caller and ask how you can help."
},
"voice": {
"provider": "11labs",
"voiceId": "default"
},
"firstMessage": "Hi! This is a test assistant. How can I help you today?"
}
Notice the assistant config has 3 top-level pieces mirroring the pipeline: a model (the LLM and its instructions), a voice (the TTS provider), and Vapi handles the STT and phone connection underneath both. firstMessage is spoken immediately when the call connects, before the LLM has even processed anything -- this matters for latency: the caller hears something right away instead of silence while the pipeline spins up.
Make the actual phone call -- don't just read the transcript in a dashboard
It's tempting to configure the assistant and check a text transcript in Vapi's dashboard and call it "tested." Actually dialing the number and listening is a genuinely different test: you'll hear the latency, the voice quality, and any awkward pauses that a transcript hides completely. This course's ship moment (Lesson 6) requires a real recorded call for exactly this reason.
You call your test assistant and there's a noticeable 3-4 second pause after you finish speaking before it responds. The transcript in the dashboard shows the LLM's response was generated almost instantly. Where's the delay most likely coming from?
If the transcript shows the LLM responded quickly, the LLM isn't the bottleneck -- the delay is happening in one of the other two hops (STT finishing transcription, or TTS generating and starting playback of audio). This is exactly the debugging value of understanding the 3-hop pipeline from this lesson: you can localize a symptom to a specific layer instead of guessing at "voice AI is just slow."
What you're building today
vapi_hello_world.json: a basic assistant configuration, provisioned with a real phone number, actually called and listened to — with notes on where latency showed up, if any, before Lesson 2 adds a custom voice on top.