AI-first продукт начинается не с выбора модели и не с красивой инструкции для модели. Он начинается с вопроса: где в системе рождается контекст, кто имеет право его менять и что произойдёт, если модель, база данных или внешний сервис в нужный момент не ответят.
Я всё чаще смотрю на такие продукты не как на «ботов», а как на рабочие контуры. Внутри есть входные каналы, память, правила, инструменты, журналы, ограничения доступа и люди, которые принимают решения там, где автоматике нельзя доверять полностью. LLM в этой схеме важна, но она не является всей системой. Это функция: на вход получает текстовый контекст, на выходе возвращает текстовый результат. Главная инженерная работа — собрать правильный контекст и не дать ему превратиться в случайную свалку.
Поэтому архитектура AI-first продукта для меня — это не модная схема из прямоугольников. Это договор о границах: какие данные входят, какие действия разрешены, где нужен человек, как проверяется результат и как система деградирует при отказах.
Почему AI-first нельзя строить как один большой чат
Самая частая ошибка — считать, что продукт уже стал AI-first, если в нём появился экран с перепиской и вызов LLM API. Такой прототип может быть полезен для проверки идеи, но в эксплуатации быстро появляются одни и те же вопросы.
Откуда модель знает актуальные данные? Можно ли ей показывать внутренние документы? Кто разрешил ей отправить письмо или изменить запись в CRM? Что будет, если она уверенно ошиблась? Как понять, почему вчера она приняла одно решение, а сегодня другое?
Если на эти вопросы нет архитектурных ответов, продукт остаётся демонстрацией. В реальной работе ему не хватает опор: контекста, границ, наблюдаемости и аварийных сценариев.
Я разделяю два уровня. Первый — способность модели рассуждать и генерировать текст. Второй — способность продукта управлять контекстом, действиями и последствиями. Второй уровень важнее для бизнеса. Именно поэтому контекст-инжиниринг важнее выбора модели: качество ответа часто определяется не тем, какая модель подключена, а тем, что именно она получила на вход.
Базовые слои AI-first продукта
Удобно думать о системе как о нескольких слоях, через которые проходит задача. На каждом слое контекст либо обогащается, либо фильтруется, либо превращается в действие.
Слой входа: каналы и события
Снаружи продукт получает события: сообщение пользователя, заявку с сайта, запись из CRM, задачу из очереди, запуск по расписанию. Для модели всё это в итоге станет текстом, но до модели событие нужно привести к нормальному внутреннему формату.
На этом слое важно не смешивать протокол канала и смысл задачи. Telegram, веб-форма, почта и CRM могут давать разные технические payload, но внутри система должна получить единое описание: кто инициатор, какой объект затронут, какой канал, какое время, какие права у источника, нужен ли ответ наружу.
Если этот слой пропустить, дальше начинается хаос: где-то агент получает имя клиента, где-то только текст сообщения, где-то теряется источник, где-то невозможно отличить внутреннюю задачу от внешней заявки.
Слой сессии: история и текущий рабочий контур
Сессия отвечает за ближайшую память: что уже обсуждали, какие решения приняты, какие артефакты созданы, какие действия выполнялись. Это не вечная память и не база знаний. Это рабочий журнал конкретного разговора или процесса.
Граница здесь простая: сессия не должна становиться единственным источником правды. Если решение важно завтра, оно должно уйти в устойчивый артефакт: документ, задачу, запись в базе, changelog или другой проверяемый объект. Иначе продукт начинает жить на случайной истории чата, а это плохая основа для автоматизации.
Слой агента: роль, инструкции и ограничения
Агент — это не «модель с именем». Это роль в системе. У него есть зона ответственности, стиль работы, доступные инструменты, запреты и формат результата. Один агент может разбирать входящие заявки, другой — готовить черновики, третий — проверять изменения, четвёртый — следить за регламентом.
Здесь важно разделять системную роль и техническое выполнение. Если нужен исполнитель с ограниченными правами, он не должен наследовать доступ архитектора или администратора. Если нужен проверяющий, он не должен одновременно быть автором спорного изменения. Иначе вместо команды получается один всемогущий процесс, которому сложно доверять.
Я подробно разбирал это в статье про выбор между AI-агентом и обычным скриптом. Архитектурно агент нужен там, где есть вариативность, контекст и ответственность за решение. Для повторяемого действия без рассуждения часто лучше обычный скрипт.
Слой памяти и артефактов
Долгосрочная память AI-first продукта — это не «пусть модель всё помнит». Модель не хранит вашу операционную истину. Её нужно хранить в понятных местах: файлах, базе данных, карточках знаний, отчётах, задачах, журналах изменений.
Артефакт должен отвечать на три вопроса: кто его создал, из каких источников, как его проверить. Если этого нет, он превращается в красивый текст без доказательной силы. В AI-first продукте такая «память» опасна: она уверенно подмешивается в следующие решения и размножает ошибку.
Поэтому я предпочитаю явные артефакты с жизненным циклом. Черновик, проверено, применено, устарело, отклонено — простые статусы уже сильно снижают риск. Система должна знать, что можно использовать как факт, а что является только гипотезой.
Слой инструментов и действий
Инструменты — место, где текст превращается в действие: прочитать файл, создать задачу, запросить CRM, собрать отчёт, изменить страницу, отправить сообщение. Это самый опасный слой, потому что ошибка модели здесь уже влияет на внешний мир.
Граница должна быть жёсткой. Чтение и запись — разные права. Черновик и публикация — разные операции. Внутренний отчёт и сообщение клиенту — разные уровни риска. Если инструмент может менять данные, ему нужны проверки, журналирование и иногда явное подтверждение человека.
Я не люблю архитектуры, где один агент имеет доступ «ко всему, потому что так удобнее». Это удобно ровно до первого инцидента. Нормальная система даёт агенту минимально достаточные права и понятный путь эскалации.
Слой модели и маршрутизации
LLM — внутреннее ядро, но не единственный центр принятия решений. В хорошем AI-first продукте модель можно заменить, а продукт не развалится. Для этого вокруг неё должны быть стабильные интерфейсы: формат входа, формат выхода, валидаторы, обработка ошибок, журнал результата.
Маршрутизация между моделями нужна не всегда. Иногда достаточно одной модели и хорошего контроля контекста. Но если задачи разные, появляются основания разделять маршруты: быстрые ответы, сложная аналитика, работа с кодом, чувствительные данные, резерв при недоступности провайдера. Главное — не превращать маршрутизацию в магию. У каждого маршрута должна быть причина и проверяемое поведение.
Границы доверия
AI-first продукт почти всегда работает на стыке нескольких зон доверия. Есть публичный пользователь, внутренний оператор, база клиентов, коммерческие документы, технические доступы, внешние API. Ошибка начинается там, где эти зоны смешиваются.
Я обычно разделяю минимум четыре границы.
Первая — входная. Внешний пользователь не должен напрямую влиять на системные инструкции, права инструментов и служебную память. Его сообщение — это данные, а не команда для всей системы.
Вторая — контекстная. Не каждый агент должен видеть все документы. Если задача касается ответа клиенту, ей может быть достаточно карточки обращения и регламента. Доступ к финансовым данным, внутренним заметкам или ключам не должен появляться «на всякий случай».
Третья — операционная. Есть действия, которые можно выполнять автоматически, и есть действия, которые требуют подтверждения: отправка наружу, изменение продакшн-данных, списание денег, массовая рассылка, удаление информации.
Четвёртая — доказательная. Ответ модели сам по себе не является фактом. Фактом становится проверяемая запись: ссылка на источник, результат теста, лог операции, подтверждение владельца процесса. Поэтому для серьёзных сценариев нужны журналы и проверка происхождения данных.
Эта логика особенно важна для публичных и внутренних контуров. Подробно близкую проблему я разбирал в материале про безопасность AI-агентов и сессий: агент для внешнего чата и агент для внутренней автоматизации не должны жить с одинаковыми правами.
Типовые ошибки в архитектуре AI-first продукта
Первая ошибка — начинать с модели. Команда спорит, какую LLM выбрать, но не описывает источники данных, регламенты, права и проверки. В итоге даже сильная модель получает слабый контекст.
Вторая ошибка — хранить знания только в истории чата. Это удобно на старте, но плохо работает в команде и не переживает смену сессии, агента или интерфейса. Важные решения нужно выносить в устойчивые артефакты.
Третья ошибка — давать агенту слишком много прав. Если один процесс может читать всё, писать всё и отправлять всё наружу, это не автономность, а отсутствие границ. Автономность должна расти ступенчато: сначала анализ, потом черновик, потом действие с подтверждением, потом ограниченное автоматическое действие.
Четвёртая ошибка — не проектировать отказы. Внешняя модель может быть недоступна. CRM может вернуть неполные данные. Поиск может не найти источник. Валидатор может отклонить результат. Если для этих ситуаций нет сценария, система либо молча ошибается, либо зависает, либо делает лишнее.
Пятая ошибка — считать красивый ответ доказательством. LLM умеет писать убедительно. Поэтому архитектура должна отделять «модель сказала» от «система проверила».
Отказоустойчивость: что должно быть заложено заранее
Отказоустойчивость в AI-first продукте — это не только резервная модель. Это поведение всей системы, когда один из слоёв не смог выполнить работу.
Если недоступен источник данных, система должна явно пропустить этот источник, пометить неполноту контекста и не выдавать результат как окончательный. Если нет нужного конфига, лучше понятная ошибка, чем попытка угадать. Если внешний сервис отвечает нестабильно, нужны таймауты, повторы с ограничением и запись причины отказа.
Для действий с последствиями нужен guard от массовых ложных срабатываний. Например, если агент должен обновлять карточки, он не должен за один проход менять сотни объектов без отдельного лимита и отчёта. Если система публикует контент, она должна сначала проверять целевой файл, сборку, ссылки и отсутствие служебных пометок. Если отправляет сообщения, нужен отдельный слой подтверждения или хотя бы строгий список ситуаций, где отправка разрешена автоматически.
Отдельно я закладываю идемпотентность. Повторный запуск не должен дублировать задачу, повторно отправлять одно и то же сообщение или ещё раз применять уже применённое изменение. Для этого нужны ключи операций, статусы, журналы и проверка текущего состояния перед действием.
Ещё один важный принцип — деградация без маскировки. Если часть системы недоступна, продукт может выдать ограниченный результат, но должен честно знать, что он ограниченный. Пользователю не всегда нужно видеть техническую кухню, но внутри журнала причина должна быть зафиксирована.
Практический сценарий проектирования
Когда ко мне приходит задача «сделать AI-first продукт», я не начинаю с текста запроса к модели. Я прохожу по контуру будущей системы.
1. Описать рабочие события
Сначала фиксирую, что запускает систему: сообщение, заявка, cron, webhook, изменение в CRM, ручная команда. Для каждого события отмечаю инициатора, канал, объект, ожидаемый результат и уровень риска.
На этом этапе уже видно, где нужен агент, а где достаточно скрипта. Видно, какие события должны только создавать черновик, а какие могут завершаться автоматическим действием.
2. Разложить контекст на статический, динамический и текущий
Статический контекст — роль агента, правила, ограничения, формат ответа. Динамический — данные из систем, память, артефакты, история. Текущий — конкретный запрос или событие.
Если эти части смешаны, систему трудно поддерживать. Любое изменение текущего запроса начинает ломать правила, доступы и бизнес-логику. Когда слои разделены, можно менять регламент агента, не переписывая интеграции.
3. Провести границы доступа
Я выписываю, что агенту можно читать, что можно создавать, что можно менять, что можно отправлять наружу и где нужен человек. Это скучная часть, но без неё AI-first продукт быстро становится опасным.
Особенно внимательно смотрю на массовые операции, персональные данные, финансы, клиентские коммуникации и продакшн-среду. Там должны быть отдельные разрешения и понятные остановки.
4. Спроектировать артефакты
Нужно заранее решить, что система оставляет после работы: отчёт, задачу, комментарий, запись в базе, файл, журнал. Хороший артефакт помогает следующему шагу. Плохой артефакт просто занимает место и загрязняет контекст.
Я предпочитаю, чтобы артефакты были короткими, проверяемыми и имели статус. Тогда их можно безопасно подмешивать в будущие задачи.
5. Добавить проверки и аварийные маршруты
Перед запуском нужно пройти по неприятным вопросам. Что если модель вернула пустой ответ? Что если источник недоступен? Что если данные противоречат друг другу? Что если действие уже было выполнено? Что если пользователь просит то, что агенту запрещено?
Ответы на эти вопросы должны быть частью архитектуры, а не реакцией после первого сбоя.
Практический чек-лист
Перед тем как считать AI-first продукт готовым к разработке, я проверяю его по такому списку:
- входные события описаны единым внутренним форматом;
- у каждого агента есть роль, зона ответственности и ограничения;
- статический, динамический и текущий контекст разделены;
- известны источники данных и правила их актуальности;
- важные решения сохраняются как проверяемые артефакты;
- чтение, запись и внешняя отправка разделены по правам;
- опасные действия требуют подтверждения или имеют жёсткие лимиты;
- все внешние сервисы имеют сценарий таймаута, повтора или пропуска;
- повторный запуск не создаёт дублей и не применяет действие второй раз;
- результат можно объяснить через источник, журнал или тест;
- есть режим ограниченного ответа, если часть контекста недоступна;
- владелец процесса понимает, где заканчивается автоматика и начинается его ответственность.
Если большинство пунктов не закрыто, продукт ещё рано называть AI-first. Это может быть хороший прототип, полезный внутренний инструмент или первая версия автоматизации. Но архитектура начинается там, где у системы появляются границы, память, проверяемые действия и нормальное поведение при сбоях.
Для сложных внедрений я обычно начинаю именно с проектирования AI-архитектуры, а не с разработки интерфейса. Когда уже понятны слои, права, контекст и отказы, дальше можно переходить к AI First трансформации без ощущения, что каждый новый сценарий придётся собирать заново.