Проект-координатор — одна из самых дорогих ролей в крупной компании. Третий месяц эту роль у нас закрывает AI-агент — и всё это время мы собираем, где и как он ломается.
Вся работа координатора держится на одном фокусе: к вечеру пятницы помнить, что Вася утром сказал «API готов, остался только тест», а Маша две недели назад пообещала макет. Год подряд удерживать этот фокус не получается ни у кого. Простуда, ребёнок, митинг на два часа дольше, в голове три проекта, и половина сказанного на созвоне до доски не доезжает. У любого человека есть предел внимания, и постоянная операционная нагрузка до него добирается.
В Манараге проект-координаторов не было с первого дня. Сначала казалось, что проблема решается сама: самоуправляемые команды, роль раскидана между PM, аналитиками и тимлидами. Через полгода стало видно, что такая раскидка ничем не отличается от отсутствия роли. К концу квартала никто точно не мог сказать, кто именно отслеживает обещания с прошлой среды. Когда это обязанность всех, это обязанность никого. К концу 2025 модели подтянулись до уровня, на котором роль может взять агент.
В конце января 2026 мы включили его на собственную команду. Ниже — что стоит за тремя месяцами калибровки.
Три сцены, которые повторяются каждую неделю.
Расхождение с доской. Вася на созвоне говорит «API готов, остался только тест». Агент открывает доску — карточка три дня висит In Progress без обновления. Сходится не так, как должно. В карточку уходит комментарий с цитатой из созвона и предложением «перевести в Review?» одним кликом. Это минимальное действие: расхождение отмечено рядом с работой, на которую оно влияет, без эскалаций и пингов в личку.
Забытое обещание. Маша на планировании пообещала макет к пятнице. Прошло две недели. В чате про него никто не спрашивал — команда переключилась на следующий спринт, и задача просто выпала из общего поля внимания. Агент поднимает флаг: «Обещание от 10.04 не исполнено и не упоминалось с тех пор. Уточнить у Маши или закрыть как отменённое?» Он — единственный в команде, кто ещё помнит про этот макет.
Подкрадывающийся дедлайн. Через два дня сдача, последнее обновление пять дней назад. Агент пишет исполнителю в чат с конкретикой: какая задача, какой дедлайн, что последний раз обсуждалось. Если сутки тишины — передаёт руководителю проекта всю историю обсуждения с цитатами из созвонов. К моменту эскалации у руководителя уже есть фактура: о чём говорили, что обещали, где именно перестало идти.
На раннем этапе мы отпустили эту страховку: агент мог менять статусы сам, если в созвоне звучало «готово». В одном из дейли прозвучало «этот кусок уже в CI, зелёный» — агент перевёл карточку в Done. Выяснилось, что зелёный был предыдущий прогон, свежий упал, и на доске закрытой значилась задача, которой ещё нет. Разбор занял несколько итераций: вернули карточку в прежний статус, переписали инструкцию о том, что считать «готовым», прогнали новую формулировку на эталонном наборе, сверили, не сломалась ли она на соседних статусах.
Это был первый разбор из серии. Следующие случаи вскрывали границу автономии с других сторон: где агент не различает идею и обещание, где не учитывает согласованную паузу в задаче, где переносит формулировку обещания из одной команды в другую, у которой иной ритм дейли. Каждый такой случай сдвигал правило на один щелчок. Сейчас: комментарии агент пишет сам, всё, что двигает доску — смена статуса, исполнителя, дедлайна, создание карточки, — уходит через подтверждение в один клик. Молчаливых правок на доске у агента больше не бывает.
За бытовыми сценами — шесть проверок, каждая со своим сценарием действия. Именно они делают агента полезным, а не шумным.
stuck — карточка в одном статусе N дней и при этом не всплывала в чате и созвонах. Сигнал — спросить у исполнителя, есть ли блокер, без эскалации.repeated_delay — дедлайн сдвигали несколько раз подряд. Сигнал руководителю проекта: задача дозрела до отдельного разговора, сдвигать дедлайн ещё раз смысла нет.status_mismatch — в созвоне прозвучало «готово», на доске In Progress. Комментарий с цитатой и предложение перевести одним кликом.lost_commitment — обещание, данное в прошлом дейли или в чате, не упоминалось дольше порога и не исполнено. Запрос владельцу: ещё актуально или можно закрыть как отменённое.overdue — просрочено и не закрыто. Базовая проверка с большим эффектом: одна просроченная карточка редко важна сама по себе, но паттерн пропусков у исполнителя или команды видно сразу.not_mentioned — активная задача в спринте, ни разу не всплывавшая ни в чате, ни в созвонах. Часто это признак, что задача «есть», а работы по ней нет.У каждой проверки свой порог и своё описание, они живут отдельным markdown-файлом. Это место — входная точка ко всей калибровочной работе, и именно там система может сломаться тихо.
Возьмём stuck. Его порог — точка баланса между двумя крайностями. Поставим терпимее — теряется половина реальных залипаний. Поставим жёстче — команда через неделю перестаёт открывать флаги, шум заглушает сигнал. Правильное значение лежит где-то между, оно разное для багфиксов, исследовательских задач и интеграций, и достаётся калибровкой на корпусе прошлых дейли. То, что снаружи читается как «правка абзаца и коммит», внутри — десятки калибровок с проверкой, что поведение сдвинулось именно туда, куда мы хотели, и не ушло вбок на соседних типах карточек.
Без эталонного набора такие правки опасны: одна неудачная формулировка «готово» в markdown проходит ревью за минуту и каскадом ломает три проверки, и команда снаружи заметит это только через неделю, когда перестанут приходить флаги по реально застрявшим задачам. Поэтому каждая правка скилла прогоняется на наборе прошлых дейли, второй проход LLM сверяет вывод со старым поведением, merge блокируется при сдвиге выше порога. Без этого гейта markdown — самый опасный формат правил из существующих: легко править и так же легко молча разрушить.
То, что сверху выглядит как «агент ходит на созвоны и следит за доской», внутри — связка из четырёх слоёв. Мы сознательно не строили собственную инфраструктуру под них: в 2026 году оркестрация, хранилище состояния и LLM-роутинг берутся готовыми — это решённые задачи. Инженерный бюджет у нас ушёл туда, где готовых решений нет: в эталонный набор, пороги проверок, границы автономии, eval-гейт. Работы в них в несколько раз больше, чем ушло бы на собственную оркестрацию.
git revert на коммите, который его породил. Аудит «что агент делал 14 марта» — git show по истории коммитов, без отдельной системы логирования.Инженерия этой системы живёт в калибровочной работе под команду: эталонный набор, пороги проверок, границы автономии, eval-гейт. Код и инфраструктура — тысяча строк Python транспорта, готовый CI-рантайм, git-репозиторий, markdown-файлы — вокруг неё.
Шесть проверок работают ровно потому, что каждый порог прошёл через десятки калибровок на эталонном наборе прошлых дейли. stuck без калибровки на второй неделе превращается в шум: флаги сыплются слишком часто, команда перестаёт их открывать, и проверка теряет ровно ту роль, ради которой поставлена. Граница автономии работает, потому что мы выверяли её классами реальных инцидентов на собственной команде, и каждый инцидент сдвигал правило на один щелчок. Skill-файлы переносятся между командами потому, что у нас есть шаблон того, какие правила завязаны на культуру конкретной команды, какие универсальны, а какие вскрываются только на третьей-четвёртой неделе работы.
У команды, которая пробует собрать такое с нуля, этого шаблона нет. Одни и те же грабли встречают её раз за разом: порог stuck на старте ловит половину ретро-задач и пропускает исследовательские, потому что без калибровки на эталонном наборе его не получается поставить под разную природу задач; формулировка «обещание», работающая у инженерной команды, у аналитической молча меняет смысл, и агент начинает помнить то, что никто не обещал; первая попытка автономии заканчивается переведённой в Done задачей по устаревшему CI — той самой, которую мы разбирали полдня у себя. Мы знаем эти классы, потому что прошли их на себе; внутренняя команда клиента встречает каждый впервые.
Markdown как язык правил выдерживает продакшн по одной причине: под ним лежит eval-гейт с эталонным набором и блокировкой merge. Без этого контура одна неудачная формулировка «готово» каскадом ломает три проверки, и никто снаружи этого сразу не увидит. Аналитик правит безопасно ровно в границах того, что удерживает гейт. Без гейта markdown — самый опасный формат правил из существующих: править его так же просто, как и молча разрушить.
Три месяца на собственной команде — не демо-таймлайн и не витрина. В git log за это время — разборы классов инцидентов автономии, волны калибровки порогов под разные типы задач, перенос skill-пакета между профилями команд, блокировки merge eval-гейтом. Стабильность, которая снаружи выглядит как её отсутствие, держится на этих коммитах и разборах.
Набор узких агентов: подготовка повестки к стендапу, разбор транскрипта, написание комментариев в карточки, сводка в чат. Каждый отвечает за один шаг, а общий координатор собран как цепочка таких агентов, где каждый делает одну вещь хорошо
Созвоны, планинги, чаты и снимки доски сводятся в одно описание состояния проекта. Транскрипт разбирается на сущности: карточки, обещания, люди, сроки, — на них можно ссылаться прямо из комментариев, не возвращаясь каждый раз к исходным транскриптам
Шесть проверок аномалий описаны инструкциями в skill-файле. Каждый порог прошёл через десятки калибровок на эталонном наборе прошлых дейли; перед merge правка прогоняется на этом наборе и блокируется, если поведение сдвинулось не туда
Комментарии агент пишет сам — комментарий стираем, ничего не ломается. Смена статуса, исполнителя, дедлайна и создание карточки — только через подтверждение в один клик. Критерий границы один: обратимость действия
Ответим, подходит ли задача для AI-агентов, и если да, предложим конкретный план.
Заявка отправлена
Ответим в течение дня на указанный email.
или напишите напрямую — ilya@manaraga.ai