[uzayer]

Proposes an RFD for steering: sending a message to an Agent while it is still working, so the current turn takes it into account instead of the user having to cancel and resend.

The v2 prompt RFD leaves "queueing, steering, or whether agents insert new prompts while busy" out of scope. This picks that up.

Summary of the proposal (v2 only):

• New agentCapabilities.session.steering: {} capability.
• With it, a Client may send an ordinary session/prompt while the session is running or requires_action. The Agent inserts the message at its next safe point (for example between tool calls), responds with the messageId once inserted, reports a user_message update, and keeps the same foreground work going.
• No new method or request field. Queueing stays in the Client (hold the message until idle).

Open question called out in the FAQ: whether steering should be implicit (any prompt while not idle) or explicit (for example "delivery": "steer").

Prior art: Cursor, Claude Code and Codex "send now" / steer UX, and the OpenAI Responses API response.steer.

Looking for a champion, and happy to prototype this in an adapter and a Client.

[kennethsinder]

Hi @uzayer, I've just revised #1261 to build on session/prompt the way this RFD does, since the v2 prompt lifecycle makes a separate method redundant. The main difference left is your open question: #1261 adds an explicit delivery: "steer" | "queue" field, because the Agent can't tell "stop, wrong file" from "when you're done, also run the tests."

The two RFDs now mostly overlap, so I'd be glad to merge them into one with both of us as authors, whichever PR the maintainers prefer to keep. Let me know what you think.