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

Типичный сценарий: специалист открывает чат, пишет запрос, получает результат. Если результат плохой — переписывает запрос, добавляет деталей, уточняет. На простых типовых задачах это работает. На сложных, требующих понимания специфики организации, — уже нет. Большинство команд на первом этапе внедряют ИИ через интерфейсы обычных чат-ботов, подменяя ими полноценных агентов, учат сотрудников «правильно формулировать запросы», добавлять примеры. Но промпт — это лишь малая часть того, что видит большая языковая модель (LLM) в ИИ-агенте. Основным объёмом в передаваемых данных должен стать контекст организации — внутренние правила и политики, договорённости команды, спецификации и многое другое. Если контекст организации не передан в запрос к LLM, то она сформирует ответ «по умолчанию» — усреднённый по всему интернету, без учёта специфики организации. И от этого недостатка контекста никакой «волшебный» промпт не спасёт.

ОшибкаСутьПример из практики
Оптимизация промпта при игнорировании архитектуры контекстаКоманды тратят время на формулировки запроса, но не настраивают системный контекстКоманда разработчиков: агент генерирует код «не в том стиле», ревью занимает больше времени, чем написание с нуля
Отсутствие постоянного контекста и памяти агентаУ LLM нет памяти между сессиями, знания не сохраняются автоматическиРазные сотрудники получают разные ответы на однотипные запросы: один прописывает правила вручную, другой использует личный шаблон, новичок не знает регламентов
Регламент «для людей» вместо регламента «для ИИ»Инструкции написаны в мотивационном стиле, агенту нужны факты и границыАгент сгенерировал коммерческое предложение, нарушающее политики продаж и безопасности, из-за отсутствия конкретных правил в регламенте

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

Вторая ошибка — отсутствие «постоянного» контекста и памяти агента. У ИИ-ассистента на базе LLM нет памяти между рабочими сессиями, и если не выстроена витрина знаний, он каждый раз как новый сотрудник, которому забыли рассказать о нюансах работы в этой команде и организации. Это обучение новичка, бесплатное для ИИ, но дорогое для компании, делает сотрудник вручную в чате. Из практики: руководитель подразделения заметил, что при обработке однотипных клиентских запросов разные сотрудники получают от агента совершенно разные результаты. Один каждый раз вручную прописывал правила работы со скидками, другой использовал личный шаблон из текстового файла, а новичок вообще не знал о внутренних регламентах. Знания жили в головах и личных переписках, а качество ответов зависело от того, кто именно делает запрос. Решение — построить постоянный слой корпоративных знаний, к которому агент будет обращаться автоматически через механизмы RAG (поиск по базе знаний) или API, а не ждать, пока пользователь вспомнит и загрузит нужные файлы. Этот слой должен включать базовые инструкции, правила и стандарты, описание процессов и регламенты, историю ключевых решений, в которых зафиксировано, почему мы делаем именно так, а не иначе.

Третья ошибка — регламент «для людей» вместо регламента «для ИИ». Внутренние инструкции часто пишут в мотивационном стиле: «Наш отдел — важная часть компании, мы стремимся делать клиентов счастливыми…». ИИ-агенту не нужна мотивация, ему нужны факты, границы и правила. Из практики: менеджеру поручили подготовить коммерческое предложение для крупного клиента, он применил агента, подгрузив общий регламент отдела продаж. Агент не нашёл там ни слова о том, какие скидки можно давать без согласования с руководителем и какие данные клиента категорически нельзя передавать третьим лицам. В итоге он сгенерировал коммерческое предложение, нарушающее политики продаж и безопасности компании, потому что «для людей» это казалось очевидным, а для алгоритма — нет. Хорошо, что руководители остановили этот документ на согласовании. Инструкция ИИ-агента должна содержать конкретные правила и ограничения, а не общие ценности.

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