Привет, я работаю аналитиком в Cloud.ru. По работе я много смотрю на ИИ-агентов и пытаюсь понять, что интересного могут предложить разработчики. Решила собрать кейсы с разным уровнем зрелости: какие-то из них уже работают в проде, а какие-то еще находятся на этапе теста или внутреннего использования.

Ниже — четыре примера, за которыми интересно следить. 

Разберем, как они устроены и какие идеи можно забрать в свои продукты или внутренние системы.

Pixel Societies

Pixel Societies выглядит как серия «Повесь диджея» из четвертого сезона «Черного зеркала», в которой карманный тиндер помогал людям найти идеальную пару. 

И теперь такое приложение есть в реальности. Правда, пока в тестовом режиме. Идея такая: вместо того чтобы самому свайпать, переписываться и пытаться понять, есть ли у вас с человеком хоть какая-то химия, вы отправляете в симуляцию своего ИИ-двойника.

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

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

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

Второй — работа с Memory Stream. ИИ-агент ведет много симуляций диалогов параллельно, поэтому технически тут важно, чтобы архив воспоминаний работал без сбоев и четко разделял, кому и что он уже говорил, не путал контексты и информацию о разных собеседниках.

То, как именно устроена память внутри, команда публично не раскрывала. Однако можно предположить, что принцип похож на стэнфордскую работу 2023 года о генеративных агентах, а именно на Memory Stream. 

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

При «общении» из памяти извлекаются наиболее релевантные записи с учетом их свежести, значимости и близости к текущему контексту. Это помогает агенту не держать весь архив диалогов в голове, а каждый раз вытаскивать только то, что важно прямо сейчас. Особенно это критично в Pixel Societies, потому что агент ведет параллельные симуляции с разными людьми одновременно. Если их четко не разделить, то он быстро начнет путать, кому что говорил, кто чем интересуется, о чем была предыдущая реплика.

Скрин выше — это открытый мир. Когда я зашла в первый раз, то попала, видимо, в тестовую комнату: со мной в ней сидели всего четыре агента, в том числе создатель. 

А агенты неких Алекса и Юри вели не очень интересный диалог.

Конкретно в дейтинг-сфере проект спорный. ИИ-агент все-таки не Роза Сябитова, он не сможет быстро считать мэтч и отправить вас в загс. Разве что поможет отсеять совсем уж неподходящих кандидатов.

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

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

Как архитектурная идея — проект прикольный, я с удовольствием зарегистрировалась и изучила фичи. 

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

Notable AI Agents

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

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

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

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

Notable работает поверх EHR-систем или электронных медкарт, которые уже есть в клинике. При этом связь двусторонняя: агент не только читает данные пациента, но и обновляет их в реальном времени. Под капотом у Notable не одна модель: платформа сама выбирает LLM под задачу, в зависимости от того, где нужна скорость, а где точность.

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

Но медицина хорошо показывает и обратную сторону таких помощников. Тут выше цена ошибки. Если ИИ перепутает данные пациента, неверно обновит документ или не передаст важную информацию врачу или страховой, кто знает, к чему приведет такой фейл.

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

Но не всё агент делает сам. Такую рутину, как записать пациента, напомнить о записи, обновить статус, система берет на себя. Там, где выше риск (медицинские данные, финансы, нестандартная ситуация), останавливается и передает живому сотруднику. Срабатывает human-in-the-loop.

Еще, кстати, важен след действий: откуда агент взял данные, что проверил и почему перешел (или не перешел) к следующему шагу. Поэтому каждый шаг должен логироваться: пользовательский запрос, подзапросы к RAG, параметры поиска, найденные документы с метаданными и идентификаторами чанка, а также финальное действие агента. Это помогает и объяснить решение (показать, на какие документы он опирался), и навесить политики, например потребовать человеческий апрув перед конкретным действием (например, запись).

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

Air Traffic Control Simulator

Air Traffic Control — агент, который помогает пилотам тренировать переговоры с авиадиспетчером. Это учебный сценарий: пилот общается с агентом голосом или текстом, получает инструкции и отрабатывает их. Автор проекта начинал с простого кастомного GPT-диалога. Он вел себя как диспетчер и помогал студенту-пилоту практиковать радиосвязь.

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

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

У такого поведения есть причина, ведь модель плохо удерживает детали из середины длинного контекста: начало и конец запоминает хорошо, а все, что между, может забыть. Это известный эффект, который исследователи называют lost-in-the-middle (подробнее можно почитать в недавней статье моей коллеги про постановку ТЗ). Для диспетчерского симулятора это критично: если агент забыл, какая полоса активна или какой позывной у самолета, он продолжит уверенно давать инструкции, вот только неправильные.

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

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

Обычные реляционные базы данных для этого не приспособлены: поиск пути между узлами потребовал бы громоздких запросов вместо одного сравнительно простого. Граф же хранится в Neo4j — графовой базе данных. Когда агенту нужен маршрут, он делает запрос к базе: «Дай путь от стоянки 12 до полосы 07» — и получает конкретную последовательность рулежных дорожек. Знание об аэропорте живет не в промпте, а в структуре данных, которую невозможно забыть или исказить.

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

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

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

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

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

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

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

Gamma app

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

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

Покажу на примере. Пользователь сразу просит конечный материал: презентацию, документ, страницу сайта или пост:

И получает результат: три концепции, с которыми уже можно работать дальше — менять стиль, цвета, добавлять или убирать детали. 

А вот так выглядит редактура презентации, где можно работать с каждым слайдом по отдельности.

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

Но тут важно вот что: нет нормального ТЗ — результат… сами понимаете какой. Так что тестить это надо на очень конкретной и достаточно подробно описанной задаче. 

Пример промпта:

«Собери презентацию на 8 слайдов для внутренней встречи продуктовой команды на тему „Как ИИ-агенты могут помогать в поддержке пользователей“.

Аудитория: продакты, тимлиды и руководители поддержки, которые уже слышали про ИИ-агентов, но пока не понимают, где их реально применять.

Цель презентации: показать не хайп, а практические сценарии внедрения — где агент может снять рутину, где нужен контроль человека, какие риски важно учесть и с чего начать пилот.

Структура:

Почему поддержка — хорошая зона для ИИ-агентов.

Чем ИИ-агент отличается от обычного чат-бота.

3–4 сценария применения: разбор обращений, поиск ответа в базе знаний, подготовка черновика ответа, маршрутизация сложных кейсов.

Роль человека: где агент помогает, но не принимает решение сам.

Основные риски: ошибки, чувствительные данные, токсичные ответы, потеря контекста.

Что нужно подготовить до пилота: базу знаний, доступы, правила эскалации, метрики.

Как оценивать результат: по скорости ответа, доле автоматизированных обращений, качеству ответов, CSAT.

Вывод: начинать лучше с узкого сценария и прозрачного контроля.

Стиль: экспертный, но живой. Без канцелярита и рекламного тона. Используй короткие тезисы, понятные примеры и визуальные блоки. Дизайн — современный, чистый, с акцентами, без перегруза текстом».

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

Я, кстати, Gamma встречаю постоянно в чате с коллегами. Это и сподвигло меня на поиск интересных агентов в самых разных областях, которые для меня, например, вообще нерелевантны. А у вас есть примеры? Интересны любые странные, нишевые или реально полезные кейсы для любых сфер.