WorkBuddy Practical: 25 - Ensuring Workflow Reliability

Three gates before automation

Not every task should be automated immediately. Use these criteria:

1. The same prompt has been run manually at least three times, with stable quality and format;
2. Triggers, inputs, and acceptance criteria are clear: when it runs, which sources it depends on, and what format it produces;
3. There is an owner, an alert, and a way to disable it: someone handles failures, and the task can be paused without affecting other workflows.

The topic task meets all three: the prompt structure is fixed, it runs at 09:00 each morning, and the output is a list of the day's hot topics.

Tasks whose prompts or data sources are still changing should remain manual until they stabilize.

Configure an automated task in WorkBuddy

After confirming the manual result, tell WorkBuddy in the same conversation:

Set this task up as an automation. Run it at 09:00 every morning and send the result to [specified Lark group / email / WeCom notification].

WorkBuddy saves the current prompt and source configuration as a scheduled task and runs it automatically at the configured time.

Once configured, WorkBuddy calls the five sources at 09:00, aggregates the results, and pushes them. The creator can open the notification and start selecting topics without triggering the task manually.

Design the automation as a state machine

Automation is not simply a matter of making a task “run.” In production, one source may time out, the hot-search list may contain no AI items, the GitHub API may rate-limit the request, or the delivery target may be unreachable.

Design the task as a state machine with an explicit success condition and failure exit for every state:

The key rule is that one failed source should not block the entire task. Mark the missing source and continue aggregation. If delivery fails, retain the result and raise an alert rather than losing the generated content.

Data-source readiness checks

A scheduled trigger does not mean the data sources are ready. At the start of each run, check their availability:

At least three of the five sources must be healthy before producing the trend list. If all fail, enter Blocked, push an alert, and trigger again the next day.

Content quality gates

An available source does not guarantee useful content. Filter the aggregate by:

• Relevance: whether an item belongs to the AI field, excluding general technology noise;
• Timeliness: whether its date is today, preventing old trends from being pushed again;
• Duplicates: whether the same event appears in several sources and should be merged;
• Minimum count: fewer than five valid items means AI trends are insufficient for the day and must be marked.

Quality states are pass (normal output), warning (some sources missing, explained at the top), and blocked (too few valid items, so push an explanation instead of the body).

Output structure

After aggregation, use a fixed structure so the creator can scan and judge quickly:

📋 Daily AI Trend Topics — 2026-07-10

[Today's overview]
Valid items: 18 | Sources: 5/5 | Run time: 09:02

━━━━━━━━━━━━━━━━
🔥 High heat (good for fast trend coverage)
1. [Model name] released, [core capability] — Sources: AIHOT + GitHub
   Heat index: ★★★★★ | Suggested angle: feature review / tutorial

2. [Tool name] open-sourced, [feature description] — Source: GitHub Trending Projects
   Heat index: ★★★★ | Suggested angle: getting-started tutorial / comparison

━━━━━━━━━━━━━━━━
📈 Potential directions (good for deep analysis)
3. [Topic] triggered discussion — Source: WeChat article
   Heat index: ★★★ | Suggested angle: opinion analysis / case breakdown

━━━━━━━━━━━━━━━━
⚠️ Data-source notes
Midu Hot Search: healthy | GitHub: healthy | WeChat: healthy
Multi-engine Search: healthy | AIHOT: healthy

With a fixed output format, the creator can decide on topics within five minutes instead of rebuilding the format every day.

Delivery targets and idempotency

Each run should push its output to a fixed destination:

Idempotency rule: if a run retries after a delivery failure, it must not send content that was already delivered successfully. Generate a unique batch ID for each run, such as ai-hotspot-2026-07-10; record success and skip completed steps during a retry.

Timeout and retry strategy

Retries are for transient faults only, not input or configuration errors.

Resume from a checkpoint

Each run creates a state file recording completed steps and artifacts:

{
  "batch_id": "ai-hotspot-2026-07-10",
  "trigger_time": "2026-07-10T09:00:00+08:00",
  "state": "delivering",
  "completed": ["fetching", "aggregating", "filtering"],
  "source_status": {
    "wechat": "ok",
    "midu": "ok",
    "github": "ok",
    "multi_search": "ok",
    "aihot": "ok"
  },
  "item_count": 18,
  "last_error": null,
  "updated_at": "2026-07-10T09:02:14+08:00"
}

If delivery fails, resume from delivering instead of fetching and aggregating again.

Alerts must be actionable

An automation failure alert must contain enough information for the recipient to decide what to do immediately:

⚠️ AI trend-topic task alert

Batch: ai-hotspot-2026-07-10
State: Blocked
Trigger time: 09:00
Reason: all data sources returned empty results or timed out
Completed steps: fetching (partially failed)
Impact: today's trend list was not generated or delivered

Suggested actions:
1. Check the status of each data-source API
2. If the failure is temporary, manually trigger one rerun
3. If today's run should be skipped, confirm and mark it handled

Recovery path: WorkBuddy → Automations → Run manually

“The task failed; please check” is not actionable enough.

Degraded delivery

Do not wait for every source when some are unavailable:

• Three or more sources healthy → output the list and note missing sources at the top;
• Two sources healthy → output a simplified list and mark the data as incomplete;
• One or zero sources healthy → do not output the body; push only an explanation and alert.

Degraded results must explicitly show source coverage and must not look like a complete run.

Logs

Record for each run:

• Batch ID and trigger type (scheduled or manual);
• Response status and latency for each data source;
• Number of aggregated and filtered items;
• Delivery target and result (success, failure, or message ID);
• Total duration and error details;
• Run cost (token consumption and API-call count).

Do not put the trend-topic body in logs; this prevents logs from becoming unnecessarily large.

Cost budget

The main costs of the topic task are:

Set a budget limit. If a run exceeds the limit, record an alert and continue, but require confirmation before the next run.

Automation definition template

For the topic task, record the complete definition:

Task name: Daily AI Trend Topics
Trigger: 09:00 every day (workdays)
Condition: no prerequisite check; run on schedule
Prompt: [full prompt text]
Sources: @wechat-article-search / @Midu Hot Search / @GitHub Trending Projects / @Multi-engine Search / @AIHOT
Quality gate: at least 5 valid AI items; at least 3 available sources
Output: structured trend list with sources, heat, and suggested angles
Delivery: [Lark group / personal notification / append to Lark document]
Idempotency: batch ID = ai-hotspot-{date}; mark successful delivery and do not resend
Retries: one retry for source timeout; two backoff retries for delivery; hand other failures to a person
Alert recipient: [personal Lark notification]
Owner: [creator]
Disable: WorkBuddy → Automations → Pause

Pre-launch rehearsal

Before enabling the schedule, manually simulate the following cases:

Enable the schedule only after the rehearsal passes.

Runtime metrics

Once the automation is stable, check these metrics regularly:

• On-time trigger rate: whether the 09:00 schedule fires on time;
• First-run success rate: the share of runs that succeed without retry;
• Source availability: availability rate for each source;
• Valid-item trend: fluctuations in the volume of AI trend information;
• Delivery success rate: share of deliveries that arrive without loss;
• Per-run cost: cost trend over time.

If a metric declines continuously, check whether the corresponding source or delivery configuration changed.

From personal automation to a team service

After the personal task is stable, extend it for team sharing:

Team service requires an owner, runbook, permissions for changing prompts and delivery settings, and a change process in which a new source is tested before activation.

The advanced form of automation minimizes interruptions on the normal path. It does not eliminate people; it finds the right person quickly on the exception path.

Iterating on the topic task

After launch, iterate from actual usage:

Prompt: adjust filters and descriptions based on which items are selected or ignored. After changing a prompt, run it manually three times before saving the automation again.

Sources: replace or lower the weight of a source whose quality or availability remains poor.

Output: adapt the list to selection habits, such as adding a “covered this week” marker to prevent duplicate topics.

Time: adjust the trigger according to actual usage, such as 08:30 or 10:00.

Treat every change as a small configuration release: change, verify manually, then save again. Do not experiment directly in the scheduled task.