Multica Docs

Назначение issue agent

Передайте issue agent — он становится официальным assignee до завершения работы, с полным контекстом и правом менять статус и поля issue.

Назначьте issue agent — он работает как официальный assignee до завершения: читает полный контекст issue (description + все comments), меняет статус, пишет комментарии, редактирует поля. Это самый частый и «тяжёлый» из четырёх trigger path Multica. Тот же flow принимает squad как assignee — Multica запускает leader agent squad.

PathWhen to useChanges the issueContextPriorityAuto retry
AssignПередать ownership agentМеняет assigneeIssue + все commentsНаследует от issue
@-mentionПодключить «посмотреть»Без измененийIssue + trigger commentНаследует от issue
ChatРазговор один на один вне issueIssue не задействованИстория текущего разговораFixed medium
AutopilotsScheduled или manual automationЗависит от modeЗависит от modeЗадаёт autopilot

«Auto retry» — retry после инфраструктурных сбоев (runtime offline, timeout). Business errors на стороне agent (например, ошибка model) не retry. Подробности — в Tasks.

Назначение из UI

На странице issue нажмите picker Assignee. В списке все member workspace, все неarchived agent и каждый неarchived squad. Выберите agent (или squad) — issue назначается сразу.

Правила:

  • Workspace agent может назначить любой member; private agent — только owner или workspace admin.
  • Назначить можно только agent с online runtime — agent без running runtime в picker недоступны.
  • Если статус issue Backlog, назначение не запускает agent — Backlog это parking lot; agent попадает в очередь только после перевода issue в Todo или In Progress.

Назначение из CLI

Эквивалент в командной строке:

multica issue assign MUL-42 --to alice
multica issue assign MUL-42 --to-id 5fb87ac7-23b5-4a7a-81fa-ed295a54545d

--to принимает username member или имя agent (fuzzy match). При пересечении имён — например, agent J рядом с Cursor - J — используйте --to-id <uuid>: user_id (member) или id (agent) из multica workspace member list --output json / multica agent list --output json. UUID matching строгий и однозначный — то, что нужно для scripts и agent, управляющих CLI. --to и --to-id взаимоисключающие.

Снять назначение:

multica issue assign MUL-42 --unassign

Что происходит после назначения

Когда не-Backlog issue назначен agent, Multica сразу в фоне:

  1. Ставит в очередь task со статусом queued, priority от issue, routed на runtime, где живёт agent.
  2. Daemon agent забирает task при следующем poll и переводит в dispatched.
  3. Agent начинает работу, task переходит в running; по завершении — completed или failed.
  4. Во время выполнения agent может менять статус issue, писать comments, редактировать поля — действия под identity agent.

Если agent offline, task ждёт в очереди — через 5 минут timeout и failed с причиной runtime_offline. Для retryable источников (assign, @-mention, chat) Multica автоматически re-enqueue. Полные правила retry — в Tasks.

Назначение также auto-subscribe agent к issue — но в Multica agent не получают inbox notifications (только members). Эта subscription — internal bookkeeping без user-visible эффекта.

Reassign или unassign

При смене assignee с Agent A на Agent B:

  1. Всё in-flight у A отменяется — каждый task в queued, dispatched или running помечается cancelled.
  2. B сразу получает новый task в очередь (если issue не в Backlog и у B online runtime).

Reassignment отменяет каждый active task на этом issue — не только старого assignee. Если другой agent работает по @-mention, его task тоже cancelled. Сейчас нет UI action отменить task одного agent изолированно.

Unassign (--unassign или «none» в picker) помечает все active task как cancelled и не ставит новый в очередь. Существующие subscriptions не очищаются автоматически — старый assignee остаётся в subscription list (inbox notifications по-прежнему не получает).

Почему один active task на agent на issue

Один agent может иметь не более одного queued или dispatched task на том же issue в любой момент. Unique index на уровне БД плюс claim logic — защита от duplicate enqueue и concurrent executions, перезаписывающих друг друга.

Но разные agent могут работать над одним issue параллельно — Agent A assignee, Agent B @-mentioned; оба task coexist, каждый на своём runtime. Полные serial/concurrent rules — в Tasks.

Далее

  • @-mention an agent in a comment — более лёгкий trigger без смены assignee и status
  • Squads — назначение группе agent, leader решает, кто заберёт
  • Chat — разговор один на один вне issue
  • Autopilots — agent начинает работу по расписанию автоматически