Content to action
Qubicweb keeps the discovery and trust-education layer lightweight. When you need governed account, commerce, service, or trust actions, continue in the canonical app without losing the article’s source context.
Content to action
Qubicweb keeps the discovery and trust-education layer lightweight. When you need governed account, commerce, service, or trust actions, continue in the canonical app without losing the article’s source context.
Brief points
Key points will appear here once TrustOps condenses this read. Use the source link below if you need the full article immediately.
Most AI agents wait. They sit idle until a human types something, respond, then go back to waiting.
Garudust Agent can be different. With garudust-cron, you schedule tasks using standard cron syntax — the agent wakes up, runs a full LLM loop with all its tools, and goes back to sleep. No human required.
This post shows you exactly how to configure it, with the correct syntax pulled straight from the source.
garudust-cron is a crate within the Garudust workspace. When a scheduled trigger fires, it calls agent.run(task) — the same code path as a user typing a message. The agent has access to all its configured tools: file read/write, terminal, RAG, web search, and anything else you've enabled.
Cron runs as part of garudust-server. There is no separate daemon.
config.yaml — Permanent, survives restarts
# ~/.garudust/config.yaml
cron: jobs: - schedule: "09**1-5" # weekdays at 09:00 (server timezone) task: "Writeamorningbriefingandappenditto~/briefing.md" - schedule: "018**5" # Fridays at 18:00 task: "Summarisethisweek'sgitcommitsandsaveto~/weekly.md"
CronJob has exactly two fields: schedule and task. Nothing else.
schedule uses standard 5-field cron syntax:
┌─────── minute (0–59)
│ ┌───── hour (0–23)
│ │ ┌─── day of month (1–31)
│ │ │ ┌─ month (1–12)
│ │ │ │ ┌ day of week (0–6, Sun=0)
│ │ │ │ │
0 9 * * 1-5
Timezone follows the server process — set your system timezone before starting garudust-server if needed.
# CLI flag — comma-separated "cron_expr=task" pairs
garudust-server --cron-jobs "0 9 * * *=Write morning briefing,0 18 * * 5=Weekly summary" # Or via environment variable in ~/.garudust/.env
GARUDUST_CRON_JOBS="0 9 * * *=Write morning briefing"
These take precedence over config.yaml when both are set.
Once the server is running, you (or any admin) can create jobs live by asking the agent:
You: Create a cron job that runs every day at 7am to check disk usage and send me an alert if any partition is above 80%. Agent: [uses cron_create tool] Created cron job 'disk_check' with schedule: 0 0 7 * * *
Note:
cron_createuses 6-field cron syntax (seconds first):sec min hour dom month dow
This is different from the 5-field syntax inconfig.yaml.
| Format | Where used | Example |
|---|---|---|
| 5-field |
config.yaml, --cron-jobs, env var |
0 9 * * 1-5 |
| 6-field |
cron_create tool at runtime |
0 0 9 * * 1-5 |
Runtime jobs are not persisted — they disappear on server restart. Add them to config.yaml for permanent schedules.
Manage runtime jobs:
You: List all active cron jobs.
Agent: - [disk_check] schedule: 0 0 7 * * * task: Check disk usage... created: 2025-05-21 07:00 UTC You: Delete the disk_check job.
Agent: Cron job 'disk_check' removed.
CronConfig has two extra fields specifically for automatic memory housekeeping:
cron: jobs: - schedule: "09***" task: "Morningbriefing" # Consolidate and deduplicate memory entries memory_consolidation: "03***" # daily at 03:00 # Expire stale memory entries (based on memory_expiry settings) memory_expiry: "04**0" # weekly on Sunday at 04:00
These run lightweight maintenance tasks — no LLM call required.
cron: jobs: - schedule: "08**1-5" task: > Write a morning briefing covering: (1) any new files in ~/inbox/, (2) a summary of yesterday's ~/logs/app.log errors, (3) today's date and day of week. Save the result to ~/briefing/$(date +%Y-%m-%d).md.
cron: jobs: - schedule: "*/15****" # every 15 minutes task: > Check /var/log/app/error.log for entries in the last 15 minutes. If there are more than 10 errors, append a summary to ~/alerts/errors.log.
cron: jobs: - schedule: "017**5" # Fridays at 17:00 task: > Run git log --since="1 week ago" --oneline in ~/project/, summarise what changed by area, and save to ~/reports/weekly.md.
Cron jobs have no built-in delivery mechanism — the agent writes to files or uses tools. To send to Telegram, write it into the task prompt:
cron: jobs: - schedule: "09***" task: > Write a morning briefing (top 3 priorities for today, weather summary). Then send it to Telegram chat ID 123456789 using the send_message tool.
The agent calls send_message itself. The chat ID must be hardcoded in the task or retrievable from a file the agent can read.
If you want to prevent the agent from creating or deleting jobs at runtime, disable the toolset:
disabled_toolsets: [cron]
Config-file jobs still run — only the cron_create / cron_list / cron_delete runtime tools are disabled.
config.yaml |
--cron-jobs / env var |
Runtime (cron_create) |
|
|---|---|---|---|
| Cron syntax | 5-field | 5-field | 6-field (sec first) |
| Persists across restarts | ✅ | ❌ | ❌ |
| Requires restart to activate | ✅ | ✅ | ❌ |
cron_list shows it |
❌ | ❌ | ✅ |
Start with config.yaml for anything you want running reliably. Use runtime jobs for experiments or tasks you only need for the current server session.
Spot something off?