[Bug]: Subagent delegation incorrectly triggers completion notifications and unread status

[ElliotDrel]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

Notifications, unread-thread state, provider lifecycle, and subagent orchestration

Steps to reproduce

1. Start a thread in which the primary agent delegates work to one or more subagents.
2. The primary agent temporarily stops or waits while the delegated subagents continue working.
3. Observe T3 Code's notification and thread state.

Expected behavior

Delegating to active subagents should still count as the overall agent run being in progress.

While any delegated subagent is still running and the primary agent is expected to resume afterward:

• T3 Code should not send a completion notification.
• The thread should not be marked unread merely because the primary agent temporarily stopped or entered a waiting state.
• The thread should continue to show a working/running state.
• The UI may show that the primary agent is waiting on subagents, but it should not imply that the user's attention is required.

A notification and unread state should occur only when the overall run has actually settled, requires user input or approval, encounters an error requiring attention, or otherwise reaches a meaningful user-facing stopping point.

Actual behavior

When the primary agent stops working in order to delegate to subagents, T3 Code treats that intermediate state like the agent has finished:

• it sends a notification;
• it flags the thread as unread;
• but the delegated subagents are still working and the primary agent may continue afterward.

This creates false completion alerts. I open the thread expecting finished work, only to find that the run is still in progress.

Why this matters

Notifications and unread indicators should mean that something new is ready for me or needs my attention. Triggering them during internal delegation makes those signals unreliable, especially when several long-running threads are active remotely.

It also creates repeated interruptions during one logical run: the user may be notified when the parent delegates, then again when subagents finish, and again when the parent produces the actual final response.

Suggested state model

Treat the parent agent and its delegated subagents as one logical run for attention and completion purposes.

Possible states could include:

• Running: primary agent actively working.
• Waiting on subagents: primary agent paused, but one or more child agents are active.
• Needs attention: waiting for user input, approval, or recoverable intervention.
• Settled: all relevant agents have stopped and the final user-facing result is ready.

Only Needs attention and Settled should normally generate notifications or unread status.

Acceptance criteria

• Starting or waiting on a subagent does not generate a completion notification.
• A thread is not marked unread solely because the primary agent transitions into a subagent-waiting state.
• The thread remains visibly active while any child agent belonging to the run is active.
• The final notification occurs once, when the overall run settles or genuinely requires user attention.
• Errors, permission requests, and questions that require the user still notify immediately.
• The behavior is consistent across desktop, mobile, web, and remote T3 Connect sessions.
• Multiple nested or parallel subagents do not cause duplicate completion notifications.

Impact

Frequent false alerts and misleading unread state during normal multi-agent workflows.

Workaround

Ignore intermediate notifications and reopen the thread repeatedly to determine whether the overall run has actually finished.