Anthropic оценивает, что агент может потратить около 150 тыс. токенов только на загрузку описаний MCP-инструментов, еще до того как начнет делать что-то полезное. На этом фоне идея Context Lake выглядит не модным словарем из мира AI, а попыткой закрыть вполне земную проблему: почему агент с доступом к GitHub, Jira и облаку все равно регулярно отвечает как стажер в первый день на проекте.
Об этом пишет The New Stack в материале Зоара Эйни, опубликованном 27 мая 2026 года. Тезис простой: корпоративным AI-агентам мало выдать набор инструментов и MCP-серверов. Им нужен отдельный слой организационного знания, который объясняет, что в компании считается сервисом, кто им владеет, какие у него зависимости, где прод, кто дежурит и что вообще означает «готово к продакшену». Иначе агент умеет нажимать на кнопки, но не понимает, зачем именно и в каком порядке.
Автор разбирает три типовых барьера при попытке масштабировать агентский подход на команду или всю компанию. Первый барьер предсказуемо бюрократический, но от этого не менее болезненный: безопасность и комплаенс. По словам Эйни, в крупных организациях подключение новых MCP-серверов и моделей часто требует проверки каждого источника данных, а иногда проходит через внутренние AI-комитеты. В статье приводится показательная цитата platform lead из крупной финансовой организации: на согласование GitHub Copilot для внутреннего использования ушло больше девяти месяцев, а MCP-серверы там вообще заблокированы. Для тех, кто уже мечтал о полностью автономном инженерном помощнике, это неприятное напоминание: между демо и продом лежит отдел безопасности.
Второй барьер связан уже не с политикой, а с механикой. Когда компания все-таки получает одобрение, появляется соблазн подключить агенту все подряд: GitHub, Jira, AWS, PagerDuty и дальше по списку. В итоге у него оказывается 10 и более MCP-серверов и сотни инструментов. Проблема в том, что это не делает его автоматически умнее. Наоборот, если определения инструментов целиком грузятся в контекстное окно, растут задержки, стоимость запросов и риск деградации качества. Эйни ссылается на инженеров Anthropic, которые оценивали такую загрузку примерно в 150 тыс. токенов. Это уже не мелкая накладная расходная часть, а полноценный инфраструктурный налог на каждую попытку «сделать агенту побольше возможностей».
Третий барьер самый неприятный, потому что он всплывает даже там, где доступы выданы и инструменты подключены. Агент все равно не знает, что именно означает вопрос внутри конкретной компании. Запрос «Какие у меня открытые PR?» выглядит тривиально только для человека. Для модели в нем слишком много скрытых переменных: кто такой «я», что считать open, в каких репозиториях искать, в каких организациях, нужно ли включать draft. То же самое с вопросом о статусе деплоя сервиса: сначала надо понять, что именно в этой компании считается сервисом, какой pipeline к нему относится и какой из нескольких похожих процессов вообще представляет реальный прод. Если таких знаний нет, агент начинает угадывать. Иногда правдоподобно. Но это все равно угадывание, а не надежная автоматизация.
Отсюда и критика подхода с AGENTS.md, который многие уже успели полюбить за простоту. Документ с инструкциями для агента может работать в одном репозитории или в небольшой команде. Но когда у компании сотни или тысячи репозиториев, эта схема быстро превращается в ручной труд без гарантии актуальности. В статье приводится пример с 1000 репозиториев: поддерживать единые правила, описания зависимостей и терминологию в таком масштабе через markdown-файлы почти нереально. Поэтому вместо локальных подсказок автор предлагает Context Lake как централизованный слой знаний, который можно запрашивать программно.
По версии Port, чей sponsored post и опубликован на площадке The New Stack, Context Lake должен стоять между агентом и набором инструментов. Это не замена GitHub или Jira и не еще один каталог ради каталога. Скорее, это слой связей и смыслов: какой репозиторий соответствует какому сервису, какая команда им владеет, что зависит от чего, какие среды считаются production, какие требования по SLA действуют и какие стандарты SDLC нужно считать обязательными. В статье отдельно подчеркивается различие между привычным service catalog и Context Lake: каталог удобен человеку для просмотра, а Context Lake должен быть удобен агенту для запроса и получения однозначного ответа.
Дальше начинаются практические сценарии, ради которых все это и затевается. Если связи между объектами описаны явно, агент может стабильно отвечать на вопросы уровня «какие PR сейчас открыты у моей команды», оценивать blast radius изменений в коде, подбирать ревьюеров по ownership и недавней активности, собирать новому разработчику план задач из инцидентов, тикетов и упавших мониторингов, а в инциденте сразу понимать критичность сервиса, SLA и нужного on-call. В статье есть и показательный бизнесовый пример: условный checkout-service, который обрабатывает 2 млн долларов в день и требует реакции класса P1, не должен для агента выглядеть так же, как внутренний сервис, который спокойно подождет до понедельника. Для бизнеса это, пожалуй, главная мысль: без контекста агент автоматизирует действия, но не приоритеты.
Технически схема выглядит знакомо для любой команды, которая уже строила внутреннюю платформу. Данные стекаются из GitHub, Jira, AWS, PagerDuty и других систем, затем маппятся на бизнес-термины компании: репозиторий становится сервисом, проект в Jira превращается в бэклог команды, облачный ресурс привязывается к окружению. Поверх этого описываются сущности, связи и scorecards, которые фиксируют, что компания считает нормой для production-ready сервиса. Доступ агентам, по словам автора, можно выдавать через те же механизмы контроля, что и людям, чтобы модель видела только то, что разрешено конкретному пользователю.
Во всей этой истории важен не только сам термин Context Lake, а сдвиг в инженерном мышлении. Рынок AI-агентов постепенно уходит от идеи «дадим модели побольше инструментов, и она разберется» к идее «сначала опишем организацию так, чтобы машина могла в ней ориентироваться без гадания». Для русскоязычных команд это звучит особенно знакомо: почти в каждой компании уже есть разрозненные куски такого знания в wiki, каталогах, runbook, Jira и головах сотрудников. Вопрос теперь не в том, подключать ли агенту еще один MCP-сервер, а в том, кто первым соберет из этого работающий слой контекста и превратит красивые демо в предсказуемый production.