30 октября 2026 года стартап Zest представил персонального AI-консьержа, который живёт в текстовых сообщениях. Пользователь пишет на номер (212) 470-6067, получает подборку ресторанов под свои вкусы и там же оформляет бронь. Приложение Zest для поиска заведений вышло раньше, консьерж стал следующим шагом: подбор, уточнения и резерв столика переехали в обычную переписку. TechCrunch описывает запуск и приводит детали работы агента.
Компания основана в ноябре 2024 года. До анонса консьержа Zest привлекла 1,8 млн долларов pre-seed финансирования от Alexis Ohanian (фонд 776) и Steve Jang (Kindred Ventures).
Что такое AI-консьерж Zest и как им пользоваться
Механика простая: агент принимает текстовый запрос и отвечает списком мест. Формулировка попадает в описанные возможности так: «нужно итальянское место на пятницу вечером, район SoHo, двое, без рыбы». Агент вернёт варианты, при необходимости задаст уточняющий вопрос и забронирует стол. Отдельный интерфейс, регистрация и настройки не нужны, канал один, SMS.
Персонализация строится не на анкете и не на десяти сообщениях о любимой кухне. Приложение Zest связывается с кредитными картами пользователя и видит, где он реально ест. Консьерж использует ту же историю посещений, поэтому стартует не с нуля.
Чем консьерж отличается от приложения Zest
Приложение отслеживает визиты через привязку карт. Консьерж переносит всё взаимодействие в текстовый канал, и разница видна в трёх местах. Не нужно открывать отдельный интерфейс. Уточнения идут обычными сообщениями, как в переписке с другом, который хорошо знает город. Бронь оформляется в том же треде, где обсуждали варианты, без переключения между приложениями и вкладками.
Этот сдвиг шире одного продукта. Разговорные агенты берут на себя задачи, для которых раньше требовалось запускать отдельное мобильное приложение, и ресторанный сценарий здесь один из самых очевидных. Подробнее о том, как меняются интерфейсы: разбор перехода от приложений и сайтов к агентам.
Откуда агент знает вкусы: Plaid, кредитные карты и границы данных
Транзакции Zest импортирует через Plaid, финансовый сервис, который агрегирует данные по банковским счетам и картам. Из всего потока компания учитывает только операции в категориях еды и напитков: рестораны, кафе, бары. На этой истории строится профиль вкусов, который агент использует в переписке. Ограничение по категориям заявлено самой Zest.
Марио Гомес-Холл, основатель и CEO Zest, объясняет логику так: агент отвечает, отталкиваясь от истории самого пользователя и его друзей, поэтому ему не нужны недели диалога, чтобы выучить вкусы. Стартовая точка - места, где человек действительно был.
Почему история трат учит вкусам быстрее переписки
В рекомендательных системах это называют холодным стартом: пока про пользователя ничего не известно, выдача получается средней и одинаковой для всех. Транзакции дают сигнал сразу и с контекстом: тип кухни, ценовой уровень, частота визитов, район, размер чека, время. Универсальный ассистент такой сигнал получает только из разговора, и пользователю приходится самому пересказывать то, что и так записано в его выписке.
Ограничение здесь симметричное. Качество профиля зависит от объёма и чистоты истории: чем меньше человек платит картой, тем беднее данные. Наличные, оплата чужим счётом, корпоративные карты, заказ доставки вместо похода в зал искажают картину, а редкие визиты дают слишком мало точек для уверенных выводов. Плюс сам доступ к финансовым данным требует доверия к Plaid и к тому, как Zest обрабатывает и хранит эти транзакции. В исходном материале детали хранения и сроков не раскрыты, поэтому оценивать политику приватности придётся по документам самой компании, а не по описанию продукта.
Групповой чат, голосование и бронирование через OpenTable, Resy и SevenRooms
Групповой сценарий стал самой заметной частью запуска. Консьержа добавляют в чат, он объединяет вкусы участников и предлагает места, которые устроят всех, а не только того, кто задал вопрос. Дальше запускает голосование прямо в переписке и после выбора бронирует стол на группу, не выводя пользователя из разговора. Спор «куда пойдём» перестаёт требовать отдельного чата для голосования и ручного звонка в ресторан.
Резерв идёт через подключённые сервисы бронирования: OpenTable, Resy и SevenRooms. Проверку доступности и оформление брони выполняет агент, человек только подтверждает вариант. Компания тестировала консьержа за месяц до анонса, но придержала запуск, пока не добавила бронирование. То есть на момент анонса продукт закрывал цикл от подбора до резерва.
Какие уточнения принимает агент
Запрос можно формулировать по нескольким факторам: кухня, конкретное желание вроде «хочу рамен», повод, ограничения в питании, район. Отдельно разрешено спрашивать про само заведение: насколько оно загружено, есть ли Wi-Fi. Меню агент присылает по запросу, и это заметно сокращает путь до решения: посмотреть цены и состав блюд можно в том же чате, где выбирают место.
| Тип запроса | Что делает агент | Что уточнить у источника |
|---|---|---|
| Кухня, район, повод | Выдаёт список заведений с опорой на историю посещений | Насколько широко покрытие по городам |
| Ограничения в питании | Учитывает фильтр при подборе | Глубина проверки состава блюд не раскрыта |
| Загруженность, Wi-Fi | Отвечает на вопросы о заведении в переписке | Источник данных о загруженности |
| Меню | Присылает меню по запросу | Формат и актуальность меню |
| Компания друзей | Объединяет вкусы, запускает голосование в треде | Как учитываются конфликты предпочтений |
| Бронирование | Проверяет доступность и резервирует через OpenTable, Resy, SevenRooms | Какие рестораны подключены в вашем городе |
Насколько это работает на практике: тесты TechCrunch и честные ограничения
TechCrunch протестировал консьержа и описал результат: AI работал довольно хорошо и предложил список новых мест под вкусы тестировщиков с учётом времени дня, размера компании, локации и других факторов. Это ограниченный сторонний тест одного издания, а не выборка и не сравнение с альтернативами. Он подтверждает, что базовый сценарий подбора работает, и ничего не говорит об устойчивости на длинной дистанции, о точности рекомендаций в незнакомом городе или о поведении агента при плотной загрузке ресторанов.
Ограничения стоит держать в голове до первого сообщения:
- Зависимость от данных Plaid: без карточной истории персонализация слабеет до уровня обычного каталога.
- Привязка к сервисам бронирования: если ресторан не подключён к OpenTable, Resy или SevenRooms, автоматической брони не будет.
- География покрытия в источнике не раскрыта, поэтому для российских городов и части европейских локаций работа агента не подтверждена.
- Финансовые данные: пользователю нужно решить, готов ли он отдавать историю трат ради подбора ресторанов.
Проверить пользу самому можно по четырём пунктам: попадает ли выдача в ваши районы, появляются ли в ней места, которых вы не знали, срабатывает ли бронь без ручных правок и не приходится ли переспрашивать очевидное. Если хотя бы половина ответов положительная, агент экономит время. Если нет, история трат пока не превратилась в полезный профиль.
Место Zest в тренде разговорных AI-агентов
Запуск отражает общий сдвиг: разговорные агенты забирают задачи, для которых раньше требовалось открывать отдельное мобильное приложение. Zest попал в ту же волну, что Instinct и Poke: агент живёт в переписке, помнит контекст и выполняет действие за пользователя. Функции у этих продуктов разные, механика похожа, и конкуренция идёт не за экран смартфона, а за место в списке чатов.
Мессенджер как интерфейс даёт три вещи. Низкий порог входа: ничего не нужно устанавливать и настраивать. Готовый групповой сценарий: чат с друзьями уже существует, агента остаётся добавить. Привычный канал уведомлений, который человек и так читает. Минусы тоже предсказуемы: текстом плохо показывать каталог с фото и картами, а часть задач удобнее решать в визуальном интерфейсе, чем в переписке.
Отдельный вопрос в этом тренде - приватность групповых агентов. Как устроены разрешения и изоляция личных данных на примере Instinct: разбор механики доступа. Для Zest этот вопрос острее, чем для универсальных ассистентов: на кону история банковских транзакций, а не список покупок.
Бизнес-модель и перспективы: на чём Zest зарабатывает
Подтверждённая часть экономики продукта: 1,8 млн долларов pre-seed, инвесторы Alexis Ohanian (776) и Steve Jang (Kindred Ventures). Бронирование идёт через партнёрские сервисы, и это естественная точка, где агент может приводить гостя и превращать диалог в визит. Логика схемы прозрачна: ресторан получает заполненный стол, сервис бронирования фиксирует источник, Zest забирает свою часть.
Детали монетизации в доступном материале не подтверждены. Текст TechCrunch обрывается на фразе о дальнейших планах, поэтому упоминания о доходе с бронирований и будущем заказе еды, а также о выходе за пределы ресторанов стоит читать как заявленные намерения, а не как работающую схему. Проверять их придётся по более поздним публикациям и официальным заявлениям компании.
Риски очевидны. Зависимость от партнёрских сервисов бронирования: смена условий работы OpenTable, Resy или SevenRooms напрямую бьёт по функциональности. Конкуренция с крупными платформами, у которых уже есть каталог, отзывы и аудитория. Доверие к финансовым данным, которое сложно вернуть, если оно потеряно. Плюс ошибка в брони разбирается пользователем вручную, а испорченный вечер стоит дороже подписки.
Как разговорный агент встраивается в путь к сделке, разбирали на примере другой платформы: AI-шопинг-ассистент TikTok и покупка в один клик. Схема та же: агент сокращает дистанцию между интересом и транзакцией.
Можно ли собрать похожего консьержа самому
Публичных деталей о стеке Zest нет. Дальше разбор подхода по компонентам, а не реверс-инжиниринг чужого продукта.
| Компонент | Что нужно | Где узкое место |
|---|---|---|
| Канал ввода | SMS через провайдера, WhatsApp Business API или Telegram-бот | Регистрация, модерация шаблонов, стоимость сообщений |
| Слой персонализации | История посещений, эмбеддинги заведений, профиль вкусов | Холодный старт и нормализация транзакций |
| Каталог | Данные о заведениях, меню, часы работы | Свежесть и полнота данных |
| Бронирование | Подключение к системам резерва | Доступ к интеграциям обычно договорной |
| Диалоговый слой | LLM с вызовом функций и поиском по меню и описаниям | Галлюцинации, стоимость токенов на длинных диалогах |
| Групповой режим | Хранение голосов, роли участников, согласия | Приватность между участниками чата |
Практический минимум, который реально собрать одному, выглядит скромнее: телеграм-бот с поиском по собственной базе заведений и меню, фильтрами по кухне, району и ограничениям в питании и ссылкой на внешнюю страницу брони. Такой бот не требует финансовых данных и работает на открытых источниках, а роль персонализации играет короткая анкета.
Самое трудное в проекте Zest - не диалог. Диалоговый слой сегодня собирается из готовых моделей и вызова функций. Трудное - данные: история трат, которая даёт сигнал с первого дня, и партнёрские интеграции с системами бронирования. Без них агент скатывается к обычному поиску по каталогу с более удобным вводом. Для аллергий и медицинских ограничений такой консьерж годится как первичный фильтр, финальную проверку состава блюд всё равно делают в ресторане.
Если хочется оценить подход на практике, начните с одного запроса на номер (212) 470-6067: сформулируйте кухню, район и повод, а затем посмотрите, попали ли варианты в ваши реальные привычки. Дальше решайте, стоит ли связывать карту ради более точного профиля.