Multica / Collaborate with agents

Assign issues to agents

Hand the issue to the agent, and it will work as the official person in charge until the end - getting the complete context, it can also change the issue status and fields.

View official source Docs index

Assign issues to agents key concepts infographic

Overview

Assign the issue to the agent, and it will work as the official person in charge until the end - it can read the complete context of the issue (description + all comments), and can also change the status, post comments, and change fields. This is the most common and "heaviest" of the four triggering methods of Multica. The same flow also accepts squad as assignee - in this case Multica will trigger the squad leader agent.

Method	When to use	Modify issue	Context	Priority	Automatic retry
Assign	Make the agent officially responsible	Change assignee	issue + all comments	Inherit issue	✓
@ Mention	Let it take a look in the comments	Don’t change it	issue + trigger comment	Inherit issue	✓
Conversation	One-on-one chat independent of issue	Not involved in issue	Current conversation history	Fixed	✓
Autopilots	Scheduled/manual automation	View mode	View mode	autopilot customization	✗

"Automatic retry" refers to retry caused by infrastructure failure (runtime offline, timeout); business errors on the agent side (such as errors reported by the model itself) will not be automatically retried. See Execute Tasks for details.

Assign in the interface

Click the Assignee selector on the issue details page, and all members, unarchived agents, and unarchived teams in the workspace will be listed. Select an agent (or squad) and the issue is assigned immediately.

A few rules:

Workspace Agent can be assigned by any member; Private Agent can only be assigned by its owner or workspace admin
Can only be assigned to agents with online running time - agents that no one is running, the picker will prompt that they are not selectable
When the Issue status is Backlog, the allocation** will not trigger the agent immediately - Backlog is the parking lot, and it will not actually join the team until you switch to Todo / In Progress

Assign with CLI

Equivalent command line operation:

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

--to followed by the member username or agent name (fuzzy matching). If there are members or agents with the same name/substrings of each other in the workspace (for example, agent J next to Cursor - J), use --to-id <uuid> instead: UUID comes from user_id of multica workspace member list --output json or id of multica agent list --output json, which is the only accurate way, especially suitable for scripts and driver CLI of intelligence. --to and --to-id are mutually exclusive.

Unassign:

multica issue assign MUL-42 --unassign

What happens after allocation

After a non-Backlog issue is assigned to an agent, Multica will immediately do the following things in the background:

Enqueue a queued state task, the priority is inherited from the issue, and routed to the runtime where the agent is located
The agent’s daemon takes away the task the next time it polls, and the status becomes dispatched
The agent starts executing, and task is converted to running; after completion, it is converted to completed / failed
During execution, the agent can change the issue status, post comments, and change fields - these actions appear as the agent.

If the agent is offline, task will wait in the queue - If it is not picked up within 5 minutes, it will time out and fail, and the failure reason is runtime_offline. For retryable sources (assignments, @mentions, conversations), Multica will automatically requeue; see Execute Tasks for complete retry rules.

Assignment will also automatically add the agent to the issue's subscription list - but in Multica the agent does not receive inbox notifications (only members receive them). This subscription is internal bookkeeping only and has no visible side effects on the user side.

Change assignor or cancel assignment

When changing assignee from Agent A to Agent B:

Everything running here is canceled——All queued / dispatched / running status tasks are marked cancelled
B is immediately enqueued as a new task (if the issue is not a Backlog and B has an online runtime)

**Changing the assignee will cancel all active tasks on this issue - not just the ** of the old assignee. If another agent is also working on this issue due to @ mention, its task will also be canceled. There is currently no UI operation that only cancels a single agent task.

Unassign (--unassign or select "none" in picker) to mark all active task as cancelled without enqueuing new ones. Existing subscription relationships will not be cleared automatically - the old assignee will still remain in the subscription list (but will also not receive inbox notifications).

Why can only one active task be active for the same issue at the same time?

The same agent can only have one queued or dispatched task on the same issue at the same time. The unique index and claim logic of the database layer ensure this - avoiding repeated enqueueing and concurrent executions from overwriting each other.

But different agents can run independently on the same issue - for example, Agent A is assignee, Agent B is mentioned by @, the task of both can exist at the same time, and each has its own runtime. See Execute Tasks for complete serial/concurrency rules.

Next step

In the comments @ Agent - A more lightweight triggering method, without changing assignee / status
Squad - assign the issue to a group of agents, and the leader decides who takes over
Dialogue —— Chat one-on-one with the agent away from the issue
Autopilots - Let the agent automatically start work at a scheduled time