Вопрос внедрения ИИ в рабочие процессы изменился. Еще недавно главной задачей было «как это сделать»: подключить модель к Jira, дать доступ к GitHub, настроить MCP и собрать workflow. Сейчас техническая часть стала заметно дешевле — агента под конкретную задачу можно собрать за несколько часов, модели умеют работать с tools, а MCP стандартизирует доступ к внешним системам. На первый план выходит другой вопрос: а стоит ли вообще здесь делать агента и в какой части процесса он принесет реальный эффект.
В компании Laplace, которая занимается внедрением ИИ в корпоративные процессы, пришли к модели Discover → Build → Measure. Прежде чем строить агента, нужно понять, где его имеет смысл строить. Проблема уже не в создании агентов, а в том, как сделать эффективнее процесс, частью которого агент становится. Вокруг агента всегда остается человек: кто-то ставит цель, принимает результат, отвечает за решение. А вокруг них существуют Jira, Confluence, GitHub, почта и другие инструменты. Поэтому внедрение агента — это изменение рабочего процесса, и прежде чем менять процесс, нужно увидеть, как он работает сейчас.
Один и тот же агент может быть полезным в одной команде и бесполезным в другой. В первой команде разработчик открывает Jira и сразу понимает задачу: acceptance criteria заполнены, документация актуальна, все изменения связаны с pull request. Создание агента для «восстановления контекста задачи» даст небольшой эффект. Во второй команде задача выглядит как «Добавить поддержку нового тарифа. Подробности обсуждали на встрече». Разработчик идет в Confluence, но документ обновлялся восемь месяцев назад, ищет похожий pull request, пишет коллеге и узнает, что часть решения обсуждали в чате, а архитектурное ограничение знает только один человек. Здесь появляется точка для автоматизации: повторяемая ручная работа по поиску, сопоставлению и восстановлению контекста.
Для поиска таких мест в Laplace используют понятие контекстного долга. Контекстный долг — это издержки из-за разрозненной, устаревшей или недостающей информации внутри рабочего процесса. Примеры: разработчик ушел в отпуск, и часть работы остановилась, потому что только он знает устройство области; новичок неделями ходит по людям с вопросами, ответы на которые уже звучали, но нигде не зафиксированы; в Jira десятки задач без содержательного описания; изменения в GitHub невозможно связать с задачей. Каждый такой случай сам по себе не означает, что нужен ИИ-агент, но вместе они показывают места, где процесс требует ручного восстановления контекста.
Почему нельзя просто спросить ИИ, что автоматизировать? Подключаем корпоративные системы, ИИ анализирует компанию и через пять минут выдает: «Создайте пять агентов, они сэкономят вам 327 часов в месяц». Проблема в том, что такой результат практически невозможно проверить. Поэтому в Laplace стараются отделять наблюдаемые факты от интерпретации. Например, факт: у 42% задач нет содержательного описания. Гипотеза: сотрудники тратят время на восстановление требований. Возможность: агент может собирать связанный контекст. Но из первого утверждения не следуют второе и третье: возможно, команда сознательно использует Jira как короткий список задач, или требования находятся в другой системе. Только после проверки гипотез можно переходить к построению агента.
Подход Discover → Build → Measure помогает избежать типичных ошибок: потратить неделю на агента, которым пользуются два раза в месяц, автоматизировать процесс, который занимал пять минут, или встроить ИИ в плохо устроенный workflow, автоматизировав хаос. Вместо этого нужно найти повторяемый процесс, в котором несколько человек ежедневно тратят время на поиск информации и ручные действия между системами. В таком случае агент становится не демо, а частью рабочего процесса.
