Summary

Telegram group turns that require visible replies through the message tool can still emit the generic empty-response fallback after the agent successfully sends the visible reply and ends with NO_REPLY.

Observed shape:

• The Telegram source prompt requires message(action="send") for group-visible output.
• The agent successfully sends a visible Telegram message through the message tool.
• The agent final answer is exact NO_REPLY.
• The Telegram delivery mirror later appends/sends No response generated. Please try again.

Expected

If a turn already has a successful visible message-tool send, and the final assistant payload is intentionally silent, the Telegram delivery layer should consider the turn handled and must not emit the empty-response fallback.

Actual

The turn can be treated as having no visible response because the fallback check only sees the Telegram plugin delivery snapshot/queued-final state. Message-tool-only delivery is outside that lane, so the generic empty-response fallback may fire even though the user already got a visible reply.

Impact

The chat appears wedged or broken after a successful response, which can prompt unnecessary session resets and continuity loss.

Evidence

From a real Telegram group session:

• A user-visible message-tool reply was sent successfully.
• Two subsequent transcript mirror entries used provider openclaw, model delivery-mirror, and text No response generated. Please try again.
• The user reset the session shortly afterward because the turn looked broken.

Local transcript/log paths are intentionally omitted from the public issue; they are available to the reporter if maintainers need private repro detail.

Suggested fix

Treat message_tool_only source delivery as handled when the turn reports successful message-tool sends, even if the normal Telegram delivery lane has no final payload. Also keep exact NO_REPLY final payloads silent in this path.