Еще недавно главный вопрос при внедрении AI звучал примерно так: «Как это сделать?». Как подключить модель к Jira, как дать ей доступ к GitHub, как написать агента, настроить MCP, собрать workflow и заставить все это работать стабильно.

Сейчас техническая часть стала заметно дешевле. Агента под конкретную задачу можно собрать за несколько часов. Модели умеют работать с tools, MCP стандартизирует доступ к внешним системам, frameworks берут на себя orchestration, memory и выполнение.

Из-за этого изменился сам вопрос. Теперь гораздо важнее понять: а стоит ли вообще здесь делать агента? И если стоит, то в какой именно части процесса он принесет реальный эффект?

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

Вот в последнем случае агент уже становится не демо, а частью рабочего процесса.

Именно поэтому в Laplace мы пришли к модели:

Discover → Build → Measure

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

Проблема уже не в создании агентов

Сейчас вокруг AI много разговоров про context engineering, agent harnesses, memory, orchestration и MCP. Все это важно, но в основном отвечает на вопрос: как сделать агента эффективнее?

Нас больше интересует другой уровень: как сделать эффективнее процесс, частью которого становится агент?

Потому что агент почти никогда не существует сам по себе. В процессе остается человек: кто-то ставит цель, кто-то принимает результат, кто-то отвечает за решение, кто-то должен понять, что произошло после выполнения. А вокруг них уже существуют Jira, Confluence, GitHub, почта, календарь, документы и другие рабочие инструменты.

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

Один и тот же агент может быть полезным в одной команде и бесполезным в другой

Представим две команды. В первой разработчик открывает Jira и сразу понимает задачу. Acceptance criteria заполнены, документация актуальна, все изменения связаны с pull request, решения фиксируются. Создание отдельного агента, который будет «восстанавливать контекст задачи», скорее всего, даст небольшой эффект.

Во второй команде задача выглядит так:

Добавить поддержку нового тарифа. Подробности обсуждали на встрече.

Разработчик идет в Confluence. Документ последний раз обновлялся восемь месяцев назад. После этого он ищет похожий pull request, пишет коллеге и в какой-то момент узнает, что часть решения обсуждали в чате, а архитектурное ограничение знает только один человек.

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

Именно такие места сначала нужно научиться находить.

Контекстный долг как след проблемы

Для этого мы используем понятие контекстного долга.

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

Например, разработчик ушел в отпуск, и часть работы остановилась, потому что только он знает устройство конкретной области. Новичок несколько недель ходит по людям с вопросами, ответы на которые уже звучали раньше, но нигде нормально не зафиксированы. В Jira десятки задач без содержательного описания. Изменения в GitHub невозможно связать с задачей, ради которой они появились. Документация существует, но никто не уверен, можно ли ей доверять. Половина встречи уходит на восстановление предыдущих договоренностей.

Каждый такой случай сам по себе еще не означает, что здесь нужен AI-агент. Но вместе они показывают места, в которых процесс требует большого количества ручного восстановления контекста. А это уже хорошие кандидаты для исследования.

Почему нельзя просто спросить AI, что автоматизировать

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

Создайте пять агентов. Они сэкономят вам 327 часов в месяц.

Проблема в том, что такой результат практически невозможно проверить.

Поэтому мы стараемся отделять наблюдаемые факты от интерпретации.

Например:

Факт: у 42% задач нет содержательного описания.

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

Возможность: агент может собирать связанный контекст и помогать готовить описание.

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

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

Что смотрит Context Audit

Сейчас Context Audit в Laplace собирает сигналы из Jira, Confluence, GitHub и подключенного календаря. Мы смотрим на разные части рабочего процесса отдельно.

Jira: насколько задачи готовы к передаче

Для задач проверяется наличие содержательного description, acceptance criteria, priority, estimate, assignee и связи с epic или parent task.

Задача без описания сама по себе не означает проблему. Но если значительная часть backlog требует дополнительного объяснения перед началом работы, появляется повторяемый ручной процесс: найти человека → получить объяснение → восстановить контекст → начать работу.

Вот это уже интересно с точки зрения автоматизации.

Confluence: насколько знания можно использовать

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

Старая страница не обязательно неправильная. Документ об архитектурном принципе может оставаться актуальным несколько лет. Поэтому мы не говорим: «Страница старая — документация плохая». Мы говорим: вот страницы, которые стоит проверить.

GitHub: можно ли восстановить причину изменений

В pull request смотрим, существует ли связь с задачей, можно ли подтвердить эту связь и насколько большим получилось обсуждение.

Двадцать комментариев к PR не означают автоматически плохую постановку задачи. Это может быть просто сложная техническая работа.

Что делать после Context Audit

Сам по себе Context Audit ничего не автоматизирует. Его задача — показать места, где процесс требует слишком много ручного восстановления контекста, координации или переключений между системами.

Дальше начинается более интересная часть: из найденной проблемы нужно сформулировать конкретный workflow, который имеет смысл изменить.

Допустим, аудит показывает, что большая часть задач приходит без технического контекста, разработчики регулярно ищут связанные документы и pull request, а после реализации вручную обновляют Jira. Это уже не просто «плохие задачи». Это повторяемый процесс:

поиск контекста → проверка пробелов → выполнение → обновление артефактов

Вот вокруг такого процесса уже имеет смысл строить агента.

Причем не абстрактного «AI-сотрудника», а агента с конкретной ролью, источниками данных, разрешенными действиями и человеком, который остается точкой контроля.

После этого аудит нужен снова. Только теперь вопрос меняется: не «где у нас проблема?», а «изменилось ли что-нибудь после автоматизации?»

Стало ли меньше времени уходить на восстановление контекста? Снизилось ли количество ручных действий? Стало ли меньше возвратов и уточнений? Пользуется ли команда новым workflow?

Если нет — значит, мы либо автоматизировали не тот процесс, либо неправильно его изменили.

Поэтому для нас Context Audit — не конечная функция. Это первый и последний шаг одного цикла:

Сначала найти место, где AI действительно может создать ценность. Потом встроить его в процесс. А затем проверить, создал ли он эту ценность на самом деле.