DurableAgent should preserve reasoning content in conversation history across tool loop steps #1393

Activity

1. gr2m

   added a commit that references this issue on Mar 18, 2026

   Preserve reasoning content in DurableAgent conversation history

   ...

   This issue will close once commit df4c22b is merged into the 'main' branch.

   df4c22b
2. craze3 commented on Mar 29, 2026

   

   craze3

   on Mar 29, 2026

   Contributor

   More actions

   I hit what looks like the same root problem in a real multi-step DurableAgent run with openai/gpt-5.4 and high reasoning.

   What I observed:

   • long tool-call loop
   • repeated finishReason: 'tool-calls'
   • later finishReason: 'error'
   • log: Error processing UI message chunks: Error: [object Object]

   After digging locally, this lines up with the current behavior where DurableAgent does not preserve reasoning content across tool-loop steps, while OpenAI reasoning models still appear to depend on that continuity.

   I also confirmed the published package still has:

   • do-stream-step.js: error instanceof Error ? error.message : String(error)
   • stream-text-iterator.js: the OpenAI itemId sanitization path with the comment about reasoning items not being preserved

   So from my side this issue is not just theoretical:

   • there is still a real failure mode on long reasoning/tool-call runs
   • when it blows up, downstream consumers only get [object Object], which makes the actual cause hard to diagnose

   I’ve worked around it locally by disabling provider-level reasoning for Workflow chat turns on GPT-5.4, but that is not a real solution 🙃
3. VaguelySerious

   closed this as completedin #1444on Apr 3, 2026
4. iNishant commented on May 14, 2026

   

   iNishant

   on May 14, 2026

   Contributor

   More actions

   Heads up: the same class of bug as this issue exists for assistant
   text content emitted alongside tool calls, and was not fixed by
   #1444.

   In stream-text-iterator.ts, the finishReason === 'tool-calls'
   branch builds the assistant ModelMessage from reasoningParts +
   toolCalls — text parts from step.content are still being dropped:

   // stream-text-iterator.ts (current)
   if (finishReason === 'tool-calls') {
     const reasoningParts = (step.reasoning ?? []).map(...);   // ✅
   fixed in #1444
     conversationPrompt.push({
       role: 'assistant',
       content: [
         ...reasoningParts,
         ...toolCalls.map(...),                                  // ❌
    no text parts
       ],
     });
     ...
   }
   else if (finishReason === 'stop') {
     // Add assistant message with text content to the conversation
     const textContent = step.content.filter((item) => item.type ===
   'text');
     if (textContent.length > 0) {
       conversationPrompt.push({ role: 'assistant', content:
   textContent });
     }
     ...
   }

   The 'stop' branch correctly carries text forward, and the AI SDK's
   own toResponseMessages() includes both text and tool-calls in the
   same assistant message
   (ai/src/generate-text/to-response-messages.ts). The 'tool-calls'
   branch is the only place this divergence remains.

   Repro

   Prompt an agent to (a) call a tool, and (b) emit text alongside the
   tool call ("explain what you're about to do" + todo_write).
   Anthropic emits a text block followed by a tool_use block in the
   same assistant turn — both are present in step.content. On the next
   step, only the tool-call shows up in the conversation prompt; the
   text is gone.

   Concrete symptom we hit: model emitted intro text + todo_write on
   step 1, then on step 2 (with its own prior text invisible to it)
   started the entire task over from scratch, duplicated the intro,
   and ran into maxOutputTokens on what should have been a short
   follow-up turn.

   Suggested fix

   Mirror the 'stop' branch / toResponseMessages() — one extra spread:

   const textParts = (step.content ?? []).filter((item) => item.type
   === 'text');
   conversationPrompt.push({
     role: 'assistant',
     content: [
       ...textParts,
       ...reasoningParts,
       ...toolCalls.map(...),
     ],
   });

   Note: step.content is built by chunksToStep() as [{type:'text',
   text: }, ...toolCalls], so the ordering above is the only
   ordering available — original streaming interleaving of text →
   tool_use → text → tool_use is already collapsed before this code
   runs. Preserving full interleaving would require a separate change
   in chunksToStep.