Routines
A routine is a saved agent set to run on its own, on a schedule you choose. You build and test an agent by hand, then hand it a clock: every morning, every Monday, or every few hours, it runs unattended and leaves its work in your workspace for you to read when you are ready.
Routines live in the AI section, under their own Routines surface (the /ai/routines route), separate from Workflows. Each one points at an agent you already saved and carries that agent’s exact instructions, skills, and permissions. Scheduling adds a timer. It does not loosen anything.
Create a routine
Open the Routines surface in the AI section and create a new routine. A routine needs two things:
- An agent to run. Attach one of your saved agents. This is the job that fires on the schedule. Build and test it first on the Agents page, because a routine runs it exactly as it is.
- A schedule. Pick when it should run (see below).
Under the hood, each routine is a small folder in your workspace, so it is yours, portable, and readable:
.undra/ai/routines/<your-routine>/
ROUTINE.md the routine's definition and schedule
state.json the run record (last run, last result)ROUTINE.md holds the routine’s settings and which agent it runs. state.json is the sidecar that tracks what happened on the last run. You never have to open these by hand, but it helps to know they are real files on your disk like everything else in Undra.
Schedules
A routine fires on one of three kinds of schedule:
| Kind | Fires | Good for |
|---|---|---|
| Daily | Once a day, at a time you set | A morning review, an end-of-day digest |
| Weekly | Once a week, on a day and time you set | A Monday-morning summary, a Friday wrap-up |
| Interval | Every fixed stretch of time (for example, every few hours) | A folder watcher, a recurring catch-all |
A scheduler checks roughly every minute and fires any routine whose time has come.
Closed app, no backlog
If Undra was closed over a scheduled time, the routine does not fire a pile of catch-up runs the next time you open the app. Missed runs are collapsed: it runs once to catch up, not once for every slot it missed. You will not come back to a backlog of duplicate output.
What a routine inherits
A routine runs the agent you attached, with the same instructions, skills, and permissions you set on that agent. Putting an agent on a timer changes nothing about what it is allowed to touch:
- A read-only agent stays read-only on a schedule. It can read your workspace and write a summary or digest, but it has no way to change your existing files.
- A propose-edits agent still surfaces its changes for review. It does not gain the right to silently rewrite your files just because no one is watching.
This is the whole point of setting permissions before you automate: the schedule inherits a safe agent rather than a loose one. If you want to change what a routine can do, change the agent it runs, not the schedule.
Undo is not wired to background runs
The one-click “AI made N changes, Undo” bar applies to interactive chat, not to background or routine runs. If a routine runs a propose-edits agent, review its changes yourself rather than relying on that bar to roll them back. Keep a scheduled writer on a tight leash, or keep it read-only.
Reading the run record
After a routine runs, check what it did instead of taking the result on faith. The run record (the state.json sidecar) tracks when the routine last ran and how that run turned out.
The last-ran timestamp is stamped even when a run fails. That is deliberate: a failing routine does not silently retry over and over in a tight loop. It marks the attempt, waits for its next scheduled slot, and tries again then. So if a routine looks like it stopped producing output, open it and read the last result rather than assuming it is still trying.
The run is the receipt, not the backup
The run record explains what happened on the last run. The notes and summaries the agent wrote are the durable thing you rely on. Treat the run record as the account of what the routine did, and keep the actual items as the result.
Where to go next
- Agents: build and test the agent a routine runs, and set its permissions.
- Build a recurring agent: the full path from connecting a provider to a scheduled, inspectable agent.
- Local-First Trust: why a permission-bounded, scheduled agent is safe to leave running.