ИИ-коуч продаж на LiveKit – tool-calling и анализ экрана

Коротко

Коуч продаж – это программный участник, который подключается к живому звонку с клиентом, слушает обе стороны, видит экран, который показывает менеджер, и подсказывает ему лично – но никогда не клиенту. В этом уроке мы строим такого коуча на LiveKit, добавляя три способности к молчаливому ноутейкеру из прошлого урока: tool-calling, чтобы агент мог по ходу звонка достать баттлкарту или карточку из CRM; анализ экрана, чтобы он видел презентацию или демо; и приватный канал, чтобы совет дошёл только до менеджера. Главное правило, которое делает всё это безопасным: коуч не говорит ни с кем в комнате – он шлёт текст по адресному вызову (RPC) на один-единственный identity, на менеджера, и клиент не слышит и не видит ни слова. К концу урока вы будете понимать архитектуру, бюджет задержки, структуру издержек и правила согласия достаточно, чтобы заложить эту фичу в продукт для видеосвязи или продаж.

Зачем это нужно

Коучинг продаж в реальном времени в 2026 году перестал быть идеей и стал отдельной категорией продуктов: инструменты теперь подсказывают ответы на возражения и конкурентные баттлкарты достаточно быстро, чтобы менеджер реально читал их прямо во время звонка. Если вы делаете софт для видеоконференций, для отдела продаж или для телемедицины, ваши клиенты начинают это просить, и вопрос «купить или построить» ложится на ваш стол. Этот урок даёт продакту понятную модель того, чем на самом деле является эта фича – три способности и одно правило приватности, – а инженеру даёт примитивы LiveKit, которые каждую из них реализуют. Это третий урок серии по сборке на LiveKit – после опорной статьи по архитектуре и урока с репозиторием ноутейкера, – и он предполагает, что вы прочли как минимум опорную статью.

От ноутейкера к коучу: что меняется

Ноутейкер встреч на LiveKit, которого мы собрали в прошлом уроке, – правильная отправная точка, потому что коуч – это ноутейкер, у которого выросли три новых органа чувств и который научился хранить секрет. Он уже подключается к звонку как отдельный программный участник, уже транскрибирует каждого говорящего отдельно и уже молчит. Всё это мы сохраняем и добавляем сверху.

Ноутейкер был сознательно пассивным. Он собирал слова во время звонка, а своё единственное умное действие – резюме – выполнял только после того, как все вышли. Коуч переворачивает это. Его ценность целиком в моменте: подсказка, которая пришла после звонка, бесполезна. Поэтому коуч должен думать непрерывно, пока идёт звонок, и реагировать на три типа входных данных вместо одного.

Вот эти три дополнения – простыми словами, прежде чем углубляться в каждое.

Первое – tool-calling (вызов инструментов). Ноутейкеру никогда ничего не нужно было искать. Коучу нужно: когда клиент говорит «мы уже используем Acme», коуч должен уметь достать баттлкарту по Acme; когда клиент называет свою компанию, коуч должен уметь подтянуть карточку этого аккаунта из вашей базы. Tool-calling – это механизм, который позволяет языковой модели самой решить пойти за конкретной информацией, прежде чем ответить.

Второе – анализ экрана. Звонки по продажам – это не только разговор. Менеджер показывает экран – слайды, живое демо продукта, страницу с ценами, – и коуч, который не видит экран, наполовину слеп. Мы даём коучу глаза, подписываясь на видеотрек демонстрации экрана и снимая с него отдельные кадры, чтобы модель могла заметить, что «менеджер всё ещё на вводном слайде на восьмой минуте» или что «в демо только что выскочила ошибка».

Третье и самое важное – приватный канал. Молчание ноутейкера было удобством; молчание коуча в адрес клиента – жёсткое требование. Коуч должен достучаться до менеджера и только до менеджера. Мы делаем это прямым адресным сообщением, которое сервер LiveKit доставляет одному участнику, так что подсказка структурно невидима для всех остальных в комнате.

Дальше урок разбирает эти три по очереди, а потом показывает, как они складываются в один цикл. Начинаем с правила приватности, потому что оно ограничивает всё остальное.

Непреложное правило: коуч приватен

Коуч продаж, которого слышит клиент, – это не инструмент коучинга, а инструмент саботажа. Вся фича держится на одной гарантии: вывод коуча идёт менеджеру и больше никому. Ошибитесь здесь хоть раз в проде – и вы слили собственный плейбук (лимиты скидок, тезисы против конкурентов, вашу оценку покупателя) самому покупателю, на записанном звонке. Поэтому приватность мы закладываем на уровне транспорта, а не надеемся, что промпт заставит модель помолчать.

LiveKit даёт ровно нужный примитив: удалённый вызов процедуры, или RPC – способ для одного участника вызвать именованную функцию у другого конкретного участника и получить ответ. Слово «конкретного» здесь – это всё. Когда агент вызывает perform_rpc, он обязан указать destination_identity. Сервер LiveKit доставляет это сообщение тому одному участнику. Ни один другой участник комнаты его не получает. Клиент покупателя никогда не является адресатом, поэтому перехватывать нечего.

Нажмите, чтобы увеличить

В коде приложение менеджера регистрирует обработчик, который агент может вызвать, а агент вызывает его, указывая identity менеджера как адресата. Форма небольшая:

# В агенте: доставить подсказку ТОЛЬКО менеджеру.
await ctx.room.local_participant.perform_rpc(
    destination_identity=rep_identity,        # менеджер — никогда не клиент
    method="coach_nudge",                     # метод, который зарегистрировало приложение менеджера
    payload=json.dumps({
        "kind": "objection",
        "headline": "Возражение по цене — заякорить на ROI",
        "detail": "Сказали про бюджет. Откройте слайд ROI; назовите окупаемость за 6 недель.",
    }),
    response_timeout=4,                        # сдавайтесь быстро: запоздавшая подсказка — это шум
)

Три вещи в этом вызове несут на себе безопасность. destination_identity – это менеджер, установленный при его подключении и переданный агенту; как именно передать – в разделе про RAG. payload – это обычный текст, ограниченный LiveKit до 15 KiB, что куда больше, чем нужно подсказке; мы шлём небольшой JSON, чтобы UI менеджера мог по-разному отрисовать подсказку про возражение и подсказку со следующим вопросом. А response_timeout короткий намеренно: коучинг скоропортящийся, поэтому если клиент менеджера не успевает подтвердить за пару секунд, мы выкидываем подсказку, а не даём ей прийти поздно и невпопад.

Парная половина живёт в клиенте менеджера и регистрируется один раз до звонка, чтобы быть готовой в момент, когда агент сработает:

# В приложении менеджера: принимать подсказки и рисовать их в приватной боковой панели.
@room.local_participant.register_rpc_method("coach_nudge")
async def on_coach_nudge(data: RpcInvocationData):
    tip = json.loads(data.payload)
    render_in_coach_panel(tip)   # панель, которую видит только менеджер
    return "shown"               # подтверждение обратно агенту

Поскольку RPC – это механизм «запрос-ответ», агент узнаёт, доставлена ли подсказка. Клиент менеджера возвращает короткое подтверждение; если же агент получает ошибку «адресат отключился» или «таймаут ответа», он понимает, что подсказка не дошла, и может не слать следующую, которая предполагает, что первую увидели. Один операционный нюанс из спецификации, который стоит усвоить: участник, помеченный как «скрытый» (hidden), вообще не может делать RPC-вызовы, поэтому сам агент должен быть обычным, нескрытым участником – хотя при этом он по-прежнему не публикует ни аудио, ни видео.

Резонный вопрос: почему не использовать широковещательное data-сообщение, которое LiveKit тоже поддерживает? Потому что широковещание по определению доходит до каждого участника, и единственное, что отделяло бы его от экрана клиента, – это клиентский код, который сам решает его проигнорировать. Это гарантия приватности, сделанная из надежды. Адресный RPC переносит гарантию в маршрутизацию сервера, где ей и место. Правило на вынос: коуч не публикует аудиотрек и не шлёт данные на всю комнату – он говорит только адресными сообщениями с одним получателем.

Способность первая: tool-calling

Когда канал безопасен, можно сделать коуча полезным. Первое новое чувство – умение что-то искать, и в LiveKit Agents это tool-calling.

Инструмент (tool) – это просто функция в коде вашего агента, которую вы разрешаете вызывать языковой модели. Вы пишете обычную Python-функцию, декорируете её, чтобы фреймворк её зарегистрировал, и пишете понятный docstring с описанием того, что она делает, – а модель читает этот docstring и сама решает, когда функцию стоит вызвать. Решение – за моделью; ваша задача – составить меню вариантов и хорошо описать каждое блюдо.

Для коуча продаж меню – это ваш процесс продаж, превращённый в функции. Несколько таких, которые нужны почти любому коучу:

from livekit.agents import function_tool, RunContext

@function_tool()
async def get_battlecard(self, context: RunContext, competitor: str) -> str:
    """Достать одностраничную баттлкарту по названному конкуренту, которого упомянул клиент.
    Используй в момент, когда всплывает конкурирующий продукт, чтобы менеджер мог его парировать."""
    return await battlecards.lookup(competitor)

@function_tool()
async def get_account_context(self, context: RunContext, company: str) -> str:
    """Подтянуть карточку CRM по компании клиента: открытые сделки, прошлые заметки,
    дату продления контракта. Используй рано, чтобы привязать совет к истории этого аккаунта."""
    return await crm.fetch(company)

@function_tool()
async def check_discount_authority(self, context: RunContext, percent: float) -> str:
    """Вернуть, вправе ли менеджер дать запрошенную скидку, и шаг согласования, если нет.
    Используй всякий раз, когда обсуждают цену или скидку."""
    return await pricing_rules.evaluate(self._rep_id, percent)

Читайте docstrings, а не только код. Каждый говорит модели две вещи: что функция возвращает и когда за ней тянуться. «Используй в момент, когда всплывает конкурирующий продукт» – это не комментарий для людей, а инструкция, которой модель реально следует. Расплывчатые docstrings дают коуча, который зовёт не тот инструмент не в то время; точные дают коуча, который ведёт себя как дисциплинированный пресейл-инженер.

LiveKit поддерживает два типа инструментов, и коуч продаж использует оба. Функции выше – это функциональные инструменты (function tools): код, который вы написали, работает на вашем сервере и обращается к вашим системам. Второй тип – провайдерские инструменты (provider tools): возможности, которые запускает на своих серверах вендор модели и которые подключаются к агенту одной строкой. Несколько фронтир-вендоров предлагают как провайдерские инструменты встроенный веб-поиск, поиск по загруженному набору файлов и исполнение кода. Для коуча провайдерский file-search – быстрый способ дать модели запрашивать ваши материалы по продажам, не строя систему поиска в первый день, – хотя, как мы увидим в разделе про RAG, обычно вы его перерастаете.

Нажмите, чтобы увеличить

Есть одна ловушка, уникальная для коуча реального времени, и она про время, а не про корректность. Обычный голосовой ассистент может сделать паузу и сказать «секунду, проверю», пока работает медленный инструмент, потому что человек ждёт ответа. У коуча такой роскоши нет: клиент продолжает говорить независимо от того, ответила ли ваша CRM. Если коуч блокирует весь цикл в ожидании трёхсекундного запроса к CRM, он отстаёт от разговора, а подсказка про тему тридцатисекундной давности хуже, чем никакой. Ответ LiveKit – асинхронные, или фоновые, инструменты: долгий инструмент работает, не замораживая агента, так что модель продолжает обрабатывать новые реплики и доставляет медленный результат, когда он придёт. Правило: любой инструмент, который обращается к внешнему сервису вне вашего контроля, считайте потенциально медленным и запускайте в фоне, оставляя цикл свободным.

Сделаем задержку конкретной, потому что это и есть число, которое решает, ощущается фича волшебной или сломанной. Допустим, клиент договаривает предложение, и ваш конвейер выполняет: финализацию распознавания речи, решение модели вызвать инструмент, поход в CRM и составление подсказки.

финализация STT             ≈ 300 мс
модель решает + шлёт вызов    ≈ 400 мс
поход в CRM                   ≈ 500 мс
модель составляет подсказку   ≈ 500 мс
доставка RPC менеджеру        ≈ 50 мс
-----------------------------------------
итого                         ≈ 1 750 мс

Меньше двух секунд от конца фразы клиента до подсказки на экране менеджера. Это достаточно быстро, чтобы быть полезным, и достаточно медленно, чтобы не притворяться обратным: менеджер читает подсказку во время собственной паузы на размышление, а не в момент, когда отзвучало последнее слово клиента. Урок про бюджет задержки до 100 мс объясняет, почему этапы речи и сети стоят столько, сколько стоят; практический вывод здесь в том, что поход в инструмент – самый большой управляемый кусок, поэтому медленные инструменты место в фоне, а закэшированная или заранее загруженная баттлкарта бьёт живой запрос к базе, когда вы можете это устроить.

Способность вторая: анализ экрана

Второе чувство – зрение, и конкретно зрение разделяемого экрана менеджера. В LiveKit разделяемый экран публикуется как видеотрек, ровно как камера: та же механика, другой источник. Поэтому дать коучу глаза – значит подписаться на этот трек и превратить его движущуюся картинку в отдельные кадры, которые модель может прочитать.

Языковые модели не смотрят видео так, как мы. Большинство читают кадр – одно неподвижное изображение – за раз. Поэтому коуч не стримит весь экран в модель; он семплирует. Он берёт кадр по расписанию или когда происходит что-то интересное, отдаёт это одно изображение модели вместе со свежей транскрипцией и даёт модели рассуждать о том и другом сразу. Собственная поддержка зрения в LiveKit семплирует около одного кадра в секунду, пока пользователь говорит, и один кадр каждые три секунды, когда не говорит, и масштабирует каждый взятый кадр так, чтобы он вписался в 1024 на 1024 пикселя, перед кодированием в JPEG. Эти значения по умолчанию – разумная отправная точка; для разделяемого экрана вы часто будете замедлять их ещё сильнее, потому что слайды меняются куда реже, чем лицо.

Нажмите, чтобы увеличить

Деталь, которая отделяет работающего коуча от сбивающего с толку, – это то, какой трек вы семплируете. На звонке по продажам нередко одновременно живут несколько видеотреков: камера менеджера, камера клиента и разделяемый экран менеджера. Автоматический режим живого видео в LiveKit использует только единственный самый недавно опубликованный видеотрек, что удобно для ассистента с одной камерой и неверно для коуча: если клиент включит камеру после того, как менеджер начал показывать экран, коуч вдруг будет смотреть на лицо клиента вместо демо. Поэтому коуч не должен полагаться на автоматический режим. Вместо этого он перебирает опубликованные треки менеджера, выбирает тот, чей источник – демонстрация экрана, и семплирует именно его. У демонстрации экрана есть собственный источник трека ровно для того, чтобы вы могли отличить его от камеры; используйте это различие, а не угадывайте по свежести.

Вот выбор и семплирование, обрезанные до сути:

from livekit import rtc

def attach_to_screenshare(self, rep: rtc.RemoteParticipant) -> None:
    # Выбираем именно трек ДЕМОНСТРАЦИИ ЭКРАНА, не камеру и не «самый недавний».
    for pub in rep.track_publications.values():
        if pub.source == rtc.TrackSource.SOURCE_SCREENSHARE and pub.track:
            self._frames = rtc.VideoStream(pub.track)
            break

async def latest_screen_frame(self):
    # Держим только самый свежий кадр; мы семплируем, а не стримим каждый кадр.
    async for event in self._frames:
        self._latest = event.frame

Когда коуч собирается думать – скажем, на каждой завершённой реплике клиента – он прикрепляет самый свежий кадр экрана к этой реплике, так же как ноутейкер прикреплял строку транскрипции. Тогда модель видит слова и экран сразу и может выдать совет, зависящий от обоих: «Они спросили про безопасность, а вы всё ещё на слайде с ценами – перейдите к разделу комплаенса».

Две оговорки. Первая – стоимость, и она немаленькая. Каждый кадр, который вы семплируете, – это изображение, которое модель должна прочитать, а vision-вход оплачивается за изображение. Семплируйте 30-минутный звонок раз в три секунды – и вы скормили модели около шестисот изображений; раз в секунду – около тысячи восьмисот. Поэтому частота семплирования – это прямой, линейный рычаг издержек: самый дешёвый коуч с экраном – тот, что семплирует только когда транскрипция намекает, что экран важен, а не по фиксированному частому таймеру. Эту поэлементную экономику мы моделируем в реальной стоимости ИИ в видео-продуктах, а компромиссы в том, как часто и как богато семплировать кадры, – целиком тема урока Video VLMs – семплирование кадров против потока токенов.

Вторая оговорка – понятность. Неподвижный кадр слайда модель читает легко; кадр на середине прокрутки или быстрого демо может быть смазом, который ничего полезного модели не скажет. Содержимое экрана к тому же необычно детальное – мелкий текст, плотные таблицы, – так что уменьшение до 1024 пикселей может стереть тот самый текст, который вы хотели прочитать. Для коуча это обычно нормально, потому что вам нужна суть («на экране таблица с ценами»), а не мелкий шрифт; но если когда-нибудь понадобится мелкий шрифт, семплируйте этот один кадр в более высоком разрешении и примите более высокую стоимость.

Способность третья: скормить коучу ваш плейбук

Инструменты позволяют коучу подтянуть конкретную запись по запросу. Но коучу нужны и широкие, всегда доступные знания – ваша методология, факты о продукте, позиционирование против конкурентов, – которые должны окрашивать каждую подсказку без вызова инструмента каждый раз. Эти постоянные знания поставляет генерация с дополнением поиском (RAG), а рекомендации LiveKit по внешним данным задают, как их подключить, не замедляя звонок.

Начните с разделения двух видов знаний по тому, как часто они меняются. Ваша методология продаж и факты о продукте одинаковы для каждого звонка, поэтому загружайте их один раз при старте процесса агента – LiveKit называет это шагом prewarm – и переиспользуйте на всех звонках, которые этот процесс обслуживает. Противоположный полюс – данные, специфичные для этого одного звонка: какой менеджер на нём, какой аккаунт, что говорили на прошлом звонке. Это место не в prewarm, а в метаданных звонка, переданных агенту при его диспетче. LiveKit позволяет приложить это как job metadata или participant attributes, и рекомендация явная: шлите данные конкретного звонка как метаданные, а не загружайте их внутри стартового пути агента, и если уж надо сделать сетевой вызов на старте – делайте его до подключения агента к комнате, чтобы менеджер не увидел коуча раньше, чем тот реально готов. Здесь же приходит identity менеджера – тот самый destination_identity с рис. 1, – чтобы коуч знал, кому шептать.

Между этими двумя полюсами лежит живой поиск: пока клиент говорит, подтянуть самый релевантный к только что сказанному кусок вашего плейбука. Это можно сделать двумя способами, и выбрать правильно – это разница между шустрым и вялым коучем. Способ через вызов инструмента мы уже видели: модель решает вызвать get_battlecard, что стоит лишнего похода в модель. Более быстрый способ, когда вы гоняете конвейер «распознавание-затем-модель», – выполнить поиск на завершённой реплике пользователя до того, как сработает модель, и вставить результат прямо в её контекст. LiveKit предоставляет это как хук on_user_turn_completed, и его документация называет выигрыш прямо: он избегает лишних походов, которые несут вызовы инструментов, потому что поиск происходит на том же шаге, что и реплика, а не отдельным вызовом, который модель должна запросить и ждать. Компромисс в том, что вы отдаёте суждение модели о том, стоит ли вообще что-то искать, – вы ищете всегда, – поэтому это лучше всего для поиска, который вы хотите на каждой реплике, вроде «найти кусок плейбука, самый релевантный только что сказанному».

Простое эвристическое правило: используйте вставку на завершённой реплике для широкого контекста плейбука на каждом ходу, а явные инструменты приберегите для точных, нечастых действий – подтянуть один названный аккаунт, проверить одну скидку, записать исход в CRM. Урок про video RAG по архиву уходит вглубь самой стороны поиска; здесь же суть только в том, где в цикле звонка каждый вид знаний входит.

Складываем вместе: цикл коуча

Теперь у нас есть все части. Отойдите и посмотрите, как идёт один полный цикл, потому что архитектура – это просто эти куски, собранные в правильном порядке.

Нажмите, чтобы увеличить

Клиент договаривает предложение. Транскрайбер с одной сессией на говорящего – тот же паттерн, что у ноутейкера, по одной сессии распознавания на участника, чтобы каждая строка была атрибутирована, – выдаёт финализированную строку, приписанную клиенту. На этой завершённой реплике коуч достаёт самый релевантный кусок плейбука и вставляет его, прикрепляет свежий кадр экрана и запускает модель. Модель может решить, что ей нужен конкретный факт, и вызвать инструмент; если инструмент медленный, он работает в фоне, пока цикл остаётся отзывчивым. Модель составляет короткую подсказку. Коуч шлёт её по RPC, адресованному менеджеру, и приватная панель менеджера обновляется. Клиент всё это время не слышал и не видел ничего, кроме менеджера.

Заметьте, что коуч по-прежнему не говорит и по-прежнему не публикует видео. Он, как и ноутейкер, участник «слушать-и-смотреть» – он просто ещё и думает непрерывно и шепчет приватно. Всё, что делало ноутейкера безопасным и дешёвым в эксплуатации, сохранено; мы лишь добавили чувства и рот, который открывается ровно для одного человека.

Строить это или купить надстройку для коучинга?

Коучинг в реальном времени теперь настоящая категория продуктов, поэтому честное сравнение – против покупки, а не сборки. Устоявшиеся вендоры conversation intelligence и волна новых инструментов реального времени доставляют живые баттлкарты, подсказки по возражениям и сигналы о пропущенных вопросах во время звонков; сдвиг 2026 года на этом рынке – «агентный» коучинг, который не просто помечает момент, но и набрасывает письмо-фоллоуап и обновляет CRM после звонка. Если вы хотите коучинг, прикрученный к уже существующим звонкам ваших менеджеров в Zoom или Meet, и вам не нужно, чтобы он жил внутри вашего продукта, – купить быстрее.

Версию на LiveKit вы строите, когда коучинг должен жить внутри софта, которым вы уже владеете, – вашего приложения для видеоконференций, телемед-платформы, e-learning-комнаты, инструмента для продаж, который вы поставляете клиентам, – или когда плейбук, модели и данные звонков должны оставаться на инфраструктуре, которую вы контролируете. Это та же логика «строить или купить», что и у ноутейкера, на ступень способностей выше.

Структура издержек, если вы строите, расширяет издержки ноутейкера. Те же три счётчика LiveKit – минуты участников WebRTC для всех в комнате, включая агента; минуты сессии агента за его собственный рантайм; и распознавание речи за минуту аудио. Коуч добавляет два счётчика модели, которых ноутейкер в основном избегал: текстовые токены за непрерывное думание и vision-токены за каждый семплированный кадр экрана. Ноутейкер гонял один проход модели в конце звонка; коуч гоняет много проходов во время него. Это цена действия в моменте, и частота семплирования с рис. 3 – ваш главный регулятор vision-половины этой цены.

«Частая ошибка: коуч, который протекает, блокирует или достаёт. Три режима отказа дают большинство сломанных коучей. Первый – утечка: у агента включён аудиовыход, или он шлёт совет широковещанием на всю комнату, и клиент видит плейбук. Решение: не публиковать аудио и доставлять только адресным RPC одному получателю, как на рис. 1. Второй – блокировка: медленный инструмент CRM замораживает цикл, и коуч отстаёт от разговора. Решение: гонять сетевые инструменты в фоне и держать цикл свободным. Третий – занудство: коуч стреляет подсказкой на каждой реплике, менеджер тонет и выключает панель. Решение: повысить в инструкциях модели планку для прерывания и ограничить частоту подсказок в своём коде – не чаще одной в несколько секунд. Коуч, который молчит 90% времени и точен в остальные 10%, – это тот, которого менеджеры оставляют включённым.»

Пара слов о согласии и законе

Поскольку коуч обрабатывает слова и экран клиента в реальном времени, он попадает прямо под законы о записи звонков и раскрытии ИИ, и проектировать под это нужно заранее, а не прикручивать потом. В США несколько штатов требуют согласия всех сторон звонка на его запись или мониторинг; в Европейском союзе правила прозрачности AI Act требуют информировать людей, когда они взаимодействуют с системой ИИ или обрабатываются ею, во многих контекстах. Безопасные значения по умолчанию: в начале звонка раскрыть, что присутствует ИИ-ассистент, гейтить коуча за этим раскрытием и согласием и держать обработку данных клиента внутри того, что уже покрывает ваше согласие на запись. Ничто из этого не является юридической консультацией – мы инженеры, а не ваши юристы, – и конкретика зависит от юрисдикции и меняется со временем, поэтому относитесь к согласию как к продуктовому требованию, которое нужно подтвердить с юристом, так же как вы относились бы к хранению медицинских данных. Детали инженерии раскрытия для ИИ-фич живут в уроке про статью 50 EU AI Act.

Где здесь Фора Софт

Мы строим продукты для видео в реальном времени с 2005 года – видеоконференции, телемедицину, e-learning и живое сотрудничество, – и агент встреч стал почти дефолтным запросом на проектах по конференциям, которые мы оцениваем. Коуч – более ценная версия этого запроса: тот же участник «слушать-и-смотреть», теперь с tool-calling в CRM и плейбук клиента и приватным каналом обратно к одному пользователю. Архитектура из этого урока – та, к которой мы тянемся, когда коучинг должен жить внутри собственного продукта клиента, а не в стороннем сервисе, прикрученном к Zoom. В телемедицине тот же паттерн приватной подсказки становится подсказкой врачу во время приёма; в e-learning – тихой подсказкой преподавателю; в продажах – описанным здесь коучем. Инженерное суждение, которое нам важно: сначала правило приватности, вторым бюджет задержки, третьим регулятор издержек – частота семплирования.

Главное

• Коуч продаж – это ноутейкер плюс три чувства: tool-calling, зрение экрана и приватный канал.
• Непреложное правило: доставлять совет по RPC, адресованному только менеджеру, – не аудио в комнату и не широковещание.
• Docstrings инструментов – это инструкции, которым модель следует; пишите «когда использовать», а не только «что вернёт».
• Гоняйте медленные инструменты в фоне, чтобы коуч не отстал от живого разговора.
• Семплируйте именно трек демонстрации экрана, а не самое недавнее видео; частота семплирования – ваш регулятор издержек.
• Коучинг в реальном времени регулируется: раскрывайте ИИ, берите согласие, подтверждайте правила с юристом.

Что почитать дальше

• Ноутейкер встреч на LiveKit – полный репозиторий
• ИИ-ассистент встреч на LiveKit – архитектура и цены
• Video VLMs в 2026 – семплирование кадров против потока токенов