Нельзя нормально экспериментировать с agent pipelines

Разные комбинации моделей, harness, skills и стратегий работы остаются личными экспериментами конкретного разработчика.

Нельзя сравнить инженерные процессы

Финальный результат задачи виден. Способ его производства — нет.

Compute фрагментирован по персональным подпискам

Оплаченная вычислительная ёмкость распределена между людьми, а не между задачами.

Нельзя определить реальную стоимость принятого результата

Цена подписки и количество токенов не равны стоимости разработки.

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

Параллельность ограничена локальным runtime

Разработчик может вести несколько задач, но его компьютер не является инфраструктурой для параллельного agent execution.

Task tracker больше не отражает реальный жизненный цикл задачи

Статус «задача у разработчика» скрывает несколько стадий agent execution.

Промежуточные результаты не являются артефактами задачи

Код сохраняется в PR. Но исследование, план, альтернативы и причины возвратов часто остаются в session history.

Разработчики стали менеджерами agent pipeline, но без менеджерской практики

С агентами программист всё чаще не пишет код сам, а делегирует работу, контролирует исполнителя и принимает результат.

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

Реальная человеческая работа не отражается в задачах

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

Фактический исполнитель недоступен другим участникам процесса

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

• QA не может прямо спросить про regression risk.
• Лид не может уточнить у исполнителя, почему выбран такой подход.
• Другой разработчик не может продолжить обсуждение с agent context.

Harness, skills и context недоступны другим разработчикам

Это не только межкомандная проблема. Даже два разработчика внутри одной области часто не имеют доступа к agent stack друг друга.

Нет общей модели доступа, безопасности и ответственности

Agent pipeline может иметь очень разные полномочия: от read-only анализа до доступа к production-инструментам.

• Кто-то даёт агенту только локальный repo.
• Кто-то может дать доступ к shell, секретам, билд-системе или production admin.
• Без общей модели это зависит от личной осторожности разработчика.

Skills не являются общим управляемым активом

Skill влияет на production pipeline, но часто живёт как локальная инструкция, zip-архив, копия в проекте или submodule-репозиторий.

Нельзя воспроизвести и отревьюить неудачную agent session

Когда у разработчика «не получается с агентом», помочь трудно: проблема могла быть в постановке, context, tools, plan, модели или ручном вмешательстве.

• Нельзя увидеть, где именно разработчик ошибся при делегировании.
• Нельзя повторить fail case в тех же условиях.
• Нельзя научить команду на реальном провале pipeline.

Agent memory обучается на личном наборе задач

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

Это не пятнадцать независимых проблем

У локальных проблем повторяется один и тот же паттерн.

Агентская разработка сегодня организована как личный, локальный и закрытый заводик конкретного разработчика

Это финальный диагноз первого акта.

Что должно измениться?

Если root cause в том, что agent stack привязан к отдельному разработчику, следующий вопрос очевиден: как перенести agent execution в общий инженерный процесс?

Multica — платформа агентов

Multica делает работу ИИ-агентов отдельной частью инженерной системы: её можно запускать, наблюдать, настраивать и анализировать.

Runtime

Runtime — это место работы агентов: отдельная машина или worker, на котором запускаются агентские задачи.

Agent

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

Skills

Skills — это общие способности агентов: reusable-инструкции, правила, знания и процедуры для конкретных типов работы.

• общий доступ
• версии
• история изменений
• привязка к агентам
• обновления

Мониторинг работы агентов

Multica показывает, что сейчас происходит с агентами, runtime и задачами исполнения. Это не замена Jira, а слой наблюдения за agent execution.

Issue

Issue — это единица работы внутри Multica. В ней хранится постановка, исполнитель, состояние, комментарии, запуски и все материалы выполнения.

Artifacts и metrics

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

Chat

Issue не обязана быть one-shot. С агентом можно продолжать разговор в контексте конкретной задачи и её истории.

Версионирование agent stack

Если agent pipeline влияет на production-код, его нужно развивать как инженерную систему: с версиями, владельцами и историей изменений.

Agent execution становится объектом системы

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

Следующий вопрос: как встроить это в реальный процесс команды, которая уже живёт в Jira?

В Jira появляются цифровые исполнители

В текущий task flow добавляются аккаунты агентов. Эти аккаунты видны как исполнители задач, а их фактической работой управляет Multica.

У агентов разные роли и уровни

Цифровой исполнитель связан с конкретным agent stack в Multica: model, harness, skills, tools, permissions и runtime policy.

Назначение задачи запускает execution

Когда issue назначается на агентский аккаунт, Jira hook создаёт связанную Multica issue и запускает агента на доступном runtime.

Jira-задача получает execution summary

В Jira нужен короткий понятный результат. Подробности исполнения, traces, metrics и artifacts открываются по ссылке в Multica.

Начать с agent code review

Первый безопасный этап: агент не меняет код, а только анализирует diff и оставляет review как участник процесса.

Перенести локальные agent stacks в Multica

Не надо сразу искать универсального идеального агента. Сначала переносим существующие личные harness, skills и привычные workflows в облачный контур.

Теперь agents и skills можно обсуждать

Когда локальные stacks перенесены в Multica, команда впервые видит, чем они отличаются и что из них стоит переиспользовать.

После сравнения появляется командный pipeline

Когда agents и skills видны, можно договориться, какие профили использовать для разных классов задач.

Агенты помогают синхронизироваться людям

Multica полезна не только для “агент пишет код”. Она даёт общий контур для взаимодействия между разработчиками и командами.

Sprint превращается в очередь execution

Разработчик не запускает две локальные сессии и не ждёт ноутбук. Он отправляет задачи в общий runtime pool и позже принимает результаты.

Агенты не должны наследовать права разработчика

Junior с мощным агентом не должен случайно получить доступ к тому, что опасно менять автоматически: production admin, publish tools, секреты, платежи.

Что нужно поставить

Минимальная инсталляция — это Multica-сервер, Jira integration и набор VDS/workers, на которых будут запускаться agent executions.

Внедрять без революции

Сначала переносим существующее, потом начинаем сравнивать, затем вырабатываем общий pipeline.