«А что если заменить целую команду ИИ-агентами?» — этим вопросом в конце декабря прошлого года задался Игорь, директор компании «Эрегион» и давний пользователь Кайтена. Он решил проверить идею на практике и понять, что из этого получится и как вообще все грамотно организовать.

Первые внедрения ИИ Игорь сделал в процессах «Кабель.РФ». А уже к июню небольшой эксперимент вырос в целую систему, где 10+ ИИ-агентов в фоне закрывают продуктовые и IT-задачи. Причем Игорь подключается всего несколько раз за проект — на старте, приемке прототипа и в конце.

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

Раньше нейросеть все время просила себя перепроверить

Активно использовать LLM в работе Игорь начал в октябре прошлого года. Сначала все выглядело довольно привычно: он общался с моделью в чате, просил сделать часть проекта, потом отправлял список ошибок и ждал исправлений. Так постепенно начали появляться первые экспериментальные проекты — LMS-система, сервис транскрибации и другие небольшие продукты.

Но в этой схеме было одно большое ограничение: весь контроль все равно оставался на Игоре.

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

Когда проектов стало заметно больше, схема попросту начала разваливаться. У каждого проекта был свой контекст, задачи и списки доработок. Внутри чатов росли огромные to-do списки, часть идей уходила в бэклог, часть терялась, а кроме разработки появились еще исследования, маркетинг и продуктовые задачи.

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

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

Почему Игорь выбрал Кайтен

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

Первым кандидатом был Linear. У него есть встроенная логика работы с задачами и развитая поддержка MCP (Model Context Protocol) — специального протокола, через который ИИ-агенты могут напрямую работать с внешними сервисами и таск-трекерами.

Если подключить его к Claude Code, агенты сами начинают вести в нем задачи: создавать, выполнять, выносить в бэклог. 

Но были и ограничения:

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

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

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

На это ушло немного времени, зато в результате ИИ-агенты получили доступ ко всем привычным инструментам. 

Все, что умеет API Кайтена, умеет и MCP-сервер: создавать карточки и подзадачи, писать комментарии, менять типы карточек, добавлять и менять участников, проставлять теги. ИИ-агенты работают на доске как обычные программисты.

Сейчас для таких задач можно использовать и Kaiten CLI Community Edition — открытую разработку одного из участников комьюнити Kaiten. Через CLI LLM-агенты могут работать с Кайтеном из терминала: получать доступ к карточкам, комментариям, участникам, тегам и другим данным. Поэтому на его основе можно выстроить похожую работу агентов с доской без собственного MCP-сервера.

→ Инструкция по работе с CLI

Как устроена система: стандарты, реестр агентов и сборка команды под задачу

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

Стандарты — это жесткие инструкции, как агенту жить и работать. Одни стандарты отвечают за работу с карточками Кайтена, другие — за запуск новых проектов, третьи — за организацию бизнес-процессов. Есть даже отдельный стандарт по созданию новых стандартов, чтобы система развивалась по единым правилам. Игорь написал их вместе с Claude. Вот несколько примеров:

• стандарт работы команды агентов с карточками Кайтена — как двигать карточки по IT-потоку;

• стандарт создания агентов — как собрать нового агента под задачу;

• стандарт обсуждения агентами задач перед началом ее реализации;

• стандарт ведения бизнес-проектов;

• и даже стандарт по созданию стандартов — чтобы система прописывала правила систематически и проверяла сама себя.

Второй элемент системы — реестр агентов (agent registry). Это библиотека ролей, из которых потом собираются проектные команды. В ней есть аналитик, бэкендер, фронтендер, тестировщик, маркетолог, DevOps-инженер, критик, прототайпер и другие специалисты. Есть даже агент для подготовки презентаций — он помогает со структурой и придумывает шутки для выступлений. В общей сложности сейчас в реестре около 12–13 ИИ-агентов разных специализаций. 

Дальше из этого реестра собирается команда под конкретную задачу: Выглядит это так:

1. Игорь создает в Кайтене одну основную карточку с описанием задачи.

2. Просит агента сходить в Кайтен, прочитать нужный стандарт и собрать команду.

3. Агент по типу задачи (продуктовая или разработческая) читает нужный стандарт, идет в реестр агентов, берет шаблоны и достраивает их под контекст — подтягивает только те навыки, что нужны именно здесь.

Например, для разработки MVP он может собрать аналитика, бэкендера, фронтендера, тестировщика и DevOps-инженера. Для маркетингового исследования — маркетолога, аналитика и критика. Каждый получает только те инструкции и навыки, которые нужны именно в этом проекте.

Агенты спорят, критикуют и возвращают задачи на доработку

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

Для бизнес-задач обязательно подключается критик. Лид готовит план работы, критик его критикует, и все обсуждение фиксируется в папке проекта и складывается в конкретные артефакты: PRD (Product Requirements Document), ADR (Architecture Decision Records).

Случаются и другие ситуации:

• если агент не знает, что делать, он выносит задачу в бэклог, а не выдумывает решение;

• тестировщик не принимает результат, если видит непройденные тесты — двигает карточку обратно в работу и зовет того агента, что ее делал;

• работа идет итерационно: пока фича не закрыта, к следующей не приступают.

Один из примеров на практике Игоря — работа над неймингом компании. Один агент предложил названия. Критик возразил: сначала сходи проверь, не зарегистрированы ли уже такие товарные знаки. Агенты сходили в ФИПС, проверили защищенные и незащищенные знаки — и Игорю на выходе не пришлось ничего делать.

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

Еще один пример — создание маркетинговой стратегии.  Для нее Игорь отдельно загрузил агентам методологию Александра Бындю. Это подход к проектированию стратегии через сегменты, гипотезы, каналы, метрики и ограничения — то есть задача раскладывается как система, а не сводится к списку идей для продвижения.

Агенты сначала изучили методологию, выделили целевые сегменты, определили метрики успеха и приоритизировали каналы. А потом начали искать слабые места в собственных выводах.

И нашли. Выяснилось, что у проекта нет ни четко описанной ценовой политики, ни лендинга, который конвертирует посетителей в заявки. Более того, критик прямо указал: пока не решены эти вопросы, заниматься контент-планом преждевременно.

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

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

Бэклог как страховка от «бесконечной гонки»

Чем больше задач выполняли агенты, тем быстрее росла другая проблема — незавершенная работа. Ее тоже нужно было где-то хранить и контролировать. Что-то оставалось недоделанным, что-то откладывалось «на потом», а общий объем работы терялся из виду. 

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

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

За счет этого одновременно можно вести несколько проектов, не пытаясь держать все детали в голове. Пока агенты работают над одними задачами, Игорь занимается другими. Бэклог при этом работает как страховка от «бесконечной гонки», когда кажется, что все нужно успеть сразу.

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

И это не единственное место, где Игорь сохранил ручной контроль.

Что Игорь все еще делает руками

Полностью из процесса человек не исчезает. Изменилась его роль: вместо постоянного исполнения задач Игорь выступает координатором.

Теперь Игорь:

• создает основную карточку проекта;

• подключается на этапе создания проекта;

• принимает HTML-прототип, оставляет правки и при необходимости превращает их в новые задачи.

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

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

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

Скорость система считает сама

В Кайтене Игорь использует учет времени по карточкам, поэтому статистика собирается автоматически. Можно посмотреть, сколько задача провела в очереди, сколько — в работе и когда была завершена.

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

Если собрать эти данные за период, картина становится нагляднее. Вот что показала доска Игоря за 10 дней — с 1 по 10 июля 2026:

• 12 проектов прошло через AI-команду: 3 IT-проекта и 9 бизнесовых;

• ~218 карточек заведено, из них закрыто ~207;

• фич — 24 (23 готово), Dev-задач — 107 (106 готово),

• Test-задач — 23 (все готово), 

• бизнес-задач — 52 (50 готово), 

• PRJ-карточек — 12.

Скорость по таймстампам Кайтена выглядит так: Dev-задача проходит путь от «В работе» до «Готово» за 6–20 минут, а фича целиком — с декомпозицией, разработкой и тестированием — за 1–3 часа.

Рекорд — MVP «ЧМ-Прогнозы»: 9 фич, 17 Dev-задач и приемочные тесты за один рабочий день. Бизнес-прототип той же игры (10 задач и ревью критика) занял ~1,5 суток.

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

По наблюдениям Игоря:

• один серьезный проект укладывается примерно в 4–5-часовой лимит;

• в начале недели расходуется около 45–50% недельного лимита.

Из-за этого он перешел на тариф Claude Code x20.

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

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

Что Игорь хочет улучшить дальше

Система еще далека от финального состояния. Игорь рассматривает ее как постоянно развивающийся эксперимент и уже планирует несколько следующих шагов:

• оценку задач в токенах — отдельное поле в карточке, чтобы планировать недельный лимит;

• стандарт тегирования — пока теги ставят агенты, но единого правила нет;

• мультимодельность — отдать продуктовый ресерч под ChatGPT, разработку оставить за Claude Code, а сверху связать все через OpenRouter и n8n;

• новых агентов — налоговик, бухгалтер и другие роли под бизнес-задачи;

• разобраться с разросшимся бэклогом, который становится все сложнее контролировать.

Если коротко, для Игоря вся эта история — попытка построить AI-first компанию. Сам он признает, что со стороны идея может звучать слишком амбициозно, но пока видит в ней в основном плюсы: рутины стало меньше, а энергии — больше. Правда, освободившееся время быстро заполняется новыми задачами. А то, что не получилось закончить сегодня, остается в бэклоге — к этим задачам можно вернуться позже.