I’m a big fan of the multi-task feature and love that I’m able to parallelize things. However, I’m finding a few points of friction:
I can’t directly access a subagent in a full window and do things I’d like to such as follow up, enter plan mode, etc
If there’s one task that’s evolved as important or if it’s the last remaining task, the agent continues operating it in the background even after requesting to bring it to the main context window. This is a struggle when it requires entering plan mode and iterating on it.
Multi task works well when there’s an ongoing agent run, i queue the next message, and then click ‘Start multi-task’ on the queued message. However, if I already know I want to start the message i’m about to queue and switch to Multi-task mode before sending it, it actually gets queued and can’t be triggered for ‘Start Multi-Task’
Overall this is a great feature. A few tweaks and having more control over multi-task would be fantastic.
Hey, thanks for the detailed feedback, it’s really helpful.
All three friction points are familiar to us and we’re tracking them internally:
Full-window access to the subagent (with follow-ups and plan mode) is in the backlog as a UX improvement, so the subagent view doesn’t take over the main agent view.
Bringing a background task back into the main context with full interactivity is also on our radar, especially in cases where there’s just one important task left.
Switching to Multi-task mode before sending a message (instead of from the queued state) is about discoverability and CTA timing, and we’ve logged that too.
I can’t share an ETA for these improvements yet. The team is still refining the overall interaction model for multi-task.
If you run into more specific cases while using it, especially around point #2 where the model decides not to bring the task back, please share them here. It helps us understand real-world scenarios.