Bug / Issue - Some tasks in "Backlog" status got auto activated.

[kushalkaushik]

I noticed that some tasks that were in the backlog status were activated and moved to the “To Do” list. However, I did not touch them. When I checked the logs, I found an agent named Multica prompted my agent.

What is this “Multica”? Why is it sending instructions to my agents?

[kushalkaushik]

@Bohan-J Thought?

[kushalkaushik]

@Bohan-J

This issue has occurred multiple times and is becoming disruptive.

Tasks that are intentionally kept in the Backlog are being automatically activated and moved forward without any explicit action from my side. Based on the logs, these actions appear to be triggered by an internal agent (“Multica”), which is also sending instructions to my agents.

This behavior is problematic for a few reasons:

• Tasks are being activated before they are fully defined or ready to be worked on
• Unintended instructions are being sent to my agents
• It interferes with planned sequencing and prioritization of work

Some of these tasks are deliberately created for future use, and I need to control when they become active. Currently, this automation overrides that control.

Expected behavior:

• Tasks in Backlog should remain inactive unless explicitly triggered by the user
• No instructions should be sent to agents without a clear user-initiated action

Request:

• Clarify what this “Multica” automation is and why it is triggering these actions
• Provide a way to disable or control this behavior

This is affecting workflow reliability, so a fix or clear configuration option would be important.

[Bohan-J]

Thanks for the detailed write-up — you've diagnosed it correctly, and this is on us to fix.

What "Multica" is. It isn't a hidden agent operating in your workspace. "Multica" is the display name we render for any comment generated by the platform itself (system notifications). So the log line you saw was a platform notification, not a separate agent secretly issuing instructions.

Why your Backlog tasks got activated. The trigger is sub-issue completion. When a sub-issue is marked done, the platform posts a notification on its parent issue and wakes the parent's assignee agent so it can advance the parent's plan. That woken agent can then move sibling sub-issues from Backlog → To Do, which then starts their assigned agents. The whole chain can begin from one agent finishing its own sub-task, with no action from you — which is exactly why it looked like things moved on their own. It's an intentional coordination mechanism for agent-orchestrated parent/child task chains, but it should not override Backlog when you're using Backlog as a manual parking lot.

Fix. We've shipped a change so that a parent issue sitting in Backlog no longer receives this completion notification or trigger at all. A parked parent (and the Backlog children under it) now stays inert until you explicitly move it out of Backlog — which matches the expected behavior you described. (#4391)

Next. We're also evaluating a broader, explicit control for the case where the parent is active but you still want its Backlog children left untouched, so you can fully opt out of auto-advancement. I'll follow up here as that lands.

Appreciate the report and the logs — they made this quick to pin down.

[Bohan-J]

Quick update — the fix is now merged to main (#4391) and will go out with the next release.

Once it ships, any parent issue left in Backlog will no longer receive the sub-issue-completion notification or wake its assignee — so a parked parent (and the Backlog children under it) stays put until you explicitly move it out of Backlog. That should match the behavior you expected.

We're still evaluating a broader opt-out for the case where a parent is active but you want its Backlog children left untouched; I'll update this thread when that lands. If you still see unexpected activation after the next release, reply here and we'll dig in. Thanks again for the report.

[kushalkaushik]

@Bohan-J Thanks for explaining the mechanism. I’d really appreciate the ability to completely turn off this automatic advancement feature where moving a Parent Issue or Sub Issue has an impact on other Sub-Issues. Just to be clear, I am happy with the actatied Sub-Issue or Parent Issue to move but only the Issue that is being triggered.

Based on my personal experience, this mechanism is challenging to optimize for everyone because project management practices vary widely. And I can say that cause I led a team built a project management tool a few years ago.

A bit more details of what happened in the current case, I had an activated parent task that’s was In-Progress. However, only three out of the ten sub-issues were activated and moved to the To Do-and then-In-Progress status. Those three sub-issues were marked complete, and I didn't want to activate the remaining seven because there’s still is some work that is blocking those seven before I can activate them. Since I didn’t plan to activate those sub-issues, I didn’t provide specific details about what needs to be done in those sub-issues. They simply remained in the state generated by my agent when they were planned.

As a result, automatically activating these sub-issues not only consumed a significant amount of tokens because they were large tasks that required a lot of input context, which the API connections I’ve already added fetched, but it also generated a lot of output, approximately 40 pages worth, which now needs to be manually deleted, otherwise it will created conflicts when i am actually activating those sub-issues reverses the processing that already plays now lives in the context of those sub-issues.

Now, aside from the complaints, I want to clarify that my parent issue was already in the in-progress status. It was only activated when my sub-issues were marked complete. Once the three sub-issues were marked complete/Done, the remaining sub-issues started processing. Just so you know the exact mechanics of who things played out.

Personally, I would love to completely disable this automatic advancement feature because, as the project manager of Agents, I need to have full control over the project and not have these automatic triggers unless there’s very fine control over them. For example, ClickUp doesn’t have automatic advancement, but you can create automations when certain events occur. So, it might make sense to start in a disabled state, but users can activate these automations if they need them. However, for me, it will only become useful if this functionality has a very fine controlling options. I can’t suggest what those fine controls are right now, but I’m happy to think about them and get back to you if you’d like to know more.

But the easiest way to make this work would be -- Instead of "Multica" triggering the connected issues, just ask the user what would they like to do next. Like asking permission if the other sub-issues should be activated.

Thanks.

[kushalkaushik]

One more question:

You said "Next. We're also evaluating a broader, explicit control for the case where the parent is active but you still want its Backlog children left untouched, so you can fully opt out of auto-advancement. I'll follow up here as that lands."

Does this mean that till this fix is rolled out, I move my parent issues in Backlog to prevent auto advancement of the plan?

[Bohan-J]

Thanks for laying out the exact sequence — that's really helpful, and you're right: your case is an active (In-Progress) parent whose completed sub-issues then advanced the other sub-issues, which is the broader scenario rather than the parked-parent one the first fix addressed.

Immediate workaround that works today (no need to wait for a release): assign the parent issue to yourself (any human member) instead of to an agent. When a parent's assignee is a person rather than an agent, the platform does not post the sub-issue-completion notification and does not wake anything on the parent — so marking some sub-issues done will no longer cascade into activating the remaining ones. You keep the parent in In-Progress and retain full manual control: each remaining sub-issue stays exactly where it is until you move it to To Do yourself.

To answer your earlier question directly: this human-assignee approach is the cleaner stopgap — it works in the current release and doesn't require taking the parent out of In-Progress. (Parking the parent in Backlog also stops it, but only once the merged fix ships, and it costs you the In-Progress state.)

On the product side — we agree with you. We're going to add a configuration option that controls whether this "sub-issue done → notify/advance the parent" automation runs at all, so you can turn it off. We're leaning toward your framing: make this kind of automatic advancement something you explicitly opt into — ideally with finer-grained control and an "ask before activating" confirmation step — rather than something that happens by default. I'll follow up here as that work is scoped.

Really appreciate you taking the time to detail this, including the token and output-cleanup cost — that's exactly the kind of thing the control is meant to prevent.