Bug: DurableAgent + OpenAI Responses API fails on tool calls due to missing required `reasoning` item

[bhuvaneshprasad]

Summary

When using DurableAgent with OpenAI models via the Responses API, any response that includes a tool call fails with an AI_APICallError.

The failure is possibly caused by providerOptions containing only an itemId, e.g. providerOptions.openai.itemId.

This does not happen with:

• OpenAI Chat Completions
• Responses API when itemId is omitted and providerOptions is just an empty object: { providerOptions: { openai: {} } }
• Responses API when providerOptions is removed entirely

---

Error

AI_APICallError: Item 'fc_0402bf2d292dd7ed00697a35fb10e0819ab0098545c4d0d7f5'
of type 'function_call' was provided without its required 'reasoning' item:
'rs_0402bf2d292dd7ed00697a35f76f98819abe1cc9f4e72dd689'

---

Root Cause Analysis

In packages/ai/src/agent/stream-text-iterator.ts, when finishReason === 'tool-calls', tool calls are appended like this:

conversationPrompt.push({
  role: 'assistant',
  content: toolCalls.map((toolCall) => ({
    type: 'tool-call',
    toolCallId: toolCall.toolCallId,
    toolName: toolCall.toolName,
    input: JSON.parse(toolCall.input),
  })),
});

Later, in this commit this logic conditionally adds provider metadata:

...(toolCall.providerMetadata
  ? { providerOptions: toolCall.providerMetadata }
  : {}),

Which results in payloads like:

providerOptions: {
  openai: {
    itemId: 'fc_00d2d30dba352ead00697a3b795b6081958aeedc7ff5fea9a7',
  },
},

For the OpenAI Responses API, providing a function_call item with an itemId appears to require the corresponding reasoning item to also be present in the request (based on the error). However, removing providerOptions entirely works, which suggests this requirement is being triggered specifically by the presence of itemId. Since DurableAgent does not include the reasoning item, OpenAI rejects the request.

---

Environment

• workflow: 4.0.1-beta.48
• @workflow/ai: 4.0.1-beta.49
• ai: ^5.0.118
• Model:

  import { openai } from '@workflow/ai/openai';
  
  openai('gpt-5-mini')

---

Repro

1. Clone the example:
   https://github.com/vercel/workflow-examples/blob/main/flight-booking-app/workflows/chat/index.ts

2. Update the DurableAgent model to:

   import { openai } from '@workflow/ai/openai';
   
   openai('gpt-5-mini')

3. Run pnpm dev and go to http://localhost:3000

4. Send any message that triggers a tool call

5. Results in the error shown above.

---

Expected Behavior

DurableAgent should either:

• Avoid attaching providerOptions.openai.itemId for Responses API tool calls unless the required reasoning item is also included, or
• Automatically include the corresponding reasoning item when forwarding tool calls to the OpenAI Responses API.

---

Impact

This currently makes DurableAgent + OpenAI Responses API unusable for workflows involving tool calls, despite being a supported configuration.

[bhuvaneshprasad]

The providerOptions shouldn't be removed completely. It can be the same providerOptions the user has set in the DurableAgent.

If the user provides providerOptions.openai.previousResponseId then it should be passed as it is.

[bhuvaneshprasad]

This might also be a problem across all OpenAI-compatible models, though I haven’t tested any of them yet.

[bhuvaneshprasad]

Additional Info:

• When a conversationId is passed via providerOptions in DurableAgent.stream(), it works as expected. However, there is currently no API in the ai-sdk to retrieve the conversationId. According to the ai-sdk documentation, we should be obtaining it from the OpenAI Conversations API
• While updating the Responses API to support previousResponsesId, we should also validate that the user does not provide both conversationId and previousResponsesId at the same time.