Chat-triggered agents get the demos. Time-triggered agents do the work.
The distinction matters. A chat-triggered agent waits for you to ask. A time-triggered agent runs at 6am regardless — pulls your calendar, reads the overnight email, checks whatever monitoring dashboard you care about, synthesizes it into a briefing, and puts it where you'll see it before you're fully awake. The interaction model is different, the failure modes are different, and the value they produce is different. The most useful agents most people actually deploy are scheduled, not conversational.
This is a working guide to building one. Named steps in Hermes, then a portability section because the pattern doesn't require Hermes to work.
What scheduled autonomous agents actually is
A scheduled autonomous agent is an agent that runs on a time trigger — cron, an interval, a specific clock time — with no human present, produces some output, and delivers it somewhere durable. Nobody is watching. If it fails, the failure has to be visible next time someone checks. If it succeeds, the artifact has to survive until the human sees it.
That's a different design from a chat agent. A chat agent gets to ask clarifying questions; a scheduled agent has to have all its context on file already. A chat agent gets to fail gracefully by saying "I don't know"; a scheduled agent has to fail loudly enough that someone notices, but not so loudly it sends 200 error messages while the API is down for maintenance. A chat agent's output is a message; a scheduled agent's output is an artifact — a document, a Slack post, a Notion page.
The good scheduled agents are boring. They do one thing, they do it at the same time every day, and they leave a trail.
What the pattern actually does
- Fires on a schedule — cron string, ISO interval, or a specific timestamp. Not "when the user opens the app."
- Loads durable context — the last time this task ran, what it found, what it decided. Without persistent context, every run is a cold start and the agent can't notice change over time.
- Gathers inputs from MCP servers or APIs. Calendar, email, a set of dashboards, a git log, whatever the job needs.
- Synthesizes — the LLM step, the only part that actually needs a model. Everything before and after is deterministic plumbing.
- Delivers the artifact to a real endpoint: Slack DM, Telegram message, email, Notion page, a file in a Drive folder.
- Records the run — what it saw, what it wrote, when it finished, whether it succeeded — somewhere queryable.
- Alerts on failure with backoff. Three failed runs in a row should notify. One failure at 4am probably shouldn't.
How to build one in Hermes
The Hermes-specific shape has five steps.
1. Write the skill as a markdown file. In skills/morning-brief.md, describe what the agent should do: pull calendar via Google Calendar MCP, overnight email via Gmail MCP, open PRs via GitHub MCP, produce a one-page brief. Include a "context" section naming the memory files to read first, and a "delivery" section naming where the output goes.
2. Register the schedule. Hermes uses cron strings. 0 6 * * * runs at 6am daily. 0 18 * * 5 runs at 6pm Friday. There's no at() for one-offs — schedules are recurring by definition.
3. Bind the MCP servers. Each service the skill uses needs an MCP server in the agent's config. Follow the MCP hygiene checklist: pin versions, scope permissions, verify OAuth handling.
4. Set the delivery target. For a morning brief, Telegram DM or Slack DM is usually right — fast, visible, dismissible. For a weekly report, a Notion page appended to a database is better because it's queryable later.
5. Configure failure alerts. Hermes writes to a runs/ directory. Point that at a monitoring script or a second agent whose only job is "notice if the morning brief hasn't posted by 6:30am."
That's the working shape. Add a /journey review (Hermes v0.18.0) once a week to see what the scheduled agent has been doing without you.
Why it beats a manual workflow
The workflow this replaces is: you open eight tabs, skim four inboxes, glance at a dashboard, and try to hold the resulting picture in your head. The scheduled agent replaces the assembly work, not the judgment. What you get back is the synthesized picture, delivered to the surface you already check.
The subtler win is longitudinal. A scheduled agent that runs every day for six months has six months of state. It can notice "this is the fourth time this week the same alert fired" or "this PR has been open for 40 days and nobody's mentioned it." A human doing the same assembly work daily does not notice those things reliably. The agent isn't smarter; it's just more patient.
Where scheduled agents fail is in high-signal environments. If the underlying data is noisy or the schedule is too frequent, you'll get an artifact that adds work rather than removing it. The fix is to lower the frequency, tighten the input scope, and let the agent be quiet more often than it speaks.
Where this is being built
Hermes is one shape of scheduled agent, and the one this guide is anchored to. But the pattern is portable, and it's worth naming the alternatives.
Trigger.dev is a developer-focused durable execution platform where you write tasks in TypeScript and schedule them with cron. It's more programmer-facing than Hermes and gives you fine-grained retry, backoff, and observability. Good fit when the scheduled agent is one part of a larger application, not a standalone tool.
n8n is a self-hosted workflow automation tool with visual node editing. It has a cron trigger, LLM nodes, and integrations for most of the services a scheduled agent would call. Weaker on the "agent decides what to do" side, stronger on the "workflow runs reliably" side.
GitHub Actions is the free option most people already have. A workflow with a schedule: trigger runs on GitHub's runners at cron intervals and can call an LLM API, produce an artifact, and post it to Slack. Ugly for stateful jobs. Fine for stateless ones.
Home Assistant deserves mention as the non-LLM ancestor of the pattern — a self-hosted daemon that reacts to schedules and events with automations, integrations for everything in the home, and a config file model that predates the agent framework era by a decade. If your scheduled agent's job is "turn off the lights when I leave and text me if it's below freezing," Home Assistant is still the right tool.
How to evaluate a solution
Six checks before you commit a scheduled agent to a real workflow.
How reliable is the scheduler itself? Cron on a laptop that sleeps is not a scheduler. Cron on a $5 VPS with an uptime monitor is. Which one is running your agent?
Does state survive restarts? If the process dies at 5:59am, does the 6am run happen when it recovers, or does it just skip? Ask the docs, then test it.
How does it handle overlapping runs? If the 6am job hasn't finished by 6:15am and the 6:15 job fires, do they run in parallel, does the second one queue, or does it silently skip?
What's the failure alert path? Where do you find out that yesterday's run failed? Not "in the logs if you go look" — where does it actively surface?
Is the schedule version-controlled? A schedule that only lives in a UI can silently change. Prefer a config file in a repo.
Can you dry-run? Before enabling a new scheduled agent, is there a way to run it once on demand and inspect the output? If not, your first production run is your first test.
Scheduled autonomous agents are the least glamorous corner of the agent stack. They're also, quietly, where most of the actual value is.