Randall Newman, CPTO и соучредитель Satisfi Labs — серия интервью

Randall Newman, CPTO и соучредитель Satisfi Labs, является технологическим и продуктовым лидером с обширным опытом создания AI‑платформ, финансовых технологий и высокопроизводительных систем. С момента соучреждения Satisfi Labs Ньютман сыграл центральную роль в формировании, проектировании и масштабировании разговорных AI‑технологий компании, одновременно руководя разработкой продукта, архитектурой, инженерными командами и стратегическими интеграциями. До Satisfi Labs он работал руководителем продукта в Satisfi Inc. и соучредил компанию мобильного маркетинга Right On Mobile. Ранее в своей карьере Ньютман провёл более 17 лет в CIBC World Markets, где занимал старшие руководящие позиции в областях стратегического риска, высокочастотной торговли и арбитража акций, сочетая экспертизу в количественной торговле с практической разработкой технологий.

Satisfi Labs — AI‑компания, сосредоточенная на развертывании специализированных AI‑агентов для спорта, развлечений, туризма, аттракционов и других бизнесов, предоставляющих живые впечатления. Основанная в 2016 году, компания эволюционировала от разговорного AI и своего Answer Engine к агентской платформе, предназначенной помогать организациям автоматизировать поддержку гостей, повышать конверсию билетов и коммерческих продаж, а также извлекать инсайты из разговоров с клиентами. Ее AI‑агенты могут работать более чем на 50 языках и интегрироваться с системами продажи билетов, CRM, управления контентом и другими бизнес‑системами, выполняя такие действия, как продажа билетов, эскалация диалогов к человеческому персоналу, сбор информации о клиенте и предоставление персонализированных ответов. Satisfi Labs заявляет, что её технология теперь доверена более чем 775 брендам, а интеграции и партнёрства охватывают компании, такие как Ticketmaster, Simpleview, MappedIn, Ventrata и Vozzi.

Вы провели почти два десятилетия в финансовых рынках, включая создание систем низкой задержки и руководство стратегиями высокочастотной торговли в CIBC, прежде чем перейти к технологическому предпринимательству и в конечном итоге соучредить Satisfi Labs. Какие уроки из операционных систем, где скорость, надёжность и управление рисками были критически важны, наиболее повлияли на то, как вы сегодня создаёте AI‑агенты уровня production‑grade?

Торговля научила меня, что хорошая идея и хороший бизнес — это две разные вещи. Вы можете правильно определить возможность, но всё равно потерять деньги, если ваша реализация медленная, издержки слишком высоки или предположения о риске неверны. AI — то же самое. Возможности модели — лишь один ввод. Бизнес зависит от того, сможете ли вы превратить эту возможность в повторяемый результат при приемлемых затратах и риске.

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

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

Последний урок — тот, который и запустил весь бизнес. Преимущество приходит от обнаружения неправильного ценообразования раньше, чем все остальные. Я считаю, что сейчас неправильное ценообразование заключается в том, что большинство компаний рассматривают AI‑агентов как способ сократить затраты на поддержку. В Satisfi Labs мы видим их как канал дохода. В наших спортивных площадках около 40 % разговоров агентов посвящено билетам. Эти фанаты приходят не с жалобами, а с деньгами в руках, спрашивая, где им сесть. Найдите то, что рынок оценивает неправильно, и захватите это. Тот же инстинкт, что и в арбитражном бизнесе.

Satisfi Labs была основана в 2017 году, задолго до текущего бума генеративного AI, и эволюционировала от контекстной обработки естественного языка и разговорного AI к агентской платформе. Какие были крупнейшие архитектурные изменения, необходимые для перехода от систем, в первую очередь отвечающих на вопросы, к агентам, способным выполнять действия от имени пользователей?

Мы провели десятилетие, создавая тысячи AI‑агентов для более чем 800 корпоративных клиентов, включая команды MLB/NFL, развлекательные площадки и туристические организации. Главное изменение состоит в том, что вы предоставляете системе полномочия, а не просто информацию.

Если помощник сообщает вам, какие билеты доступны, он даёт ответ. Если он меняет ваши билеты, он изменяет инвентарь, клиентские записи и потенциально деньги. Теперь необходимо знать, кто уполномочил действие, что именно произошло и как восстановиться, если процесс прерывается на полпути.

Поэтому мы разделяем суждение модели и полномочия на исполнение. Модель может интерпретировать запрос и предложить следующий шаг. Системы под ней обеспечивают соблюдение разрешений, бизнес‑правил и лимитов транзакций. Убедительное объяснение модели не может переопределить эти ограничения.

Также требуется чёткое различие между «агент сказал, что задача выполнена» и «бизнес‑система подтвердила завершение». Это не одно и то же. Если запрос на покупку истекает по времени, вам лучше выяснить, произошла ли покупка, прежде чем пытаться снова.

И стратегически более продвинутые модели не должны заставлять вас перестраивать бизнес‑контролы. Я хочу использовать каждое улучшение в рассуждениях, не пересматривая, что системе разрешено делать каждый раз, когда появляется новая модель.

Термин «агентный ИИ» теперь применяется к широкому спектру продуктов. С инженерной точки зрения, где вы проводите грань между продвинутым чат‑ботом, ИИ‑копилотом и действительно автономным ИИ‑агентом?

Я бы задал один вопрос: какую ответственность действительно делегировал человек?

Чат‑бот предоставляет информацию. Копилот помогает выполнять работу, но вы всё равно направляете и одобряете важные шаги. Автономный агент имеет разрешение принимать некоторые из этих решений самостоятельно, преследуя цель.

Интерфейс не подсказывает, какой из них вы видите. У разговорного продукта может быть реальная автономия. То, что рекламируется как агент, всё равно может требовать одобрения каждой полезной операции со стороны человека.

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

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

Satisfi Labs недавно запустила Satisfi Forward, практику инженерии с прямым внедрением. Какой разрыв вы видели между созданием способной AI‑платформы и реальной надёжной работой агентов в реальной среде клиента, который заставил вас создать эту модель?

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

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

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

Стоимость разработки кода также значительно снизилась, что делает эту модель гораздо более практичной, чем раньше. Но я не рассматриваю Satisfi Forward как сервисный отдел, прикреплённый к SaaS‑продукту. Каждый проект учит нас, каким должен быть следующий продукт. Когда три клиента просят один и тот же рабочий процесс, это не нагрузка на поддержку. Это фактически написание дорожной карты с привлечёнными платными клиентами. Старая модель SaaS угадывала функции и ждала доказательств. Так мы получаем доказательства в первую очередь и доход, пока собираем их. Я считаю, что именно так создаются продуктовые компании в эпоху ИИ.

Ваши агенты могут подключаться к системам тикетирования, платформам управления взаимоотношениями с клиентами, системам управления контентом и другим источникам информации в реальном времени. По мере того как агенты получают возможность совершать транзакции и инициировать действия, как вы балансируете доступ к данным в реальном времени и низкую задержку с обоснованием, безопасностью и мерами предосторожности против неверных действий?

Во‑первых, я никогда не позволю скорости компенсировать сбой безопасности. Некоторые требования являются ограничениями. Вы оптимизируете в их рамках.

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

Опасные случаи — это когда система не знает, что произошло. Бэкенд принимает покупку, но ответ никогда не приходит. Если агент считает, что произошёл сбой и повторяет попытку, у вас оказывается две покупки. Это не проблема языка, а проблема восстановления транзакции.

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

Здесь тоже есть решение о стоимости. Не каждый запрос требует самой дорогой модели или цепочки агентов. Используйте самый простой путь, который удовлетворяет требованию, и тратьте дополнительное время или вычислительные ресурсы там, где это действительно улучшает решение. Пользователь должен получить честный результат, включая честное заявление о том, что что‑то не удалось подтвердить.

Satisfi Labs описывает модель, в которой специализированные агенты могут работать вместе как AI‑рабочая сила. Какие самые сложные технические проблемы возникают при оркестрации нескольких специализированных агентов, особенно в отношении маршрутизации, общего контекста, конфликтующих решений и определения, какой агент должен действовать?

Самая сложная часть — сохранять подотчётность при распределении работы.

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

Когда оправдано несколько агентов, я хочу, чтобы один агент владел взаимодействием. Специалисты могут предоставлять информацию или выполнять ограниченную работу. Агент по билетам обрабатывает инвентарь и обмены, агент службы поддержки обслуживает политики. Но кто‑то должен согласовать результаты и решить, получил ли пользователь то, что он хотел.

Маршрутизация сложна, потому что люди не задают вопросы в чётко определённых категориях. Один запрос может затрагивать трёх агентов. Система должна решить: может ли один агент справиться, нужно ли запускать несколько последовательно, или следует задать пользователю ещё один вопрос перед выполнением чего‑либо.

То же самое с контекстом. Вы не отправляете всё каждому агенту. Это увеличивает задержку, создаёт шум и может раскрыть информацию, которая агенту не нужна. И предположение агента не должно становиться фактом лишь потому, что оно передано следующему агенту.

Если два агента расходятся во мнениях, я не хочу, чтобы они спорили, пока один не покажется более убедительным. Должна быть чёткая модель авторитета. Система билетов определяет доступность. Бизнес определяет политику обмена. Данные в реальном времени превосходят кэшированные данные, бизнес‑правила превосходят суждения модели, и если всё равно нельзя решить проблему, вы спрашиваете пользователя или привлекаете человека. Трудность не в том, чтобы заставить агентов разговаривать друг с другом. Сложно именно восстановить, какой агент что сделал и где лежала ответственность.

Satisfi Labs всё больше сосредотачивается на измерении агентов по целям и бизнес‑результатам, а не по метрикам вроде объёма разговоров. Что предприятиям действительно следует измерять, чтобы определить, насколько хорошо работает AI‑агент, и как оценить надёжность перед тем, как предоставить агенту большую автономию?

Начните с бизнес‑результата, затем спросите, какую часть этого результата действительно создал агент.

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

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

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

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

Вы недавно утверждали, что голосовой ИИ должен разрабатываться вокруг измеримых результатов, а не рассматриваться как ещё один интерфейс для существующего чат‑бота. Какие технические прорывы всё ещё необходимы, чтобы голосовые агенты стали основным интерфейсом для сложных, реального времени взаимодействий, особенно в таких средах, как стадионы, аттракционы и живые мероприятия?

Многие клиенты спрашивают: можно ли просто взять чат‑приложение и подключить к нему голос? Мы можем. Но это не значит, что будет хороший опыт. Следующее реальное улучшение — не более «человеческий» голос. Это взаимодействие, которое выдерживает условия, в которых люди действительно его используют.

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

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

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

Некоторые части требуют более качественных моделей. Большая часть нуждается в лучшей интеграции и дизайне взаимодействия. Ожидание прорыва не исправит рабочий процесс, построенный вокруг текста, а затем озвученного. Я бы оценивал прогресс так: справляются ли люди с задачей точно, с меньшими усилиями, в реальных условиях?

По мере того как агенты переходят от предоставления информации к продаже билетов, сбору данных о клиентах, персонализации опыта и взаимодействию с операционными системами, как компании должны определять, какие решения агент может принимать автономно, а какие всегда требуют человеческого контроля?

Это управление рисками. Если всё пойдёт не так, какой ущерб это может нанести? Откроет ли агент дверь, которую не сможет закрыть?

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

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

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

Ограничения должны применяться системами, которые выполняют действие, а не просто описываться в подсказке. Вы не даёте агенту широкий доступ и затем полагаетесь на подсказку, заставляющую его быть осторожным. И когда требуется человек, предоставьте ему достаточно контекста для реального решения. Передать кому‑то сотни одобрений без информации — значит создать печать‑резиновый штамп, а не надзор. Сосредоточьтесь на человеческом внимании там, где оно снижает значимый риск. Не распыляйте его по каждому взаимодействию.

Смотря в будущее, ожидаете ли вы, что такие технологии, как Model Context Protocol и коммуникация агент‑к‑агенту, фундаментально изменят способ построения корпоративных ИИ‑систем, переводя нас от изолированных агентов к экосистемам, где агенты могут находить инструменты, обмениваться контекстом и координировать действия между компаниями и платформами?

Я считаю, что протоколы — это средство к цели. MCP предоставляет ИИ‑приложениям общий способ доступа к инструментам и контексту. Протоколы агент‑к‑агенту обеспечивают сотрудничество между агентами. Это ценно. Вам не должно приходиться каждый раз создавать пользовательскую интеграцию, когда агенту нужен инструмент. Это аналогично тому, как API упростили интеграцию программного обеспечения.

Но единый формат не означает, что два бизнеса согласны с тем, что означает действие, кто может его авторизовать и что происходит при сбое. То, что агент может обнаружить инструмент, не значит, что ему разрешено его использовать. Всё равно нужно решать вопросы идентификации, прав доступа, доверия и ответственности. Если один агент просит другого выполнить что‑то и происходит ошибка, кто несёт ответственность за это решение?

Вот что, по моему мнению, действительно меняет ситуацию. Сегодня у площадки есть веб‑сайт и приложение. Через несколько лет у неё будет агент, с которым будут вести переговоры другие агенты. Персональный помощник фаната запрашивает у агента площадки два места по определённой цене, плюс парковочный пропуск, и вся транзакция происходит между двумя агентами. Найти нужные возможности — простая часть. Понимание полномочий клиента, подтверждение общей цены и обработка случая, когда билеты успешно куплены, а парковка не прошла, — вот реальные задачи.

И я не считаю, что управление агентом автоматически передаёт вам отношения с клиентом. Это нужно заслужить. Но я также не верю, что площадки передадут эти транзакции поисковой компании или билетному маркетплейсу. Наша цель в Satisfi Labs — стать агентом, представляющим площадку в этой экономике, тем, на кого бизнес может положиться и поставить своё имя. Всё, что мы построили вокруг надёжности, прав доступа и ответственности, и обеспечивает нам это место.

Спасибо за отличное интервью, читатели, желающие узнать больше, должны посетить Satisfi Labs.