Merge автоматизировал планирование ужинов: с десятков часов до 30 минут на событие

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

Что делает бот для ужинов

Merge продаёт инфраструктуру для ИИ-продуктов: синхронизацию клиентских данных, безопасный доступ агентов к инструментам, маршрутизацию моделей и контроль расходов. Часть работы компания делает на собственных продуктах.

Пример — закрытые ужины для клиентов и потенциальных клиентов. Для ужина в Далласе команда задала город и портрет гостей. Дальше бот достал кандидатов из CRM и Apollo, проверил прошлые приглашения и ответы, подготовил рассылку от имени CEO Шенси Дин. Он же ведёт таблицу участников, предлагает рассадку и создаёт заметки в календаре, куда продажи и customer success добавляют контекст по каждому гостю.

Разделение ролей простое: модель рассуждает и пишет черновики, а коннекторы Merge дают доступ к Salesforce, Gong, Google Sheets и Gmail. Дин проверяет результат, переписывает фразы, которые звучат фальшиво, и сама формирует список гостей, потому что у бота нет контекста личных отношений.

По данным компании, подготовка списков, писем и ведение таблицы раньше занимали десятки часов на всю команду, теперь около 30 минут на событие. Сравнение охватывает одни и те же задачи за три месяца. Параллельно число ужинов выросло с 8 в Q2 до 16 в Q3, а на Q4 запланировано больше 30.

Что здесь полезно разработчикам

Главный тезис касается надёжности. Merge утверждает, что вызовы инструментов через её слой проходят успешно в 99,9% случаев, а через публичные MCP-серверы — примерно в 60%. Методику сравнения компания не раскрывает, а продаёт как раз тот слой, который якобы решает проблему. Но сама проблема знакома каждому, кто собирал агентов: модель может быть хорошей, а цепочка падает на авторизации, схемах и таймаутах интеграции.

Вторая деталь — Codex для ревью кода. Дин показала, как он помог с новой вкладкой настройки доступа к инструментам: обсуждали, как сделать кнопку «Add tool pack» понятнее. При этом решения принимали люди, а инженеры отвечали за проверку и выпуск. Это честная схема: ревьюер подсказывает, ответственность остаётся за командой.

Третья — рабочие процессы для не-инженеров. Руководитель продаж собрал повторяемые сценарии для согласования сделок, обновления прогнозов и шагов после звонков по продлению. Он не пересобирает контекст каждый раз, а получает подготовленный материал и принимает решение сам.

Ограничения

Во-первых, это рекламный формат. Время «до и после» измерено самой компанией, и в нём нет затрат на разработку бота и его поддержку. Во-вторых, бот отправляет письма от имени CEO, а значит, ошибка в адресате или тоне стоит репутации. Поэтому там и остаётся человек, который читает всё перед отправкой. В-третьих, рост числа ужинов не доказывает рост выручки: в материале есть только положительные отзывы и возможности для демо.

Хвалебные отзывы о «характере» модели и о том, что она додумывает недосказанное, лучше считать впечатлениями пользователя, а не измерением.

Практический вывод

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