Как я собрал 10+ ИИ-агентов на Claude Code и Kaiten и почти вышел из операционки

Меня зовут Игорь Кузнецов, я ИТ-директор компании «Эрегион». Мы развиваем ИИ-продукты и консультируем бизнес по внедрению ИИ в рабочие процессы.

Недавно в качестве эксперимента я решил проверить, можно ли полностью передать продуктовые и ИТ-задачи ИИ-агентам. В итоге собрал систему из 13 агентов, которые сами разбирают задачи, распределяют работу, проверяют друг друга и фиксируют результаты.

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

Примечание от команды Kaiten: это личный опыт одного из пользователей сообщества Kaiten. Описанная система работы с ИИ-агентами — собственный эксперимент и инициатива Игоря Кузнецова, а не официальное решение или методология Kaiten.

У вас бывало ощущение, что задач в трекере становится все больше, а контроля над ними — наоборот, меньше?

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

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

Эту гипотезу я и решил проверить на практике. Дальше расскажу, каких результатов удалось добиться за 4 недели.

Почему вообще мне пришла эта идея и первые шаги

В нашей компании мы занимаемся ИИ-консалтингом и разработкой ИИ-продуктов. А с октября прошлого года еще и активно работаем с LLM.

Сначала использовали языковые модели довольно стандартно: ставили задачи в чате и получали результат. Но даже такой простой формат помог запустить первые экспериментальные проекты. Например, LMS-систему, сервис речевой аналитики и другие небольшие продукты.

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

Начали с Linear. По опыту скажу, что Linear — хороший инструмент именно для такой работы с агентами. У него потрясающий MCP-сервер. Это протокол-мост, через который ИИ-агент подключается к трекеру по API и управляет задачами. Можно было локально формировать GraphQL-запросы и через них создавать карточки, менять статусы и обновлять данные.

Но агенты быстро уперлись в два ограничения:

• Лимит карточек. На бесплатном тарифе Linear можно создать максимум 250 карточек. Это и без того небольшой лимит, а с агентами он заканчивается еще быстрее, потому что они дробят фичи на отдельные задачи гораздо активнее человека. 

• Ограниченная кастомизация досок. В Linear можно создавать свои этапы работы, но каждый из них должен относиться к одной из 5 системных категорий: Backlog, Unstarted, Started, Completed или Canceled. Сами эти категории изменить, добавить или переставить нельзя, как и задать набор этапов для отдельного проекта. А у нас проекты разные, и процессы в них тоже отличаются, поэтому хотелось иметь возможность настраивать структуру доски и этапы отдельно под каждый проект.

В итоге Linear так и не взлетел, и мы решили перенести всю эту схему в Kaiten. На тот момент мы были знакомы с системой уже 2+ года — сначала вели там ИТ-проекты, а со временем перенесли туда и бизнес-задачи. Так что разбираться с навигацией и логикой работы нам не пришлось. Кроме того, у Kaiten есть открытый API и практически полная свобода в настройке рабочих процессов.

Если у вас немного проектов и агенты не создают сотни карточек, Linear может быть удобным вариантом для старта. Мы перешли на Kaiten из-за совокупности факторов: более гибкой настройки процессов, отсутствия лимита на количество карточек и потому, что уже использовали его в работе.

Как устроена система: стандарты и реестр агентов

Готового MCP у Kaiten тогда еще не было, поэтому пришлось пойти немного другим путем: собрать собственный MCP-сервер и через него подключить агентов к нашим проектам и доскам с помощью Claude Code. 

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

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

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

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

Потом пришлось объяснить агентам, как именно у нас принято работать

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

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

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

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

• стандарт, по которому агенты обсуждают задачу до начала работы;

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

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

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

Следующий слой — реестр агентов

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

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

Как выглядит запуск проекта

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

Шаг 1. Создаю основную карточку в Kaiten. Там я описываю, что хочу получить, указываю требования и добавляю ссылки на нужные стандарты.

Шаг 2. Передаю задачу агенту. Даю агенту ссылку на задачу и говорю примерно так: «Сходи в Kaiten, прочитай карточку и стандарт, собери команду и запускай работу. Ко мне приходи только с критическими вопросами». 

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

Шаг 3. Агент собирает команду. Сначала он смотрит, что за проект и какие специалисты понадобятся. Затем идет в реестр агентов, берет подходящие шаблоны и адаптирует их под конкретную задачу. Например, для разработки MVP может собрать аналитика, бэкендера, фронтендера, тестировщика и DevOps. А для маркетинговой задачи — маркетолога, аналитика и критика.

Шаг 4. Команда обсуждает, что и как делать. Лид готовит план и передает его критику. Тот ищет слабые места, задает вопросы и при необходимости отправляет план на доработку. То, о чем договорились, агенты фиксируют в материалах проекта и в комментариях в Kaiten.

Шаг 5. Большая задача превращается в конкретные карточки. Например, одну фичу агенты могут разбить на отдельные задачи для бэкендера, фронтендера и тестировщика. Они сами создают дочерние карточки, берут их в работу, двигают по доске и оставляют комментарии с результатами.

В продуктовых проектах есть еще одна фаза. Сначала маркетолог и продуктовый агент делают каркас и ТЗ, а прототайпер собирает HTML-прототип. После того как человек его принял и зафиксировал правки, стартует вторая команда: бэкендер, фронтендер и DevOps. Они локально разворачивают MVP и только после моей проверки делают деплой на сервер. Две четко разделенные фазы снижают стоимость ошибки: дешевле переделать прототип на HTML, чем переписывать готовый бэкенд.

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

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

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

В итоге я получаю уже отфильтрованные варианты и сам в эту проверку не погружаюсь.

Вот еще один мини-кейс с маркетинговой стратегией. Мы отдельно загрузили агентам методологию Александра Бындю и поставили задачу — разработать маркетинговую стратегию на ее основе. Агенты выделили сегменты аудитории, определили метрики и каналы, а затем критик начал искать слабые места. 

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

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

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

Оговорка: это наш внутренний опыт. Результаты зависят от качества вводных и стандартов, которые вы заложили.

Бэклог помогает не держать все в голове

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

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

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

Где в этом процессе все еще нужен я

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

1. На старте — проверяю постановку задачи и направление.

2. На приемке прототипа — смотрю результат и оставляю правки.

3. Перед запуском — проверяю финальную версию и принимаю решение о деплое.

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

Теперь самое интересное — результаты

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

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

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

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

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

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

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

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

По данным из Kaiten, обычная задача разработки проходит путь от «В работе» до «Готово» примерно за 6–20 минут. На целую фичу с декомпозицией, разработкой и тестированием уходит 1–3 часа.

Пока рекорд по скорости у нас установил MVP «ЧМ-Прогнозы». За один рабочий день агенты успели реализовать 9 фич, закрыть 17 задач разработки и провести приемочное тестирование. При этом бизнес-прототип этой же игры агенты собрали за ~1,5 суток. В итоге получилось 10 задач, которые прошли еще и через ревью критика.

На чем система пока спотыкается

Во всей этой схеме Kaiten стал чем-то вроде GitHub для агентной системы. Туда деплоятся стандарты, карточки, результаты и контекст по проектам. При этом сам процесс мы еще не отточили до конца. Система постоянно дорабатывается, и сейчас есть как минимум несколько ограничений, которые нам мешают:

Агенты не умеют оценивать время. Фраза «сделаю за 4 часа» на практике может означать и 5 минут работы, и несколько часов сверх оценки. Поэтому при планировании мы на такие прогнозы не полагаемся.

Токены — главный ограничитель. Команда агентов с критиком и взаимными проверками расходует примерно в 2 раза больше токенов, чем обычный чат с моделью, а при нескольких циклах проверки — уже в 3 раза больше. Из-за этого недельный лимит заканчивается за 2–3 дня, поэтому работа с агентами обходится недешево. Пришлось перейти на более дорогой тариф Claude Code x20.

Следующий логичный шаг — попробовать мультимодельную систему: например, отдать продуктовый ресерч ChatGPT, разработку оставить Claude Code, а взаимодействие между моделями связать через OpenRouter и n8n. Так можно будет не гонять все задачи через одну модель и рациональнее расходовать ресурсы.

Автомод — это риск. Режим полного доверия удобен, но означает, что агент может принять решение, которое вы не ожидали. В нашем случае агент, работая над HTML-прототипом для англоязычного сегмента, самостоятельно убрал весь русский текст и без согласования оставил английский. Формально все логично, ведь аудитория этого сайта не говорит по-русски. Но проблема в том, что такое решение он принял без согласования. Поэтому автомод требует зрелых стандартов и осознанного принятия риска. 

Нет стандарта тегирования. Теги проставляются, но единых правил для них у нас пока нет. Это создает разнобой в фильтрах и поиске. 

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

Один из вариантов решения, который мы рассматриваем, — просить агентов оценивать объем задачи в токенах прямо в поле «Размер» карточки Kaiten. Тогда при планировании будет видно примерную стоимость каждой из них. Можно будет выбирать, что запускать с учетом оставшегося лимита токенов, а что пока оставить в очереди.

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

Вся эта история для меня — попытка построить AI-first компанию

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

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

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

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