Follow-up Queue
Line up the next ask without stopping this one
While an agent works, chat gives the next thought two bad options: a locked composer, or a send that lands inside the run it was meant to follow. Follow-up Queue stacks messages above the composer as editable cards that fire in order when the run ends — each with two verbs, after (stay queued) and now (steer the running turn). Mid-Stream Steering is the now half; this is the after. The queue also has to be honest about time: a message written against a state the run has since changed gets flagged stale instead of firing blind, and the queue holds while the agent is waiting on a question.
Framing
The problem
While an agent works the next thought has nowhere to go — the composer is locked or sending interrupts the run, so the user waits and holds it in their head.
The pattern
Stack follow-ups as editable cards above the composer that fire in order when the run ends, each one promotable to steer the running turn now.
Why chat breaks here
Chat has one verb, send, and one timeline, so a message typed during a run either waits outside the product or lands inside the work it was meant to follow.
Risks
A queue written against a state the run then changes fires stale instructions — fix the test, after the test is fixed — unless each item is re-checked before it sends.
Avoid when
Runs finish in seconds, or every follow-up depends on reading the result first.
Use when
Agent runs last minutes and users think of the next task before the current one has finished.
DOPE evaluation
- Directability
- Edit, reorder or delete any queued message, or promote it to steer the running turn with one click
- Observability
- The queue sits above the composer with its order and count visible, so what runs next is never a guess
- Predictability
- Queued messages fire only when the current run ends, in the order shown — typing never interrupts the work in flight
- Explainability
- A queued message the run has overtaken is flagged with the reason — “cart snapshot updated at step 4” — instead of firing blind
In the wild
- OpenAI Codex queued messages (OpenAI) — Captured Sep 2026: a message typed while the agent works parks as a card above the composer with ↳ Steer, delete and a menu — queue by default, steer on demand. Nothing interrupts the run until you press Steer.
- Cursor queued messages (Cursor) — Cursor 1.2 (July 2025): follow-ups typed while the agent works wait until the current task is done; once queued they can be reordered, or started without waiting.
- Claude Code message queue (Anthropic) — Queued entries are listed above the input box. The documented split is the interesting part: a queued message reaches Claude as soon as the running tool calls finish, inside the same turn, while commands wait for the turn to end. Ctrl+Enter sends the queue now; Up takes it back.
FAQ
When should I use the Follow-up Queue pattern?
Agent runs last minutes and users think of the next task before the current one has finished.
When should I avoid the Follow-up Queue pattern?
Runs finish in seconds, or every follow-up depends on reading the result first.
What problem does Follow-up Queue solve?
While an agent works the next thought has nowhere to go — the composer is locked or sending interrupts the run, so the user waits and holds it in their head.
Why is chat the wrong fit for this?
Chat has one verb, send, and one timeline, so a message typed during a run either waits outside the product or lands inside the work it was meant to follow.