Feature request: better support for agent state changes between turns

[hvppycoding]

Summary

I’d like better support for cases where agent state needs to change between turns.

A common example is when the model has already produced tool calls, but before the next turn continues, the application may need to react to something external—such as a newly arrived user message or the need to compact context.

Why this matters

In multi-turn tool-use flows, the SDK often proceeds like this:

user: user_message
assistant: [<tool_use1.1> <tool_use1.2> <tool_use1.3>]
user: [<tool_result1.1> <tool_result1.2> <tool_result1.3>]
assistant: [<tool_use2.1>]
user: [<tool_result2.1>]
assistant: [<tool_use3.1> <tool_use3.2>]
user: [<tool_result3.1> <tool_result3.2>]
assistant: assistant_message

However, in real applications, the outside world may change while the agent is running.

For example, suppose the assistant has already produced <tool_use2.1>, and while that tool is running, a new user message arrives (<user_message2>). In that case, I may want the next turn to reflect both the tool result and the new user input:

user: user_message
assistant: [<tool_use1.1> <tool_use1.2> <tool_use1.3>]
user: [<tool_result1.1> <tool_result1.2> <tool_result1.3>]
assistant: [<tool_use2.1>]
<new user message arrives>
user: [<tool_result2.1> <user_message2>]
assistant: [<tool_use3.1> <tool_use3.2>]
user: [<tool_result3.1> <tool_result3.2>]
assistant: assistant_message

Another case is context pressure. During a long-running workflow, I may need to compact or rewrite the conversation state before continuing:

user: compacted message
assistant: [<tool_use2.1>]
user: [<tool_result2.1> <user_message2>]
assistant: [<tool_use3.1> <tool_use3.2>]
user: [<tool_result3.1> <tool_result3.2>]
assistant: assistant_message

Current limitation

From outside the SDK, this feels difficult to implement cleanly if execution continues automatically from one tool-use step to the next model turn.

What seems to be missing is a clean way for the host application to handle situations where agent state may need to change between turns—for example because of new user input, context compaction, or other external orchestration.

Why this seems broadly useful

This does not feel like a niche case. In practical agent systems, long-running workflows often need to respond to external events instead of continuing turn-by-turn without interruption.

For reference, tools like Claude Code appear to support this style of interruption and continuation, and it has been very useful in practice. I mention this only as a point of comparison—the main request here is to make this kind of workflow possible in the OpenAI Agents SDK.

Thanks for considering this.

[hvppycoding]

Would setting max_turns=1 and repeatedly calling run achieve a similar effect?

[seratch]

Thanks for sharing this. Regarding the user interruption pattern, it is indeed a common need, but this SDK does not yet support the pattern. One potential solution would be to halt the agent loop in the middle (perhaps either a turn of a model call or tool output) and insert the new user message before the final output of the ongoing agent run. We need to make sure if this works well for common use cases.

As for the compaction use case, queueing the upcoming user message within the SDK could be possible, but essentially the compaction needs to be done before proceeding with its succeeding requests.

I don't think max_turns=1 could fit for your need here, but if you find some creative ideas with it or anything else, sharing those with us would be appreciated as well.