Корпоративная документация перестаёт быть справочником для сотрудников. Когда её начинают читать агенты, она становится частью production‑контура: от её структуры, актуальности и связей зависит качество ответа, стоимость инференса и риск ошибки в процессе.
Сотрудник может компенсировать пробелы опытом: знает, где лежит актуальный регламент, кто уточнял исключение и почему метрика в отчёте иногда считается не так, как в описании. Агент таких допущений не делает: если связь, статус или исключение не попали в контекст, для него их нет.
По данным LangChain State of Agent Engineering 2026 (опрос 1 300+ специалистов), качество остаётся главным барьером для вывода агентских систем в продакшен. В корпоративных сценариях дело часто не только в модели, но и во входном контексте: какие знания агент получил, насколько они актуальны и видит ли он связи между ними.
Где агент теряет контекст
У агента нет «карты в голове», которая есть у сотрудника. Определение метрики может лежать в wiki, схема таблицы — в каталоге данных, исключения — в в регламенте, а фактическая логика расчёта — в SQL‑запросе.
Чтобы ответить, агенту приходится каждый раз собирать эти фрагменты в одну картину. Ту же проблему описывает Google Cloud: когда знания распределены между системами и людьми, агентам приходится восстанавливать связи, которые для сотрудников очевидны.
У этой проблемы две цены: точность и бюджет. Лишняя разметка, навигация и служебный текст увеличивают контекст, а вместе с ним — стоимость работы агента. По замеру AlterLab (2026), конвертация HTML‑страницы в Markdown сокращала объём примерно с 50 000 до 3 000 токенов — на 94%. Формат и разметка влияют не только на расход, но и на то, какой контекст агент вообще сможет использовать.
Что модель не проверит
Модель отвечает тем, что попало в контекст. Если правило расчёта комиссии пришло без версии и области применения, агент может применить старую логику к новому продукту: неверно объяснить клиенту тариф, неправильно подсказать оператору порядок проверки или запустить лишнюю эскалацию.
Проблема не в том, что модель «плохо рассуждает». Ей неоткуда проверить актуальность источника, статус правила и границы применения, если эти признаки не описаны явно.
Поэтому важно описывать не только само правило, но и условия его применения: источник, статус, версию и область действия.
Когда контекст становится риском
На малом масштабе дефект ещё можно поймать вручную: пользователь уточнил ответ, команда поправила правило, источник обновили. На уровне нескольких агентов та же ошибка становится операционным риском: один неверный источник может повлиять сразу на несколько процессов.
Например, устаревшее определение статуса клиента может попасть в ответ поддержки, затем — в аналитический отчёт, а после этого — в обработку документов. На каждом шаге агент действует логично: он использует контекст, который ему дали. Проблема в том, что сам контекст уже неверен.
Когда агенты переходят из экспериментов в рабочие процессы, первыми напрашиваются два решения: лучше искать по существующим документам или автоматически достраивать недостающий контекст. Оба подхода полезны, но закрывают только часть проблемы.
Первый путь — загрузить сырые документы в RAG. Поиск улучшится, но качество исходных знаний останется прежним. Если документ устарел или противоречит соседнему разделу, агент будет снова и снова поднимать в контекст тот же дефект. Heeya (2026) описывает это точно: RAG усиливает проблемы качества источника, а не скрывает их.
Второй путь — сгенерировать недостающий контекст автоматически. Для черновиков подход полезен, но для промышленного контура этого недостаточно. Исследование ETH Zurich, описанное в InfoQ, тестировало LLM‑генерированные контекст‑файлы на coding‑агентах и файлах AGENTS.md в инженерных репозиториях: такие файлы снижали успешность задач на 3% и увеличивали стоимость инференса более чем на 20%.
Отсюда следующий шаг: агентам нужен слой знаний, который можно читать, проверять, версионировать и связывать с другими источниками — так же, как команды делают это с кодом и конфигурациями.
Open Knowledge Format
12 июня 2026 года Google Cloud представила Open Knowledge Format — открытый формат для корпоративных знаний, которые должны оставаться читаемыми для людей и понятными для агентов.
В OKF нет новой платформы или отдельного хранилища. Формат использует привычные инженерные элементы: Markdown для текста, YAML‑метаданные для статуса и связей, ссылки между файлами и git для версионирования.
Практический смысл в том, что агент получает не большую страницу целиком, а отдельный контекст для задачи: правило, метрику, описание API или инструкцию. Вместе с текстом он видит признаки применимости — источник, статус, дату обновления, связанные документы.
На сайте стандарта OKF можно посмотреть готовые примеры: метрика, таблица, API‑endpoint, policy‑файл и constraint. Это удобно для старта: ИИ может быстро разложить существующие страницы на такие фрагменты, предложить первичные метаданные и связи. После этого владелец домена проверяет не текст “на красоту”, а применимость: актуален ли источник, верный ли статус и где это знание можно использовать.
Сначала нужно привести источник в порядок. Уже потом его можно искать через RAG, передавать агенту в контекст или связывать с инструментами через MCP.
С чего начинать
OKF не требует начинать с большого проекта по переписыванию документации. Рациональнее выбрать небольшой, но показательный контур: тот, где ответы агента уже можно проверить на реальных вопросах, а ошибка не создаёт лишнего риска.
Мы начинаем с публичного контура — сайта fork-tech.ru и уже перевели его на новый формат. Первый практический сценарий — ассистент отдела продаж на базе PWS: он помогает быстро собрать ответ на вопросы клиента — какие проекты Fork‑Tech делала в финтехе, какие кейсы подходят под конкретную задачу и какие результаты уже есть в публичных материалах.
Раньше для такого ассистента приходилось собирать отдельную базу знаний. Это работало на старте, но быстро появлялась проблема поддержки: сайт обновился, вышел новый публичный кейс или изменилась продуктовая формулировка — и базу нужно обновлять отдельно. Чем больше таких расхождений, тем выше риск, что ассистент ответит по старой версии публичных материалов.
Поэтому в пилоте мы используем сайт не только как витрину, но и как первичный источник структурированных знаний. Для агента важна не вся страница целиком, а отдельные сущности и связи между ними: направление, продукт, кейс, отрасль, результат. Он должен находить связку «задача → кейс → продукт → результат», а не пересказывать страницу.
Знания остаются узким местом
RAG, MCP, OKF и передовые модели уже дали агентам заметный буст: им стало проще искать контекст, вызывать инструменты и работать с корпоративными знаниями. Но сами по себе эти технологии не решают главный вопрос: на какие знания агент опирается, кто отвечает за их актуальность и можно ли доверять ответу в конкретной бизнес‑ситуации.
Поэтому первичной задачей становится поддержание знаний и данных компании в рабочем состоянии. Чем быстрее компания умеет обновлять, структурировать и проверять свои знания, тем быстрее агенты начинают приносить пользу — в продажах, поддержке, разработке и операционных процессах.
