GPT-6 Astra Mid-Turn Steering Explained: Update an Agent While It Is Working

Long agent runs create a UX problem: the user notices a wrong assumption but must wait for completion before correcting it. GPT-6 Astra mid-turn steering lets a client send new user input while a response is active. The server transitions from the current response to a successor that incorporates the update.

This is not ordinary chat continuation and not cancellation with a new request. It is a WebSocket protocol with acknowledgments, commit points, and recovery rules.

Requirements and limits

OpenAI documents steering for Responses API WebSocket mode. A client sends a response.steer event containing:

• type: "response.steer";
• previous_response_id, identifying the active response;
• input, containing user-role messages.

The input may include text, image, or file content. Do not add an undocumented stream_id. Steering currently applies to supported standard single-agent modes. Conversation-bound responses and automatic compaction do not support it, so choose between those capabilities during architecture design rather than discovering the conflict in production.

{
  "type": "response.steer",
  "previous_response_id": "resp_active",
  "input": [{
    "role": "user",
    "content": "Use the EU policy version, not the US version."
  }]
}

Understand the lifecycle

response.steer.accepted means the server has accepted responsibility for the steering input. It is not yet the final commit point. The successor response.created event is the commit: persist its response ID and associate the steering input with that successor.

The active response may then end as incomplete with incomplete_details.reason: "steered". That is expected control flow, not an application failure. The successor continues with the update.

Other events matter:

• response.steer.pending: the update is queued because the current response is waiting on client-owned work;
• response.steer.failed: the server could not apply the update;
• no acknowledgment before disconnect: the outcome is unknown.

Build a small state machine instead of handling these as unrelated notifications.

Steering while a tool is running

If the response is waiting for a client tool output or approval, the steer can remain pending. The server cannot safely invent the missing result. Complete the required protocol using appropriate stubs and preserved results, and do not rerun a tool just because steering occurred.

Example: a user steers “do not send the email” while an approval prompt is open. Deny the approval and carry the steering update forward. If the email tool already executed and the acknowledgment was lost, first reconcile the mail system. Steering cannot undo a side effect.

Client state machine

A robust client tracks:

1. active response ID;
2. steering message ID and local status;
3. whether accepted arrived;
4. whether a successor response.created committed it;
5. pending tool calls and approvals;
6. terminal status of the original response;
7. last durable event cursor or application checkpoint.

Disable repeated submission in the UI while still allowing the user to edit or supersede a queued update according to your own rules. Show “Applying your update” rather than pretending the first response instantly stopped.

Recovery from disconnects

Three cases need different handling:

• No accepted event: outcome is uncertain. Reconnect, inspect available response state, and avoid blindly resending a command that could be applied twice.
• Accepted, no successor observed: the server owns the input, but the client lacks the commit event. Recover the response chain before submitting again.
• Successor created: persist that ID and continue from it.

Give steering inputs client-generated IDs in your database even if the wire schema does not use them as protocol fields. This helps deduplicate UI actions and audit what the user changed.

Good and bad use cases

Steering is excellent for changing scope, correcting a source, narrowing a search, adding a missing constraint, or changing desired output while research is still running.

It is not a substitute for approval, transaction rollback, permission checks, or deterministic cancellation. Do not use steering to authorize a payment or to assume that an already-running external action stopped.

Test the awkward transitions

Simulate steering during text generation, hosted tool execution, client tool waits, approval waits, immediately before completion, and during network loss. Verify that tools are not duplicated, accepted input is not silently lost, and the UI assigns output to the correct response.

Track steering acceptance latency, pending duration, successor creation latency, original-response status, duplicated tool actions, and user abandonment. These metrics reveal whether steering actually improves the experience.

Design the user experience around ownership

The interface should distinguish three moments. “Sending update” means the client has transmitted it but lacks an acknowledgment. “Update accepted” means the server owns it. “Continuing with update” means the successor response has been created. Those labels make rare network ambiguity understandable without exposing protocol jargon.

Keep the visible output already produced by the original response, but mark it as superseded if the correction invalidates it. Deleting it can confuse users who acted on what they saw; presenting it as final can be worse. For audit-sensitive work, preserve both branches and show which successor became authoritative.

Debounce rapid edits thoughtfully. Two steer messages—“use France” and immediately “use Germany”—may both be accepted in order. If your product wants only the latest instruction, implement a client policy and communicate it; do not assume the protocol silently collapses updates.

For accessibility, announce state changes without repeatedly reading the entire generated answer. Let keyboard users reach the steering input while generation continues, and keep a clear stop control. Good steering is as much interaction design as transport handling.

FAQ

Is steering the same as sending another message?

No. It updates an active WebSocket response and creates a successor flow.

Does accepted mean the update is fully applied?

No. Treat successor response.created as the commit point.

Can steering cancel an external tool action?

Not reliably. Tool cancellation and side-effect reconciliation are separate application responsibilities.

Can I use automatic compaction with steering?

The official steering guide says automatic compaction is not supported for steered responses. Design an explicit context strategy.

Conclusion

Mid-turn steering makes long GPT-6 Astra work feel responsive, but only when the client respects its protocol. Track accepted, pending, failed, incomplete, and successor events; preserve tool results; reconcile uncertain side effects; and expose honest UI state. Steering changes the agent’s direction—it does not erase distributed-systems reality.