You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A thread's queue drains one message per turn (#6885), and thread.steerQueuedMessage steers only the oldest queued message. That's fine for unrelated follow-ups. When the queued messages belong together, the agent handles them separately: it re-plans after each one, and it can act on the first before it sees a later one that changes the picture.
I hit this in two ways:
As the operator. During a long turn I queue notes as they come to me, for example one message per review point while I read the diff. Four notes become four turns.
With threads working together. Worker threads report to a coordinating thread with t3_thread_send. While the coordinator is busy, each report lands in its queue (mode: "queue", or "auto" before the turn is steerable), and again each one gets its own turn.
I'd like two ways to deliver the queue together. Both serve both cases.
1. "Steer all" action
Joins every queued message into one message and steers it into the running turn. The queue is empty afterwards.
Operator: the agent heads the wrong way while I have three corrections queued. Today I either promote them one by one, which gives three steers each landing mid-reasoning, or I copy them into the composer by hand. "Steer all" is one action.
Collaborating threads: I see several worker reports waiting in the coordinator's queue and want it to use them now, in a single update. The coordinating agent could do the same itself.
Places it would go: a button by the queue list, a keybinding next to thread.steerQueuedMessage, the mobile queue sheet, and an MCP tool alongside t3_queue_promote_to_steer. Available only when the provider supports steering, like the existing steer.
2. Batched queue mode
When a turn ends, the next turn gets everything queued so far as one message instead of only the first.
Operator: I keep writing review points during the turn without merging them by hand, and the agent gets them in one turn where it can weigh them against each other. [Feature]: Quote part of an assistant message and batch replies into one turn #6974 makes the same argument for quoted replies: "One turn where the agent sees all four objections together beats four turns where it re-plans after each one."
Collaborating threads: the coordinator waits on workers that finish at different times. Whatever arrived during its current turn reaches it in one next turn.
This has to be a server-side, per-thread option, not part of Follow-up behavior. That setting applies per client and decides how my own messages enter the queue. Batching decides how the queue leaves, whoever filled it, and messages from other threads never go through a client. Per-thread fits because only some threads need it. It could also be settable at t3_thread_launch, so a coordinator starts with it on.
Open questions
Join format: plain separator, or a header per message showing its source (me or a sending thread)? Attachments merged into the combined message?
Per-thread setting, environment default, or both?
Is the mode worth adding, or are "Steer all" plus a "send all as next turn" queue action enough?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
A thread's queue drains one message per turn (#6885), and
thread.steerQueuedMessagesteers only the oldest queued message. That's fine for unrelated follow-ups. When the queued messages belong together, the agent handles them separately: it re-plans after each one, and it can act on the first before it sees a later one that changes the picture.I hit this in two ways:
t3_thread_send. While the coordinator is busy, each report lands in its queue (mode: "queue", or"auto"before the turn is steerable), and again each one gets its own turn.I'd like two ways to deliver the queue together. Both serve both cases.
1. "Steer all" action
Joins every queued message into one message and steers it into the running turn. The queue is empty afterwards.
Places it would go: a button by the queue list, a keybinding next to
thread.steerQueuedMessage, the mobile queue sheet, and an MCP tool alongsidet3_queue_promote_to_steer. Available only when the provider supports steering, like the existing steer.2. Batched queue mode
When a turn ends, the next turn gets everything queued so far as one message instead of only the first.
This has to be a server-side, per-thread option, not part of Follow-up behavior. That setting applies per client and decides how my own messages enter the queue. Batching decides how the queue leaves, whoever filled it, and messages from other threads never go through a client. Per-thread fits because only some threads need it. It could also be settable at
t3_thread_launch, so a coordinator starts with it on.Open questions
Related: #6885, #11912, #6974.
Drafted with AI assistance: Claude Opus 5.5 (
claude-opus-5-5) via Claude Code in T3 Code.All reactions