Included Health развернула Dot, AI-ассистента для навигации по медицинским, финансовым и административным вопросам. Он построен на федеративной мультиагентной архитектуре с использованием Deep Agents и LangGraph: логика разложена на главный граф Dot supergraph и отдельные суб-воркфлоу для записи к врачу, срочной помощи и поведенческого здоровья.
Главное отличие от классических чат-ботов в том, что здесь нет жёстких деревьев решений. Работают LLM: они уточняют потребность пользователя и учитывают контекст диалога. Система распознаёт потенциально экстренные ситуации с первого сообщения, ещё до того, как разговор успел развернуться в сторону записи к специалисту. При неуверенности агент приостанавливает граф, передаёт диалог живому специалисту и потом возобновляет работу с полным контекстом.
Миграция на Deep Agents заняла менее двух недель и обошлась без значимых регрессий. Это, пожалуй, единственные конкретные цифры, которые есть в публичном описании кейса. Ниже разбор архитектуры и честная оценка того, что осталось за кадром.
Что такое Dot и зачем Included Health понадобился AI-ассистент
Dot закрывает три группы вопросов в одном интерфейсе: медицинские, финансовые и административные. К какому врачу записаться, что покрывает страховка, как разобраться со счётом. Именно эта тройка задач и определяет архитектуру, а не наоборот.
Формулировки вроде «болит бок, что делать» или «пришёл счёт, не понимаю, должны ли мы это платить» не содержат достаточных признаков для маршрутизации. Агенту приходится самому выяснять, что нужно пользователю: запись к врачу, разбор покрытия или срочная помощь.
Чем Dot отличается от дерева решений
Дерево решений ведёт пользователя по заранее прописанным ветвям. Первый вопрос, второй, третий, каждый следующий зависит от предыдущего ответа. Схема предсказуема, её легко тестировать и объяснять. Беда в том, что живой человек редко укладывается в ветки.
Дерево в такой ситуации либо задаёт лишние вопросы, либо уводит не туда. LLM-агент уточняет потребность и держит контекст: одна и та же реплика в начале разговора и на десятом ходу означает разное, и модель это учитывает.
Отдельное требование, которое редко встречается в чат-ботах, это распознавание потенциально экстренных ситуаций с первого сообщения. Если человек пишет что-то похожее на острый приступ, сценарий должен переключиться немедленно, а не после трёх уточняющих вопросов. Порог срабатывания здесь смещён в сторону осторожности: ложное срабатывание дешевле пропуска.
Реплики выше - иллюстрация логики, а не воспроизведение реальных диалогов Dot.
Федеративная мультиагентная архитектура: Dot supergraph и суб-воркфлоу
Федеративность означает разделение ответственности. Один универсальный агент, который умеет всё, плохо поддаётся тестированию и развитию: правка в сценарии записи к врачу ломает поведение в сценарии срочной помощи. Вместо этого архитектура разложена на уровни.
Как Dot supergraph координирует суб-воркфлоу
Dot supergraph принимает запрос пользователя и решает, в какой суб-воркфлоу его направить. В описании кейса перечислены три суб-воркфлоу: запись к врачу, срочная помощь и поведенческое здоровье. Запрос про запись уходит в один, сигнал о возможной экстренной ситуации в другой.
Практический смысл такой схемы в изоляции изменений. Команда может переписать логику записи к врачу, не трогая поведенческое здоровье, и наоборот. Верхний граф при этом остаётся тонким: он маршрутизирует и держит общее состояние диалога, а отраслевых деталей в нём нет.
Детали реализации в источнике не раскрыты: конкретные узлы графа, модели маршрутизации, схемы данных. Об этом прямо не сказано, поэтому остаётся только общий принцип.
Собственную архитектуру агента проще проектировать, когда есть с чем сравнить: оркестрация LLM, память, инструменты, обработка ошибок и метрики latency, cost и reliability. Разбор таких решений с кодом на Python и чек-листом выбора между своей разработкой и готовым фреймворком есть в материале о сборке AI-агента с нуля.
Общий реестр навыков с прогрессивным раскрытием
В системе есть общий реестр навыков (skills), к которому обращаются агенты. Навык описывает, как выполнить конкретное действие: оформить запись, собрать данные о покрытии, проверить статус обращения.
Прогрессивное раскрытие означает, что агент не получает все инструкции сразу. Он подгружает нужные по мере необходимости. Причина простая: если запихнуть в контекст описания десятков навыков, модель начнёт путаться и потратит окно на то, что не относится к текущему шагу. Прогрессивное раскрытие сокращает контекст и снижает вероятность перепутать инструменты.
Тот же принцип работает в базах знаний для агентных команд: агенту выдаётся только релевантный срез, а не весь корпус документации сразу. Форматы хранения навыков в описании кейса не указаны, поэтому конкретики здесь нет.
Deep Agents и LangGraph: что за что отвечает
LangGraph отвечает за построение графов агентов: состояние, узлы, переходы, контроль выполнения. Deep Agents это платформа, на которую Included Health перевела Dot менее чем за две недели без значимых регрессий.
Уровни стоит разграничить. Продуктовая логика живёт в суб-воркфлоу и реестре навыков. LangGraph описывает, как эти куски соединяются и выполняются. Deep Agents задаёт слой исполнения и обвязку вокруг агентов.
Схема не уникальна для медицины. LangChain выпустила Deep Life Sci, открытый агентный ассистент для клинических и лабораторных исследователей, тоже на харнессе Deep Agents, с песочницами LangSmith и сотнями субагентов. Другой домен, та же идея изоляции задач между агентами. Разбор в статье о Deep Life Sci от LangChain.
Почему миграция заняла менее двух недель
Процесс миграции в источнике не описан: ни этапов, ни состава команды, ни списка проблем. Единственные факты, срок менее двух недель и отсутствие значимых регрессий.
Правдоподобное объяснение скорости в том, что к моменту перехода логика уже лежала на supergraph и суб-воркфлоу. Это версия, а не заявление команды: причину в описании кейса не назвали.
Разделение на уровни снижает стоимость смены платформы. Когда сценарий записи к врачу и сценарий срочной помощи существуют отдельно, платформенный слой меняется в одном месте, а не расползается по всей кодовой базе.
Human-in-the-loop: как агент передаёт диалог человеку
При неуверенности агент останавливается и передаёт диалог живому специалисту. Пользователь не остаётся в тупике с ботом, который не понимает, что происходит. Для медицинской навигации это базовое требование, потому что цена ошибки высока, а не все ситуации разбираются автоматически.
Приостановка графа и возобновление с полным контекстом
Механика описана коротко: граф приостанавливается, диалог уходит человеку, затем работа возобновляется с полным контекстом. Состояние сохраняется, история не теряется.
Эффект для пользователя важнее технических деталей. Он не начинает разговор сначала и не повторяет то, что уже рассказал. Специалист видит тот же контекст, который был у агента, включая предыдущие уточнения и выбранный маршрут.
Логика близка к принципу «ИИ предлагает, человек утверждает, программа исполняет»: агент готовит варианты, решение остаётся за человеком. Как такое разделение ролей выглядит в виде формального процесса, разобрано в материале о методологии Agent-Ops 0.4.0. Деталей API приостановки LangGraph в описании кейса нет, поэтому дальше не углубляемся.
Наблюдаемость и клинический контроль: LangSmith annotation queues и evals
В кейсе названы два инструмента: LangSmith annotation queues и мультитёрновые симуляционные evals. Первый нужен для наблюдаемости и клинического контроля, второй для оценки поведения агента.
Annotation queues позволяют разметить трейсы и привлечь к разбору людей, в том числе с клинической экспертизой. Это способ поймать проблемные ответы в продакшене, а не ждать жалоб от пользователей.
Зачем мультитёрновые симуляционные evals
Навигация по медицине почти никогда не укладывается в один обмен сообщениями. Пользователь уточняет, меняет тему, возвращается назад. Проверять отдельный ответ бессмысленно: он может быть корректным сам по себе и ошибочным в контексте разговора.
Иллюстративный сценарий: человек жалуется на симптом, затем уточняет детали страховки, затем просит записать к врачу. Eval должен пройти по всей цепочке и проверить, что агент удержал контекст, не потерял ограничения и правильно выбрал суб-воркфлоу. Пример гипотетический, он показывает принцип, а не сценарий из тестов Included Health.
Метрик качества в описании кейса нет: ни точности, ни latency, ни стоимости, ни доли эскалаций. Поэтому судить о том, насколько хорошо система работает, по опубликованным данным нельзя.
Что можно перенести в свои проекты, а что специфично для медицины
Кейс полезен как архитектурный референс. Часть решений не зависит от медицины и переносится почти без изменений.
Какие паттерны переносятся в другие домены
- Разделение на верхний граф и суб-воркфлоу. Координатор маршрутизирует, специализированные воркфлоу делают работу.
- Общий реестр навыков с прогрессивным раскрытием: агент получает описания инструментов по мере необходимости, а не все сразу.
- Приостановка графа для human-in-the-loop. Диалог уходит человеку и возвращается с сохранённым контекстом.
- Мультитёрновые evals вместо проверки одиночных ответов.
Домены, где это окупается: клиентская поддержка с длинными сессиями, финансовый онбординг с несколькими продуктами, юридические консультации с ветвлением на типы вопросов. Общее свойство таких задач в том, что запрос плохо формализуется с первого сообщения, а маршрутизация определяет качество ответа.
Проектирование такой схемы начинается с архитектурной модели, а не с промпта. Как раскладывать систему на уровни и контракты, обсуждается в статье о проектировании вместо кода.
Что остаётся специфичным для медицины
Три элемента плохо переносятся в домены с низкой ценой ошибки:
- Распознавание потенциально экстренных ситуаций с первого сообщения. Здесь пороги смещают в сторону ложных срабатываний.
- Клинический контроль через annotation queues с участием людей с медицинской экспертизой.
- Требования к безопасности медицинских данных. В источнике не раскрыто, как именно они выполняются, поэтому копировать нечего.
В поддержке интернет-магазина или внутреннем ассистенте по документации эти требования можно ослабить или заменить. Эскалация человеку останется, но критерии будут мягче: недовольство пользователя, нестандартный запрос, спорный возврат.
Ограничения кейса и открытые вопросы
Все факты в этом разборе опираются на описание кейса. Независимых подтверждений, официальных публикаций с цифрами или замеров в предоставленных материалах нет.
Какие метрики и детали не раскрыты
- Нет метрик качества ответов, latency, стоимости и доли эскалаций на человека.
- Не указано, какие LLM используются и как их выбирали.
- Не раскрыты детали суб-воркфлоу, структура реестра навыков и механика human-in-the-loop.
- Не описано, как обеспечивается безопасность медицинских данных.
Единственные конкретные числа: миграция менее двух недель и отсутствие значимых регрессий. Этого достаточно, чтобы говорить о зрелости платформенного слоя, и недостаточно для выводов о надёжности всей системы в продакшене.
Как читателю проверять подобные кейсы
Пять вопросов, которые стоит задать к любому архитектурному разбору:
- Какие метрики раскрыты: качество, latency, стоимость, доля автоматических ответов?
- Есть ли данные о том, как часто диалог уходит человеку и что происходит после передачи?
- Как тестировались многошаговые сценарии, а не отдельные ответы?
- Что известно о безопасности данных и разграничении доступа?
- Указано ли, какие модели используются и на каких данных они работают?
Если ответов нет, материал остаётся описанием паттернов. Паттерны переносятся, а цифры всё равно придётся собирать на своём проекте. Архитектурная схема Dot даёт структуру для такого проектирования, но не готовый рецепт и не доказательство надёжности.