Problem
When a cron job completes successfully but Telegram delivery fails (e.g., 502 Bad Gateway, schema validation error), the job's overall status is reported as error — even though the actual task (LLM execution, tool calls, output generation) succeeded.
This conflates two independent concerns:
- Task execution — did the agent complete the work?
- Delivery notification — did the result reach the messaging platform?
A transient Telegram outage shouldn't make all cron jobs appear broken.
Observed behavior
- Cron job fires, agent runs, produces correct output saved to
$HERMES_HOME/cron/output/<job-id>/<timestamp>.md
- Agent attempts to deliver result via Telegram
- Telegram returns 502 or schema validation error
- Job status flips to
error despite successful execution
hermes cron list shows Last run: ... error — misleading
Impact
- Users see "all cron jobs errored" when only Telegram was flaky
- Retry logic re-runs the entire task (expensive LLM calls) instead of just retrying delivery
- Monitoring/alerting triggers false positives
Expected Behavior
- Task status and delivery status should be tracked independently:
task_status: ok | error
delivery_status: ok | failed | pending
- Delivery failure should trigger retry (delivery only, not the full task)
hermes cron list should show both statuses separately
- Cron output file should be written regardless of delivery outcome (this already works)
Suggested Architecture
cron tick
→ spawn agent session (task execution)
→ task completes → write output file → task_status = ok
→ delivery pipeline (async, non-blocking)
→ attempt Telegram delivery
→ on failure: retry 3x with backoff
→ delivery_status = ok | failed
→ final job state = { task_status, delivery_status }
Current Workaround
SOUL.md instructs the agent to treat delivery failure as non-blocking and to report task/delivery status separately. This is a behavioral workaround; the underlying scheduler still records error.
Environment
- Hermes Agent v0.8.0 (
nousresearch/hermes-agent:latest, arm64)
- Telegram platform in polling mode
- 11 active cron jobs
Problem
When a cron job completes successfully but Telegram delivery fails (e.g., 502 Bad Gateway, schema validation error), the job's overall status is reported as
error— even though the actual task (LLM execution, tool calls, output generation) succeeded.This conflates two independent concerns:
A transient Telegram outage shouldn't make all cron jobs appear broken.
Observed behavior
$HERMES_HOME/cron/output/<job-id>/<timestamp>.mderrordespite successful executionhermes cron listshowsLast run: ... error— misleadingImpact
Expected Behavior
task_status: ok | errordelivery_status: ok | failed | pendinghermes cron listshould show both statuses separatelySuggested Architecture
Current Workaround
SOUL.md instructs the agent to treat delivery failure as non-blocking and to report task/delivery status separately. This is a behavioral workaround; the underlying scheduler still records
error.Environment
nousresearch/hermes-agent:latest, arm64)