Один агентный запуск может породить сотни тысяч событий, а в кейсе Laminar речь уже идет более чем о 500 тысячах браузерных событий в день. На этом фоне трейсы ИИ-агентов перестают быть обычными логами: если продукт хранит их для разбора, показа пользователю и сравнения запусков, это уже не служебная телеметрия, а часть данных приложения. Для разработчиков, команд платформы и техлидов это неприятно практический вопрос: старый стек хранения может начать тормозить раньше, чем агент принесет обещанную экономию.
Об этом пишет The New Stack в материале от 26 августа 2026 года. Автор текста Манвир Чавла предлагает смотреть на следы работы ИИ-агента не как на побочный выхлоп инфраструктуры, а как на полноценный продуктовый артефакт, если команда использует их для реконструкции запуска, аудита и анализа поведения модели на множестве задач.
Сценарий знаком любому, кто уже пробовал агентную разработку. Тест падает, разработчик отдает задачу coding agent, тот читает файлы, гоняет тесты, меняет пару участков кода и запускает проверку. После этого человеку нужен не только итоговый diff, но и история действий: какие файлы агент открывал, какие команды выполнил, что вернули инструменты, где появились ошибки и на каком шаге он вообще свернул не туда. Пока такие данные живут короткой жизнью и нужны лишь для внутренней диагностики, это телеметрия. Но как только команда обязана хранить их как «чек» выполнения, показывать в интерфейсе и возвращаться к ним через неделю или месяц, начинается совсем другой класс требований.
Ключевая мысль здесь в том, что продукту не обязательно раскрывать внутренние рассуждения модели, чтобы сделать запуск проверяемым. Достаточно сохранять наблюдаемую последовательность действий: вызовы модели, обращения к инструментам, чтение файлов, результаты команд, тайминги, переходы состояний и статусы проверки. Для пользователя это способ оценить, можно ли доверять результату. Для бизнеса и платформенной команды это уже журнал ответственности: если агент работал с кодом, промптами, документами или аргументами инструментов, внутри этого следа может оказаться чувствительная информация арендатора, команды или конкретного сотрудника. Значит, доступ к таким данным должен подчиняться тем же правилам авторизации и хранения, что и остальная прикладная информация.
Почему объем растет быстрее, чем кажется
Проблема не только в статусе данных, но и в масштабе. Трейсы ИИ-агентов раздуваются не линейно, а скачками. Добавили новый tool, политику повторных попыток или ветвление сценария, и объем событий вырос, хотя число завершенных задач не изменилось. The New Stack приводит показательный пример Laminar: более 500 тысяч браузерных событий в день, сессии длительностью свыше 30 минут и сотни тысяч DOM-изменений в рамках одного сеанса. Эти данные используются для реконструкции почти видео-повтора того, что агент «видел» в браузере. И это уже история не про красивые демо, а про инфраструктурный счетчик, который начинает крутиться очень быстро.
У таких данных, по сути, двойная жизнь. С одной стороны, нужен точечный доступ к одному конкретному запуску: разработчик открывает проблему, ревьюер проверяет цепочку действий, саппорт разбирает спорный результат. С другой стороны, те же самые трейсы ИИ-агентов нужны для анализа по когортам: сравнить успешность тестов между версиями модели, увидеть, не выросла ли латентность после смены промпта, проверить, не съехала ли стоимость из-за лишних вызовов инструментов. Добавьте сюда интерес платформенной команды к окнам по времени, ошибкам и задержкам по моделям, инструментам и деплойментам, и становится ясно, почему привычная транзакционная база быстро начинает задыхаться.
Чавла отдельно подчеркивает техническую природу таких записей. Большинство событий в агентном трейсe записываются один раз и почти не обновляются: вызов модели уже произошел, результат инструмента уже получен. Изменяться могут статус запуска, оценки, аннотации, но их можно вынести отдельно или тоже хранить как новые события. При этом у набора огромная кардинальность: версии модели, шаблоны промптов, имена инструментов, идентификаторы сессий, пользователи, исходы задач. Одна запись сама по себе мало что объясняет, но вся траектория запуска или выборка по тысячам прогонов уже показывает деградацию, лишние шаги и дорогостоящие ошибки.
Что это меняет для архитектуры
Главный практический вывод не в том, что всем срочно нужен новый аналитический стек. Скорее в том, что командам придется честно ответить на вопрос: кто и как читает эти данные. Если продукту достаточно иногда заглянуть в один запуск, а масштаб скромный, основная база еще справится. Но если аналитические запросы начинают спорить с боевыми чтениями и записями за те же ресурсы, трассировку логичнее выносить в отдельное аналитическое хранилище, а транзакционные сущности вроде пользователей, прав и состояния workflow оставлять в основной БД. В статье как пример упоминается связка, где продукт живет на Postgres, а агентные события отправляются в ClickHouse; при необходимости прикладные данные можно дотянуть в аналитический контур через change data capture.
Для русскоязычной IT-аудитории здесь нет никакой экзотики. Компании уже привыкли к тому, что observability-данные живут по своим законам. Новизна в другом: трейсы ИИ-агентов теперь все чаще становятся частью интерфейса, процесса ревью, внутреннего комплаенса и даже аргумента в споре между разработчиком и машиной. Это означает, что их нельзя бездумно семплировать, быстро протухать по TTL или хранить как мусорный append-only поток без модели доступа. ИИ-агент в продукте постепенно приносит с собой не только расходы на inference, но и новый класс прикладных данных, который надо проектировать заранее, а не после первого инцидента.
Сильнее всего этот сдвиг ударит по тем командам, которые пока считают агентный запуск «расширенным логом». Как только бизнес просит воспроизводимость, прозрачность и сравнение качества между тысячами прогонов, трейсы ИИ-агентов становятся не хвостом системы, а ее отдельным слоем. И вопрос уже не в том, похожи ли они на логи, pull request или историю сессии, а в том, готовы ли ваши хранилища и права доступа к тому, что поведение агента внезапно стало продуктом само по себе.