Follow-ups: offer non-interrupting mid-turn delivery like Claude Code CLI Enter

[thomasdvd]

Problem

I want to add instructions while an agent is working without stopping its current tool calls and without waiting for the entire run to finish. In Claude Code CLI, pressing Enter supports this: the message is delivered after the current tool calls finish, within the same ongoing turn.

In T3, the user-facing choice between Steer and Queue does not give me a clearly equivalent behavior. Queue waits until the run finishes; Steer is an immediate delivery request whose effects depend on the provider and timing. This makes it difficult to know whether adding a message will preserve the work already in progress.

Example workflow

1. Ask an agent to investigate and implement task A.
2. While it is working, send: "Keep working on A. Also launch a second asynchronous subagent for task B and coordinate both."
3. I want the parent to read that addition at its next safe tool boundary, launch B, and continue coordinating A and B.
4. I do not want to interrupt an in-flight operation just to add this instruction, or wait until A's entire run ends before B can start.

The reported session showed the follow-up messages labeled Steer. That screenshot establishes the selected delivery mode, not that the original task or a subagent was actually cancelled. No deterministic reproduction of lost work is claimed here.

Expected behavior

Provide a clearly named non-interrupting mid-turn delivery option, or make the equivalent existing behavior discoverable:

• Let the current tool-call batch finish normally.
• Deliver pending follow-up messages before the next model request in the active turn, rather than waiting for the whole run to finish.
• Preserve running subagents and background work.
• Keep this behavior distinct from an explicit immediate interrupt and from an after-run queue.
• Explain the delivery timing and provider limitations in the composer/settings so "Steer" does not imply the same semantics across providers.

This is about message delivery. It does not require the application to guarantee that a model follows every task instruction.

Evidence and qualifications

• Claude Code's interactive-mode documentation describes ordinary Enter delivering messages after running tool calls finish, within the same turn.
• T3's v0.1.0 release notes expose Steer versus Queue, with Cmd/Ctrl+Enter choosing the opposite of the configured default.
• The inspected Claude adapter offers active steers with priority "now" and attempts to background foreground subagents first. That is source-level evidence, not a claim that every running command is interrupted: [Bug]: Claude Steer waits for a running Bash command to finish instead of reaching the agent #15720 documents steers waiting behind an already-running Bash command, while Agent steers on Claude threads cancel tools and look like user refusals #21895 describes agent-originated steers cancelling tool calls.

Related reports

• Discussion feat: add Steer and Queue follow-up modes alongside Chat/Plan #6684: Steer and Queue interaction model.
• [Bug]: Claude Steer waits for a running Bash command to finish instead of reaching the agent #15720 and [Bug]: Stop silently drops a Claude steer that is waiting behind a running Bash command #15708: human steering behind running Bash commands, and unread steers being lost after Stop.
• Agent steers on Claude threads cancel tools and look like user refusals #21895 and PR fix(server): agent messages no longer cancel Claude tools #21158: non-interrupting coordination for agent-originated messages. This request concerns user-authored follow-ups.

Environment

T3 server 0.1.2-nightly.20261022.3512, macOS arm64. Server version was read from the connected T3 environment on 2026-10-22. The screenshot does not establish the parent thread's provider/model. No browser automation or controlled provider reproduction was run for this report.

[ianrowe12]

A data point for ACP providers, where this gap is wider than for T3's native Claude or Codex providers.

T3's current ACP integration declares no active steering, so for ACP Registry agents Steer cancels the prompt and starts a new one. (Some ACP adapters offer their own extension for this, such as _session/steering in the Claude and Codex ACP adapters, but T3 doesn't use one.) With GitHub Copilot, that cancel kills any background agents still running (#26695, reproduced at the protocol level on Copilot CLI 1.0.105). Copilot keeps session/prompt open while background agents run, so a message sent during that window is either a destructive Steer, or it sits in Queue until every background agent finishes. Neither gives "read it at the next safe boundary".

For providers without a supported non-interrupting route, T3 does control one safe boundary: the result of a call to its own t3-code MCP tool. One provider-neutral shape:

• A message the user designates for non-interrupting mid-turn delivery can go out with the next T3 MCP tool result in that turn, then be recorded in the timeline as delivered mid-turn. Messages queued for after the turn stay queued, so Queue and Steer keep their meaning, in line with the separate mode Follow-up behavior: add a "steer at next tool call" mode #15287 asks for.
• Agents get a small tool that waits for such input, so an agent waiting on CI or a delegated task can pick up new instructions without ending its turn.
• Messages that need a new turn always wait: attachments, a model or mode change, /compact and restart continuations.

Limits: delivery only happens when the agent calls a T3 tool, so this makes in-turn delivery possible, not guaranteed, and the UI would have to say "delivered at the next T3 tool call", not "steered". It also depends on the T3 tools being available to the agent and the agent using them.

A fork has an implementation of this, tested against a simulated provider; I haven't measured how often real agents pick up messages through it. I'm not proposing it as a fix for the whole discussion, only as a possible delivery mechanism for providers that can't take input mid-turn. If maintainers want to explore it, I can write it up as a separate proposal.

— Opus 5.5 with Claude Code, reviewed by GPT 6.1 Sol

[juliusmarminge]

Closing as a duplicate of #15287, which tracks the same request. Please follow along there.