Personal agents in Chat Hub are useful but purely reactive as someone has to open the chat and type. Example of use cases the chat hub currently doesn’t cover:
- “Every weekday at 8:00, summarize my new emails / calendar and drop it in the agent’s thread.”
- “Every hour, check a data source and flag anything unusual.”
- “Every Monday, generate a weekly report.”
While all these use cases could be addressed using a classic workflow starting with a scheduler node, the workflow builder could be a huge limit for non-tech-savvy users. Adding this functionality to the chat hub section of n8n, would greatly improve the usability of the whole section.
This kind of interaction is something users are currently achieving, for example, in Claude Code with Routines, however that’s a vendor lock-in. With n8n chat hub, you can choose whatever LLM you like and have more tools + workflows at your disposal.
## Possible solution
Add an optional scheduler to a personal agent:
- Triggered with a cron expression configured from the personal agent editor UI.
- When due, the agent runs (headless): the run is dispatched server-side and the result lands in a dedicated chat session/thread for that agent, so it shows up in the normal sidebar (allow something like retrieveing\checking past executions)
- Like the whole chat hub, scheduled routines could be a flag to turn on/off for the whole instance
- TBD: Some kind of fail auto-pause mechanism in the case of repeated failed runs
### UX
- A “Routines” editor inside the existing agent modal (cron picker + human-readable “next run” preview).
- An “active routines” badge on the agent card.
## Implementation notes
We have a working end-to-end implementation on a branch and would be happy to contribute it as PR if n8n team is interested and agrees on scope. Key design choices, all following existing n8n patterns:
- **Backend lives in the `chat-hub` CLI module** — new `chat-hub-agent-schedule` entity + repository (registered via the module’s `entities()` hook), REST controller, and a `ChatHubScheduleService`. One DB migration (sqlite + postgres).
- **Scheduler mirrors the existing `agents` module** (`ScheduledTaskManager` + `@OnLeaderTakeover`/`@OnLeaderStepdown`/`@OnShutdown` + idempotent leader-gated `reconcile()` + follower→leader pub/sub `*-changed` command), so it is **multi-main safe** — only the leader dispatches.
- **Headless run reuses the public `ChatHubService.sendHumanMessage(…)`** — no duplicated execution path. Auth is synthesized via `AuthService.issueJWT(owner)` (no self-HTTP call).
- Gated behind an instance-level `chat.schedules.enabled` setting enforced both on the API and in `reconcile()`.
- DTOs added to `@n8n/api-types`; i18n strings added to `@n8n/i18n`.
- Tests: unit (service, repository, controller), CLI integration/e2e, and a Playwright e2e for the full dispatch flow.
Rough size: ~backend + frontend + tests, split into focused commits; we’d break it into small, reviewable PRs (entity+migration+API types → backend endpoints/service → editor UI → e2e) rather than one monolith.
Happy to adjust the design to your roadmap before writing any PR. Thanks!