Scheduling tasks

Scheduling is a set of reserved tools the agent can call. Enable it in your project settings and four tools become available to the model: schedule_task, list_scheduled_tasks, update_scheduled_task, and cancel_scheduled_task. You do not wire anything up. The agent decides when to use them from what the user asks.

There is a second step, and it is the one people miss. A scheduled run may only use write tools that were pre-authorised for it, and the pool it can draw from is the project's writable tools list, which starts empty. Until an admin adds tools to it in the console, no scheduled task on the project can be given a write action. Enabling scheduling alone gets you tasks that can read, summarise and report, and nothing else.

Project defaults, all editable in settings:

Users do not fill in a form. They just say what they want, and the agent turns it into a task.

"Every weekday at 9am, check my open orders and message me if any are stuck."
"Remind me to review the Q3 numbers next Monday morning."
"Run the weekly summary every Friday at 5pm my time, but only for the next month."

Under the hood each of those becomes a scheduled task with a schedule, a timezone, and a run cap.

Creation is validated before anything is stored, and each refusal comes back to the model as plain text it relays to the user:

There is no date picker. The agent reads the user's sentence and resolves it — so it needs to know what time it is and where the user is. Agentifys tells it, on every turn:

One asymmetry is worth knowing before a user asks for it. A recurring task can be moved to another timezone on its own, because the cron expression is a local time. A one-off task cannot: it was stored as an absolute instant, so the original local time is gone, and the agent is told to ask for a new run_at as well.

When a task fires there is no browser open and no user typing. The run is executed as the owning user, with their private knowledge and their vault credentials. It is close to being them, but it is not the same as them being present, and the gap is where the surprises live.

Carried into the run:

Results do not vanish into a log. A successful run is held and surfaced to the user on their next live turn, so a Friday summary is waiting for them Monday morning. Up to five unseen results are handed to the agent at the start of that turn and marked seen at the same moment — whether or not the agent chooses to mention them. Only runs that finished ok are surfaced this way; a failed run waits in the My-tasks panel instead.

Write actions during a run

Before the model is called, an unattended run is handed a reduced tool list: every tool marked requires confirmation that is not pre-authorised on the task is removed. The model is never offered an action nobody is present to approve, and a pre-authorised write runs straight through with no prompt.

Since the project's writable-tools list starts empty, the practical default is a run with no write tools at all. Nothing errors. The model works with what it has, and finishes with a report saying what it could not do. That run is recorded as a normal, successful one, and the missing write shows up only in the text of the result. Read the result text before assuming a write happened, and check the task's allowed actions if a recurring task keeps producing reports instead of doing the work.

Every attempt writes a run record, and the task's last_run_status and last_error carry the outcome. There are five ways a run ends.

Two more things the engine does on its own. A task whose project has scheduling switched off, or that has dropped out of signed identity mode, is passed over on each tick and waits rather than failing. And if the backend dies mid-run, the task is left running until the next startup, which resets it to active.

The widget ships a My tasks panel where a user can see their scheduled tasks, what ran, and cancel anything they no longer want. Its calendar button appears on its own once the project is in signed mode with scheduling enabled; you can also open it from your own UI with ERA.openTasks(). The panel is backed by the scheduled-tasks API, which you can also call directly with the user's signed identity in the X-Era-User header.

GET lists a user's tasks and results, POST /seen marks results seen (body {user_context}), PATCH /{task_id} pauses or resumes a task (body {user_context, status:"active"|"paused"}), and DELETE /{task_id} cancels one. The panel is per user, so a person only ever sees and controls their own tasks.