Почему ИИ-агентам для управления проектами нужны общие правила

Я на Хабре недавно, но уже успел заметить две вещи:

• Во-первых, здесь довольно быстро устают от хайпа вокруг искусственного интеллекта ^[1] и минусуют статьи, в которых пишут про ИИ без негативного опыта ^[2] его применения.

• Во-вторых, здесь с понятным скепсисом относятся к любым новым стандартам, сводам знаний, фреймворкам и манифестам, особенно если речь идёт о чём-то управленческом.

… а текст ниже заходит сразу на обе эти территории…

И всё же рискну.

Хочу написать о концепции агентного управления проектами и манифесте агентного управления проектами. Я участвовал в разработке этих документов, и мне важно не только показать результат, но и получить обратную связь от сообщества. Любую. Включая жёсткую.

С чего всё началось?

Всё началось не с теории и не с попытки придумать ещё один красивый термин.

С начала 2026 года мы довольно плотно обкатывали агентов в нескольких ролях проектной команды.

У нас были:

• агент администрирования проекта,

• агент мониторинга коммуникаций,

• агент планирования проекта.

Да, между ними были пересечения по функциям. И это, кстати, тоже отдельная тема. Границы между агентами на практике оказываются более размытыми, чем это кажется на архитектурной схеме.

Сначала мы гоняли всё это в своих проектах: в консалтинге и внедрении ПО. Потом попробовали те же идеи в строительных проектах. Надо признать, что опыт оказался одновременно очень вдохновляющим и очень отрезвляющим.

Удивило нас примерно следующее.

Агенты действительно хорошо работают там, где человеку приходится быть скучным и последовательным:

• непрерывно смотреть в несколько источников,

• замечать слабые сигналы,

• собирать статус,

• напоминать,

• подсвечивать расхождения,

• пересчитывать сценарии.

Там, где обычный руководитель проекта делает это урывками, потому что у него совещания, переписка, контракты, эскалации и просто ограниченный объём внимания ^[3].

Но разочарование было не меньше.

Очень быстро выяснилось, что агент не уменьшает хаос сам по себе. Если процессы в проекте кривые, статусы декоративные, данные неполные, а ответственность размыта, агент не исправляет эту картину. Он её ускоряет. Иногда ещё и очень убедительно.

И вот в этот момент стало понятно, что проблема вообще не в том, какая LLM лучше и какие промпты писать.

Проблема в другом. Что делать, когда в проекте появляется новый участник, который не просто отвечает на вопросы, а начинает влиять на информационную картину, из которой люди потом принимают решения?

Где заканчивается инструмент и начинается агент?

Это, пожалуй, была главная развилка.

Пока ИИ просто выполняет поручение по запросу: написать текст, собрать таблицу, посчитать вариант плана, проверить формулировку – это полезный инструмент. Но по логике ^[4] AgPM система считается агентом, когда ей делегируют управленческую функцию. Она сама решает, что показать человеку, как важное, и работает регулярно или непрерывно без нового запроса на каждый цикл.

Иными словами, агент не просто отвечает, а формирует вашу картину проекта. А это уже совсем другой уровень управленческого риска.

Зачем нам вообще понадобился ещё один манифест?

Потому что классическое управление проектами эту ситуацию описывает не до конца.

И PMBoK, и ISO 21502, и PRINCE2, и другие привычные рамки по-прежнему остаются полезными. В AgPM нет идеи всё это выбросить и начать жизнь с нуля. Наоборот, речь идёт не о замене классического проектного управления, а о том, чтобы добавить в него нового участника проектной системы – ИИ-агента.

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

Для меня именно это и стало причиной, почему вместо ещё одной методички по промптам появились документы управленческого типа. Потому что на практике упираешься не в качество генерации, а в вопросы вроде этих:

• Кто отвечает за последствия рекомендации агента?

• В какой момент сигнал становится фактом?

• Можно ли считать вывод агента основанием для изменения плана?

• Что делать, если два агента спорят друг с другом?

• И как не принять зелёный дашборд за реальное здоровье проекта?

Что в этих документах кажется мне действительно полезным?

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

Во-первых, жёсткая фиксация того, что ответственность остаётся за человеком. Не у модели, не у системы, не у того, кто интегрировал ИИ, а у конкретного человека, принимающего управленческое решение. В концепции это оформлено как двухслойная модель: классическая RACI остаётся человеческой, а агенты живут в параллельном слое ролей. С полномочиями, но без ответственности за результат.

Во-вторых, очень полезной мне кажется сама логика жизненного цикла проектной информации.

• Сигнал – это ещё не факт.

• Факт – ещё не официальный статус.

• Статус – ещё не изменение базового плана.

В концепции это разложено по шести стадиям:

• сигнал,

• гипотеза,

• подтверждённый факт,

• утверждённый статус,

• запрос на изменение

• и изменение базового плана.

Для практики это важнее любой красивой AI-терминологии.

В-третьих, в документах отдельно подчёркнуты вещи, без которых агентная система быстро становится опасной:

• агентное целеполагание,

• объяснимость,

• подотчётность,

• возможность отмены,

• безопасная деградация,

• пропорциональность.

Особенно близки мне последние две.

Безопасная деградация – потому что агент не должен при сбое утащить проект в неконтролируемый режим.

Пропорциональность – потому что попытка натянуть тяжёлую агентную рамку на маленький проект очень быстро превращается в карго-культ автоматизации.

В-четвёртых, четыре области практик:

• целеполагание,

• реализация,

• обучение ^[5],

• интеграция.

Это не ещё один линейный процесс из шести шагов, а скорее постоянные темы, которые РП должен держать в поле зрения ^[6]. Мне нравится эта логика, потому что она ближе к реальной жизни проекта, где всё идёт одновременно: ты и настраиваешь рамку, и разгребаешь текучку, и калибруешь поведение ^[7] системы, и постоянно стыкуешься с внешним миром.

В-пятых, модель зрелости из пяти уровней. От прозрачности, где агент только структурирует картину, до непрерывного обучения, где появляется межпроектная память ^[8] и перенос знаний. На мой взгляд, это полезно уже хотя бы потому, что в этой модели есть нормальная стартовая точка. Не давайте сразу автономный ИИ-офис, а давайте сначала научим систему наблюдать и не врать. Или хотя бы врать недорого.

Что меня в этой истории до сих пор смущает?

Скажу прямо. Сырого здесь ещё много.

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

Меня смущает и другая вещь. Главный риск здесь не технологический, а человеческий. Опасность не только в том, что агент ошибётся, а в том, что человек перестанет думать, потому что думает агент.

Отсюда ложный контроль, деградация компетенций, размывание ответственности и эффект усиления слабого РП, который с агентом начинает принимать решения, на которые без агента просто не решился бы.

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

Где это всё может дать реальную пользу?

Лучше всего смысл подхода виден не в принципах, а в сценариях.

В концепции есть очень приземлённые примеры:

• агент раньше замечает, что подрядчик скрывает отставание,

• быстрее пересчитывает варианты после изменения объёма,

• готовит материалы к встрече со спонсором на основе актуальных данных,

• помогает новому РП быстрее войти в проект,

• автоматически отслеживает критичные изменения у партнёра.

Есть и антисценарии: ложный сигнал, перегрузка рамкой, оптимизация не той функции.

Собственно, наши пилоты и подтолкнули нас примерно к тем же выводам.

Больше всего агенты пригодились там, где нужна непрерывность наблюдения, сопоставление разнородных данных и быстрое формирование вариантов. Хуже всего – там, где хотелось заменить ими смысл, контекст и политическую навигацию.

С этим они не справляются. И, думаю, ещё долго не будут.

Зачем я пишу об этом именно сюда?

Потому что такие документы бесполезно писать в вакууме проектных офисов и корпоративных презентаций.

Мы проложили в открытый доступ два PDF:

• короткий манифест ^[9]

• более подробную концепцию в версии 1.0. ^[10]

При этом концепция – документ для обсуждения проектным сообществом. И это, пожалуй, лучшая формулировка того, как к ней и стоит относиться.

Не как к канону. Как к приглашению в спор.

 

Поэтому мой призыв очень простой.

Посмотрите на эти документы как на ещё один AI-лендинг, а как на попытку описать управленческую проблему, которая уже появилась на практике. И напишите (например, в комментариях), где здесь действительно есть полезная рамка, где – переименование давно известных вещей, а где – просто лишняя сущность.

Особенно интересны возражения по четырём точкам:

• где проходит граница между инструментом и агентом,

• нужна ли для этого вообще отдельная дисциплина,

• насколько реалистична модель зрелости

• и какие правила обязательны с первого дня, а какие только утяжеляют систему.

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

Где скачать документы?

Сайт проекта: https://agenticpm.pro/ ^[11]. И выше прямые ссылки.

На сайте доступны два документа: «Манифест» и «Концепция v1.0».