Я бизнес‑архитектор, много лет работающий на стыке управления бизнес‑процессами и корпоративной архитектурой. Последние годы применяю LLM и AI‑агентов в своей практике.

В этой статье я разобрал 9 типовых ошибок управления контекстом, которые совершают команды при внедрении AI‑агентов в бизнес‑процессы, и показал, как превратить AI‑агента из дорогой игрушки в предсказуемый рабочий инструмент.

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

Первая реакция: «Модель слабая, надо перейти на более дорогую».

Но в подавляющем большинстве случаев проблема не в «силе» модели, а в том, что архитектура работы с контекстом в компании не выстроена.

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

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

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

Но промпт — это лишь малая часть того, что видит большая языковая модель (LLM) в AI‑агенте.

Основным объемом в передаваемых данных должен стать контекст организации — внутренние правила и политики, договорённости команды, спецификации и многое другое.

Если контекст организации не передан в запрос к LLM, то она сформирует ответ «по умолчанию» — усреднённый по всему интернету, без учёта специфики организации.

И от этого недостатка контекста никакой «волшебный» промпт не спасёт, поэтому нужно начинать работать с контекстом.

1. Оптимизация промпта при игнорировании архитектуры контекста

Команды тратят время на оттачивание формулировок запроса, добавляя сложные языковые конструкции, но часто игнорируют то, что AI‑агент должен увидеть еще до начала диалога.

Из практики: Одна команда разработчиков жаловалась, что AI‑агент генерирует код «не в том стиле», и на ревью уходит больше времени, чем на написание кода с нуля.

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

Как надо:

Поймите, что качество ответа LLM в AI‑агенте — это во многом функция системного контекста, а не длины и качества вашего промпта.

Самый простой способ улучшения ответа LLM — не «точнее написать в чате», а навести порядок в постоянных файлах репозитория, которые подгружаются при использовании AI‑агента.

2. Отсутствие «постоянного» контекста и памяти агента

У AI‑ассистента на базе LLM нет памяти между рабочими сессиями, и если мы не выстроили для агента витрину знаний, он каждый раз как новый сотрудник, которому забыли рассказать о нюансах работы в этой команде и организации.

И это обучение новичка, которое каждый раз бесплатно для AI, но достаточно дорого для компании, делает сотрудник вручную в чате.

Из практики: Руководитель подразделения заметил, что при обработке однотипных клиентских запросов разные сотрудники получают от AI‑агента совершенно разные результаты.

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

Знания жили в головах и личных переписках, а качество ответов зависело от того, кто именно делает запрос к AI‑агенту.

Как надо:

Постройте постоянный слой корпоративных знаний, к которому агент будет обращаться автоматически через механизмы RAG (поиск по базе знаний) или API, а не ждать, пока пользователь вспомнит и загрузит нужные файлы.

Этот слой должен включать:

• базовые инструкции;

• правила и стандарты;

• описание процессов и регламенты;

• историю ключевых решений, в которых зафиксировано почему мы делаем именно так, а не иначе.

3. Регламент «для людей» вместо регламента «для ИИ»

Мы привыкли писать внутренние инструкции в мотивационном стиле: «Наш отдел — важная часть компании, мы стремимся делать клиентов счастливыми…».

ИИ‑агенту не нужна мотивация, ему нужны факты, границы и правила.

Из практики: Менеджеру поручили подготовить коммерческое предложение для крупного клиента, он применил AI‑агента, подгрузив в него общий регламент отдела продаж.

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

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

И очень хорошо, что руководители остановили этот документ на согласовании.

Как надо:

Инструкция AI‑агента для работы в процессе должна отвечать на конкретные вопросы:

• какова цель процесса;

• какие входы и выходы;

• что входит в зону ответственности, а что нет;

• с какими подразделениями есть взаимодействие;

• правила, что нельзя нарушать и почему;

• когда и куда нужно эскалировать нестандартные вопросы.

4. Ручная загрузка данных вместо архитектуры RAG

Стремясь помочь AI‑агенту, сотрудники пытаются скармливать ему в контекст чата весь годовой отчет, устав компании и десяток старых презентаций по теме.

Итог: 30 000 слов, из которых к теме относятся менее 2 000.

Модель теряет фокус на этом информационном шуме (эффект Lost in the Middle).

Из практики: Аналитик загрузил в AI‑агента всю 100-страничную базу знаний подразделения, чтобы составить краткую справку по одному продукту.

Модель успешно нашла нужную информацию, но из‑за потери внимания в середине длинного текста она проигнорировала критическое ограничение, и предложила решение, противоречащее текущим правилам компании.

Как надо:

Вместо того чтобы выкладывать все файлы в контекстное окно, постройте архитектуру Retrieval‑Augmented Generation (RAG).

Собирайте контекст точечно под тип задачи через семантический поиск по векторной базе данных.

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

Используйте краткие выжимки, ссылки на конкретные страницы или задавайте AI‑агенту вопрос «найди нужное в базе», вместо того чтобы заставлять его читать всё содержимое целиком.

5. Игнорирование «переполнения контекста» в длинных диалогах

В длинном диалоге модель начинает «забывать» информацию, при этом модель не «забывает» информацию намеренно, просто она начинает использовать её с меньшим весом, если она находится в середине переполненного окна чата.

Из практики: Маркетолог три часа обсуждал с AI‑агентом структуру большой рекламной кампании.

В какой‑то момент времени AI‑агент начал предлагать идеи, которые маркетолог уже отверг в самом первом сообщении диалога.

Напоминание в чате о том, что «мы это уже обсуждали, смотри начало» не помогало: внимание модели было перегружено десятками промежуточных идей и черновиков.

Как надо:

Не пытайтесь решить всё в одном бесконечном чате на уровне пользователя.

На уровне инженерии внедрите механизмы саммаризации (сжатия) истории диалога и векторную память.

Разбивайте длинную задачу на несколько коротких сессий (например, «сбор идей», «структурирование документа», «написание текста»).

В начале нового чата давайте AI‑агенту не всю историю переписки, а короткую выжимку (5–10 строк) того, что уже решено, и актуальное задание.

6. Один универсальный документ для всех ролей

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

Полезное для одной роли становится информационным шумом для другой.

Из практики:

Команда создала единый документ правил и требований для запуска нового продукта.

В результате его применения маркетолога раздражали сухие юридические формулировки AI‑агента, юрист не мог найти в его ответах юридические нюансы по авторскому праву, а руководитель не видел нужные ему связи с бизнес‑метриками.

Каждый дописывал недостающие уточнения в своем чате с AI‑агентом.

Как надо:

Вместо ручного набора документов внедрите ролевую модель на основе корпоративных каталогов.

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

• «Бизнес‑цели» (для руководителя);

• «Юридические ограничения» (для юриста);

• «Маркетинговые требования» (для маркетолога).

Добавьте общий документ‑заголовок с перечнем пользователей кто и когда, должен использовать документы, и что именно здесь описано для AI‑агента.

7. Оценка результатов «на глаз» вместо метрик

«Кажется, AI‑агент c новой LLM стал отвечать лучше», «Мне нравится ответы этой новой нейросети».

Без цифр внедрение AI превращается в фанатизм, а решения о покупке дорогих подписок на новые LLM принимаются по активности самого громкого участника совещания.

Из практики:

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

Однако, замер метрик показал, что время на выполнение задачи выросло, а количество правок конечного результата осталось на том же уровне.

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

Как надо:

Внедрите несколько базовых метрик:

• время на задачу;

• количество итераций/правок;

• стоимость использования AI‑агента;

• Time‑to‑Value (время до получения первого рабочего черновика);

• Acceptance Rate — доля принятых предложений AI.

Делайте A/B‑тесты — сравните результат без контекста и результат с необходимым и достаточным контекстом, и скорее всего разница будет существенной.

8. Личный опыт специалистов вместо общих стандартов

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

Из практики:

Опытный менеджер виртуозно использовал LLM и AI‑агентов, экономя часы работы благодаря своим личным шаблонам запросов и документов.

Но, когда в команду пришел новичок, его результаты были на порядок хуже.

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

Как надо:

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

Перенесите лучшие личные практики в общую базу знаний, назначьте ответственного за её актуальность и добавьте чек‑листы в шаблоны постановки новой задачи.

9. «Сделали и забыли»: устаревшие данные и документы контекста хуже их отсутствия

Самый частый сценарий деградации работы c контекстом, когда команда написала документы контекста для AI‑агента, но перестала их поддерживать.

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

Из практики:

В одной компании появились проблемы при формировании коммерческих предложений, при детальном анализе выяснилось, что в инструкции для AI‑агента был пункт «использовать прайс‑лист 2025 года».

Но недавно компания перешла на новые тарифы.

А AI‑агент, следуя устаревшему статическому правилу, генерировал коммерческие предложения со старыми ценами, а менеджеры тратили время на ручную правку каждого документа.

Как надо:

Разделите контекст на правила и данные.

Динамические данные (цены, остатки, курсы) агент должен получать через вызовы инструментов (Tool calling) к живым API компании.

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

При этом внедрите три ритма обновления правил:

• горячий — обновляем инструкцию сразу при изменении бизнес‑процесса;

• тёплый — короткий вопрос на ежемесячном совещании: «что в наших инструкциях для AI‑агентов стало неактуальным?»;

• холодный — полугодовой аудит с правом и обязанностью удалять неактуальные пункты.

Если на аудите ничего не удалилось, то он был поверхностным.

В качестве заключения

Работа AI‑агента — это зеркало ваших бизнес‑процессов.

Как бы вы ни старались, если вы попытаетесь автоматизировать хаос, вы получите масштабированный хаос, умноженный на стоимость токенов LLM.

Поэтому управление контекстом — это не про «волшебные» промпты.

Это не просто «папка с документами», а архитектура знаний (Knowledge Architecture).

Это управленческая дисциплина работы со знаниями об организации с ответственными сотрудниками, ритмами обновления документов и четкими границами.

Поэтому успешное внедрение AI — это не погоня за самой «умной» моделью, а выстраивание системы, в которой AI‑агенты опираются на проверенные и актуальные факты о вашей компании.

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

---

Как получать более точные ответы от LLM и использовать ИИ в рабочих процессах?

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

На открытых уроках разберём, как работать с LLM: от промптов и проверки ответов до автоматизации задач:

• 1 октября в 20:00. «Проверка ответов LLM и борьба с галлюцинациями через промпт-инжиниринг». Записаться

• 12 октября в 20:00. «Промпты без случайного результата: как проектировать устойчивые сценарии работы с LLM». Записаться.

• 22 октября в 20:00. «От промта к автоматизации: как встроить LLM в рабочий процесс». Записаться

Все бесплатные уроки сентября можно посмотреть в дайджесте.