Я однажды примерно за сутки сжег около $100 на голосовом агенте.
Не на большом запуске. Не на огромной базе. Не на хитрой рекламной кампании. Просто на небольшом пуле холодных контактов, где агент периодически попадал на voicemail, IVR, секретарей и других ботов.
В какой-то момент два не очень умных голосовых процесса могли довольно долго вежливо говорить друг другу что-то в духе:
Здравствуйте.
Здравствуйте, чем могу помочь?
Я звоню, чтобы…
Здравствуйте, чем могу помочь?
Конечно, подскажите, пожалуйста…
И пока это происходит, у тебя капает телефония, STT, TTS, модель, инфраструктура. В чате такой баг выглядел бы глупо. В звонке он еще и стоит денег.
Снаружи кажется, что задача простая. Есть Twilio, есть ElevenLabs, есть OpenClaw или любой другой агентный слой. Склеил, дал промпт, сказал “позвони человеку и поговори с ним на тему” - и вроде бы готово.
На практике голосовой агент - это не чатбот, к которому прикрутили телефон.
Это realtime-система, где у каждой лишней секунды, каждого лишнего tool call и каждого кривого перехода есть цена.
TL;DR
Если коротко:
В чате модель может думать. В звонке пауза в 2-3 секунды уже звучит как поломка.
Большой промпт и много инструментов в голосе часто не делают агента умнее, а размазывают разговор.
Рабочий голосовой агент - это не один “супер-промпт”, а граф стадий: что спросить, куда перейти, когда закончить.
Cold outbound намного сложнее inbound-квалификации или напоминаний, потому что мир снаружи не подчиняется вашему flow.
Retell/ElevenLabs-подобные платформы ценны не только тем, что “умеют звонить”, а тем, что закрывают скучную realtime-механику: interruptions, streaming STT/TTS, лимиты, тесты, post-call extraction.
Главный вопрос не “как позвонить”, а “как не дать агенту продолжать звонить, когда он уже заблудился”.
Наивная архитектура, которая выглядит слишком просто
Первая версия в голове обычно выглядит так:
Twilio call
-> streaming speech-to-text
-> LLM / OpenClaw agent
-> tools: CRM, calendar, email, database
-> text-to-speech
-> Twilio callВыглядит логично.
Пользователь что-то сказал. Мы распознали речь. Отдали текст агенту. Агент подумал, вызвал инструменты, сформулировал ответ. Мы озвучили ответ. Все счастливы.
В текстовом чате эта схема в целом терпима. Хочешь качества - берешь что-нибудь тяжелое типа Opus, даешь длинный системный промпт, пачку тулов, разрешаешь модели несколько секунд или даже минут собирать хороший ответ. Пользователь подождет.
В звонке эта логика ломается почти сразу.
Latency в чате и latency в звонке - это разные сущности
В звонке пауза в 2-3 секунды уже ощущается как странность.
Если агент в этот момент:
дергает CRM;
проверяет календарь;
зовет OpenClaw;
ждет модель;
получает tool result;
генерирует ответ;
отправляет его в TTS;
начинает стримить аудио обратно;
то разговор начинает звучать не как “умный AI”, а как зависший оператор.
При этом человек на той стороне не обязан сидеть молча. Он перебивает, уточняет, говорит “алло?”, начинает повторять вопрос, комментирует паузу. Все это попадает в streaming-транскрипт, модель пытается ответить уже на новые куски, контекст засоряется, и через несколько реплик у тебя не диалог, а суп.
В чате можно попросить пользователя подождать. В звонке ожидание само становится частью разговора.
И это важное отличие.
Быстрая модель лучше медленной умной? Не совсем
На одном из проектов у нас работала Gemini 2.5 Flash.
Это была нормальная для realtime модель: она могла начать отвечать быстро, могла сказать “сейчас проверю календарь”, пока дергает инструмент, могла не оставлять человека в полной тишине.
Но у нее была другая проблема. Если дать большой развесистый промпт, длинный flow и пачку инструкций на весь звонок, она быстро терялась. Буквально через несколько реплик начинал расползаться смысл:
зачем мы вообще звоним;
что уже спросили;
что еще надо спросить;
какой сейчас этап;
можно ли уже завершать;
какой инструмент дергать дальше.
То есть “быстрая модель” сама по себе не решает задачу. Она просто переносит проблему из latency в управляемость.
В чате можно жить с большим промптом. В голосе большой промпт часто превращается в мешок инструкций, из которого модель на пятой реплике достает не ту бумажку.
Рабочий голосовой агент - это граф, а не простыня
Хороший голосовой агент обычно выглядит не как один большой промпт “будь полезным и поговори с человеком”.
Он больше похож на управляемый граф разговора.
В Retell или ElevenLabs это видно прямо в интерфейсе. Например, в шаблоне patient screening нет магической простыни “поговори с пациентом”. Там есть узлы:
greeting;
identity check;
consent;
screening questions;
closing;
transfer call;
end call;
technical issue fallback.
У каждого узла короткая инструкция. У переходов есть условия. Отдельно настраиваются interruption sensitivity, лимит длительности звонка, post-call extraction, тесты.
Примерно так:
[Greeting]
if confirmed identity
v
[Identity check]
if data matches
v
[Consent]
if agreed
v
[Question 1] -> [Question 2] -> [Question 3]
v
[Closing]
v
[End call]
-----------
Fallbacks:
wrong person
-> apologize
-> end call
transfer needed
-> transfer call technical issue
-> say we'll call back
-> end callИ вот это уже ближе к реальности.
Не:
“Ты умный агент, помоги человеку.”
А:
сейчас поздоровайся;
проверь, с тем ли человеком говоришь;
если не тот человек - извинись и заверши;
если тот - получи consent;
задай ровно этот вопрос;
после ответа перейди к следующему;
если сломались - скажи, что перезвоним;
после звонка вытащи вот эти поля.
Это звучит скучно. Но в голосовых агентах скучная инженерия обычно и спасает.
Где у нас это сработало
Первый успешный кейс был с inbound-квалификацией лидов.
Компания продавала курсы программирования на немецком рынке, в том числе людям, которым обучение могло оплачиваться через биржу труда. Маркетинг экспериментировал с аудиториями, и в заявки часто прилетали люди, которые вообще не понимали, куда они оставили форму.
Сейлзы жаловались, что тратят время на мусорные лиды. Поэтому мы посадили голосового агента прозванивать входящие заявки и выяснять базовые вещи:
понял ли человек оффер;
откуда узнал о программе;
что его интересует;
какая цель;
может ли заниматься на английском;
какой бюджет;
какие сроки.
На выходе агент заполнял короткий опросник, считался скор, теплые лиды уходили живым сейлзам, мусор отсеивался. Живые сейлзы периодически проверяли качество фильтрации.
На команду из 4 сейлзов это освободило примерно 40 часов в неделю.
Ключевой момент: агент не “продавал все всем”. Он делал узкую работу в понятном процессе.
Второй успешный кейс был с вебинарами.
Люди записывались через форму, но доходило около 10%. Мы поставили агента, который звонил за 30, 10 или 5 минут до старта:
“Привет, у нас скоро начинается вебинар, приходите.”
Звучит тупо просто. Но люди реально отвечали “да, спасибо, сейчас зайду” и заходили. Доходимость выросла примерно до 30%, местами около x2.5.
Если человек спрашивал “а кто вы и что там будет?”, агент мог человеческим голосом нормально объяснить. Не идеально продавать, не вести сложную дискуссию, а просто закрыть пару типовых вопросов.
Почему это работало? Потому что задача была узкая:
понятная цель;
короткий разговор;
мало ветвлений;
простые исходы;
понятный критерий успеха.
Где у нас это не сработало
Холодный outbound нормально не взлетел.
Потому что холодный звонок - это открытый мир.
Там voicemail, IVR с клавиатурой, секретарь, гейткипер, другой бот, “перезвоните позже”, “отправьте на почту”, “я не принимаю такие решения”, “а кто вам дал мой номер”.
И на каждый такой кейс нужен не абзац в промпте, а отдельное поведение:
что считать voicemail;
когда класть трубку;
что делать с IVR;
как не застрять на секретаре;
когда просить правильный контакт;
когда предложить перезвонить;
когда отправлять follow-up;
когда перестать тратить деньги.
Плохая новость: все эти ветки легко нарисовать в голове.
Еще более плохая новость: в реальном звонке они будут смешиваться, ломаться, перебиваться и попадать в кривые транскрипты.
Почему готовые voice-agent платформы не просто “обертка над Twilio”
Можно ли собрать все самому?
Можно.
Но “самому” довольно быстро превращается не в один Twilio webhook, а в маленькую realtime-платформу.
Нужно думать про:
streaming STT;
streaming TTS;
interruption handling;
state machine;
tool orchestration;
latency budget;
post-call analysis;
лимиты длительности;
защиту от бесконечных звонков;
fallback-сценарии;
regression tests для промптов и тулов.
И вот поэтому Retell/ElevenLabs-подобные платформы привлекательны не только тем, что “умеют звонить”. Звонить как раз можно собрать.
Они привлекательны тем, что продуктово закрывают скучные куски, которые в проде оказываются не скучными, а критичными.
Например, interruption handling.
Если человек перебил агента, агент должен не просто продолжать договаривать свой старый ответ. Он должен понять, что его перебили, остановить текущий TTS, принять новый input и решить, остался ли он в той же стадии или надо перейти в другую.
Например, тесты.
Ты постоянно меняешь промпты, переходы, инструменты, формулировки. И очень легко сделать так, что один сценарий стал лучше, а другой, который раньше работал, внезапно отвалился.
Поэтому возможность сохранить диалог как тест - ожидали такой ответ, такой tool call, такой outcome - это не приятная мелочь. Это способ не развалить прод очередной правкой промпта.
Таблица граблей
Проблема | В чате | В звонке |
|---|---|---|
Модель думает 5 секунд | Пользователь подождет | Пользователь говорит “алло?” |
Большой промпт | Дороже и медленнее | Агент теряет цель разговора |
Много tool calls | Терпимо | Длинные паузы и странный UX |
Кривой input | Можно перечитать | Streaming transcript уже уехал в контекст |
Бесконечный цикл | Плохой UX | Счет за телефонию и модели |
Нет stop condition | Чат завис | Агент продолжает звонить |
Нет regression tests | Сломали один сценарий | Сломали звонки живым людям |
Что я бы проверял перед запуском
Если бы я сейчас запускал голосового агента, я бы начинал не с выбора модели и не со связки Twilio + ElevenLabs.
Я бы сначала ответил на такие вопросы:
Из каких стадий состоит звонок?
Какая цель у каждой стадии?
Какие данные нужны модели именно на этой стадии?
Какие инструменты доступны именно на этой стадии?
Какие переходы разрешены?
Какие переходы запрещены?
Что считается успешным исходом?
Что считается тупиком?
Когда агент обязан завершить звонок?
Что делать с voicemail?
Что делать с IVR?
Что делать, если человека перебили или он перебил агента?
Какой latency budget допустим?
Какие диалоги сохраняем как regression tests?
Сколько денег можно сжечь до auto-stop?
Последний пункт не шутка.
Если агент может попасть в цикл, у него должен быть не только промпт “не попадай в цикл”, а технический лимит, который его остановит.
Вывод
Голосовые агенты уже могут звонить.
Это не самая интересная часть.
Интересная часть - сделать так, чтобы они:
отвечали быстро;
не теряли цель;
не тащили весь playbook в каждую реплику;
нормально переживали перебивания;
не путали voicemail с человеком;
не болтали с другим ботом полтора часа;
не ломались от каждой правки промпта;
и умели вовремя остановиться.
Поэтому начинать надо не с вопроса:
«Как склеить Twilio, ElevenLabs и OpenClaw?»
Начинать надо с другого:
«Из каких состояний состоит звонок, кто управляет переходами, и сколько стоит ошибка в каждом состоянии?»
Потому что позвонить агент уже может.
А вот вовремя заткнуться — это уже engineering.