Summary

There appears to be a reply-runtime assembly bug in /reasoning on mode.

Current evidence shows that /reasoning on and /reasoning stream do not follow the same effective message path:

• /reasoning stream works as expected in current testing
• /reasoning on can lose the final assistant answer on some channels
• the session transcript still contains the final assistant text
• but the channel-delivered final payload does not

This is most visible on DingTalk AI card delivery. Telegram appears unaffected in current testing, which suggests this is not a universal channel failure but a runtime assembly/contract issue with channel-specific exposure.

Message-path difference

/reasoning on

Reasoning is included in the normal block/final assembly path.

In src/agents/pi-embedded-subscribe.ts, finalizeAssistantTexts(...) only forces final text into assistantTexts in limited cases:

• when state.includeReasoning && text && !params.onBlockReply
• or when !addedDuringMessage && !chunkerHasBuffered && text

So if /reasoning on emits block replies earlier in the same assistant message, the final assistant text may never be inserted into assistantTexts.

Later, in src/agents/pi-embedded-runner/run/payloads.ts, buildEmbeddedRunPayloads(...) prefers assistantTexts over fallbackAnswerText derived from lastAssistant:

• if assistantTexts.length > 0, those are used
• lastAssistant.text is only used as fallback when assistantTexts is empty

That means the transcript can contain the correct final assistant answer, while the assembled reply payload still omits it.

/reasoning stream

Reasoning is streamed separately through onReasoningStream, so the final answer path is less likely to be shadowed by earlier block-reply state.

Telegram also has channel-side draft/preview lanes that seem to compensate for this class of problem, which likely explains why it behaves correctly while DingTalk card exposes the bug.

Why this is a bug

The runtime transcript and the final delivered reply can diverge:

• transcript: contains reasoning + final assistant text
• assembled payload: may contain only reasoning/tool/interstitial text
• channel: receives an incomplete final reply

This breaks channels that rely primarily on the assembled final payload rather than separate preview/draft lanes.

Scope / impact

This does not appear to affect all channels equally.

• Observed broken: DingTalk AI card
• Observed OK: Telegram
• Likely at risk: channels that depend on final assembled payloads instead of partial/draft lane recovery

Related issues/PRs suggest this is part of a broader family of reasoning/block/final-delivery inconsistencies:

• #30804
• #51132
• #29678
• #43885
• #57984

Suggested fixes

Option 1: fix finalizeAssistantTexts(...)

Ensure the final assistant text is preserved for the current turn even if block replies were already emitted earlier in that same assistant message.

Option 2: fix buildEmbeddedRunPayloads(...)

Do not assume assistantTexts.length > 0 means the final answer is already represented. If lastAssistant.text exists but assistantTexts only contain earlier block-derived or interstitial content, merge or replace with the final assistant text.

Option 3: tighten runtime contract

Guarantee that the assembled final payload always includes the final assistant answer, regardless of whether reasoning/tool block replies were emitted earlier in the turn.

Notes

This issue is specifically about /reasoning on. Current evidence indicates /reasoning stream follows a different effective path and is not affected in the same way.