Pazi's whole pitch on scheduled work is that you set it up once and trust it to run. That breaks the moment the result doesn't show up, and over the past two weeks we documented two ways it happens: the routing-inference failure and the bootstrap-latency dropout.

Pazi scheduled tasks now have a three-tier delivery fallback that closes both gaps. If the configured channel disappears mid-run, the run errors before its last step, or every destination is offline, the output still reaches the dashboard. The fix covers new and existing crons, and lands alongside a new pazi-set-cron skill that asks where you want delivery before any scheduled task is created.

Tier 1: resolve at creation

When an agent calls cron.add, the gateway picks a delivery channel before the entry is persisted. Explicit delivery.mode: "webhook" and "none" pass through untouched. systemEvent payloads also skip the resolver, since they don't need a channel.

For everything else, the resolver walks a four-step chain: explicitly set channel, then best configured external (Slack preferred), then the originating session, then the agent's persistent session. The pick is stamped on the cron, so openclaw cron list and the dashboard show where output will land before the first run.

The auto-detected case stamps bestEffort: true. If delivery later fails, the run isn't marked failed; it falls through to Tier 3.

Tier 2: re-check on every fire

The dispatcher re-evaluates the stamped channel against live config on every fire. That heals four cases:

1. Legacy crons created before this resolver existed.
2. Crons whose stamped channel was removed from config since creation.
3. Crons whose stamped channel is now enabled: false.
4. Crons edited between creation and dispatch in a way that re-introduced a webhook / none mode or non-agentTurn payload (the Tier 1 gates re-enforce here).

For cases (2) and (3), the dispatcher clears the dead channel and re-runs the resolver. The persisted record isn't mutated, so flipping a channel back on works without re-creating the cron. Every existing cron picks up this behaviour on its next fire.

Tier 3: enqueue to main chat

If every channel in the chain is unavailable, or the run errors before any channel is reached, the result is enqueued as a system event to the agent's main chat session. The user sees it as a chat message in the agent's main conversation on the dashboard — inline in the thread, not a toast or a separate notifications list.

The trigger is narrow: Tier 3 fires only when the run produced textual output that wasn't delivered. Heartbeat-only acks don't trigger it, so the main session doesn't fill with empty cron pings.

The pazi-set-cron skill

The fallback is the safety net. The new skill is what prevents most fallbacks from being needed in the first place. Before scheduling any task, the agent now asks the user where they want results delivered. Every time, not just on the first cron of a session. The answer becomes an explicit delivery.channel and delivery.to, so the cron has a contract instead of an inference.

The same pattern lands on the goal flow. The set_goal tool takes a deliveryChannel parameter, the tool description tells the agent to ask before filling it, and the frontend uses that value when materializing the goal's recurring check-ins.

Caveats

• Explicit delivery.mode: "webhook" and "none" are never overridden, at creation or at runtime. Caller intent wins.
• Tier 1 and Tier 2 apply only to agentTurn payloads. Internal systemEvent crons skip the chain.
• delivery.channel: "last" and "webchat" aren't deliverable. The pazi-set-cron skill won't produce them; hand-rolled crons that use them are treated as unset.

On the roadmap

A per-cron delivery health timeline isn't there yet. Today's surface is openclaw logs and the system-event channel.

The runtime resolver also has no memory of the user's original preference. If an auto-detected channel is removed from config, the dispatcher rewrites the stamp to the next best, and that rewrite sticks. Re-adding the original channel won't pull the cron back. A "remember original preference" flag is a candidate refinement.

Pazi is an agent building and management platform built on OpenClaw. You can schedule tasks for your agents and have them work autonomously, 24/7. Build your first agent at pazi.ai.