Summary

When a cron job uses delivery.mode: "announce" but the agent (following a skill/prompt) tries to deliver results via the message tool, both delivery paths fail silently:

1. The message tool send is suppressed (documented behavior: "announce delivery suppresses messaging tool sends")
2. The announce mechanism then sees the agent attempted to send to the same target — and skips delivery to avoid duplicates

Net result: the cron runs successfully, processes data correctly, but nothing is ever delivered to the user. The job reports status: "ok" with deliveryStatus: "not-delivered".

Steps to reproduce

1. Create a cron with delivery.mode: "announce" targeting channel:X
2. The cron prompt references a skill that instructs the agent to post results using the message tool to channel:X
3. Run the cron

Expected behavior

Either:

• The message tool send should work (announce should not suppress it when targeting the same channel), OR
• The announce mechanism should deliver the agent's text output regardless of suppressed message tool attempts

Actual behavior

• Message tool send: suppressed (by announce mode)
• Announce delivery: skipped (duplicate detection sees the suppressed send attempt)
• Result: zero delivery — the run is invisible to the user

Real-world impact

We had an Email Command Center cron running every 30 minutes, Mon-Fri. Out of 40+ runs over several days, only 1 ever delivered to Discord. The cron was triaging emails correctly (creating tasks, classifying orders) but the results never reached the user.

The skill (email-command-center) instructs the agent to "Post to Discord #email" using the message tool. With delivery.mode: "announce", this created the silent conflict.

delivery.bestEffort: true masked the failure — job reported "ok" and "not-delivered" without errors.

Workaround

Switch to delivery.mode: "none" and let the agent use the message tool directly. This matches the pattern used by crons that need rich output (buttons, components, attachments).

Suggestion

1. Announce duplicate detection should not count suppressed sends — if a message tool send was blocked by announce mode, it should not be treated as "already sent" for duplicate detection
2. Document the interaction clearly — the current docs say "announce delivery suppresses messaging tool sends" but don't mention the duplicate-detection side effect
3. Consider a delivery.mode: "prefer-tool" that lets the agent use the message tool directly but falls back to announce if the agent doesn't send anything

Environment

• OpenClaw v2026.3.8
• Ubuntu 24.04 x64
• Channel: Discord
• 40+ runs affected over 4 days before diagnosis