Voice agents are harder than text agents in ways that are not obvious until you build one. A text interface tolerates a two second pause. A phone call does not, and a human hearing silence assumes the line has dropped. Vapi's documentation is unusually good on exactly this problem, treating latency as the central engineering constraint rather than an optimisation, and that focus makes it worth reading even for people building on other platforms.
The latency budget material is the standout. Speech recognition, model inference and speech synthesis each consume time, and the documentation breaks down where the milliseconds go and what you can do about each stage. Understanding that a conversational response needs to begin within a few hundred milliseconds, and that this constrains every other choice you make, is the insight that explains why so many voice agents feel subtly wrong. I have not seen it explained more clearly anywhere.
Interruption handling gets the attention it deserves. Real conversations involve people talking over each other, changing their mind mid sentence and giving short acknowledgements while the other party continues. Handling that properly is genuinely difficult and the documentation covers the mechanics of detection and turn taking rather than pretending it is solved. Anyone who has been unable to interrupt an automated system knows why this matters.
Provider flexibility across the stack is a good design decision and well documented. You choose your speech recognition, your model and your voice synthesis independently, which lets you trade cost against quality at each layer. The documentation explains the options without making the choice for you, which is honest and also means you need to do your own testing to find a combination that works. Telephony integration is treated as a real subject rather than an afterthought.
Phone numbers, call routing, transfers and the specifics of working with telephony providers are all covered, and that unglamorous material is exactly what someone deploying an actual phone system needs. Cost is the thing I would push on hardest. Per minute pricing across multiple providers accumulates quickly, and a call volume that seems modest produces a bill that surprises people who tested with a handful of calls. The documentation states the rates without helping you model a realistic monthly total across the stack, and anyone planning a deployment should build that spreadsheet before committing.
Debugging a bad call is genuinely difficult and the guidance is limited. When a conversation goes wrong, working out whether the transcription misheard, the model responded poorly, the synthesis mangled a word or the timing broke requires inspecting several layers, and the tooling for that is thinner than the problem warrants. More material on diagnosing failures would improve the documentation considerably. The audience is developers only, which is a reasonable scope decision.
There is no path here for someone who cannot code, and the material does not pretend otherwise. Three point seven. Technically honest documentation about a hard problem, with latency and interruption coverage that genuinely teaches you something. Marked down for pricing that needs more modelling help and for leaving the debugging story underdeveloped.