Dust.tt: How to Schedule an Agent to Run Automatically

An agent you have to remember to ask is a tool. An agent that runs on its own is closer to a colleague, and that shift is what scheduling buys you. Dust handles it through triggers, configured inside the agent rather than in a separate automation area.

This guide covers what a trigger is, how to set a recurring schedule, how the plain English frequency actually works, and the parts their documentation currently leaves open. Those open parts matter, so they are stated as unknowns rather than filled in with guesses.

Before you schedule anything, be clear about what a scheduled run is for. The good candidates are jobs where the value comes from regularity: a Monday summary, a weekly check on something that drifts, a daily digest that nobody currently has time to compile.

What is a trigger in Dust?

A trigger is the thing that starts an agent without a human typing a message. Dust's quickstart lists triggers as one of the areas of the agent builder, alongside instructions, knowledge and tools, and settings.

The kind most teams want first is the recurring schedule. An independent analysis of Dust's open-source repository also documents an event-driven trigger type fired by incoming webhooks, so if you need an agent to react to an external system rather than a clock, that route appears to exist. Confirm the current shape in their own documentation before you plan around it.

Where do you set up a schedule?

Inside the agent, in its triggers section, rather than in a global automation screen. That placement is deliberate: the schedule belongs to one agent, so the agent is where you find it.

Dust's scheduling documentation lists four things to fill in. A name for the schedule, the frequency, an optional custom message that gets sent to the agent when it runs, and a timezone which defaults to your own location but can be changed.

Adding a recurring schedule

1. Open the agent in the builder — Schedules attach to a specific agent, so start from the agent you want to run on its own.
2. Go to the triggers section — Dust's documentation places scheduling in a dedicated triggers area within the agent builder.
3. Name the schedule — Give it a name you will still recognise in three months, because this is what you will see in the list of runs.
4. Describe the frequency in plain English — Their docs give the example of every week from Monday to Friday at eight in the morning. Dust interprets the description and builds the schedule from it.
5. Check what Dust understood — The system shows a confirmation of the parsed timing before you save. Read it, because a mis-parsed schedule is silent.
6. Set the timezone and add a message — The timezone defaults to your location and can be changed. The custom message is optional and is what the agent receives when the schedule fires.

That confirmation step deserves more attention than it usually gets. The frequency is interpreted by a language model, which is convenient and also means an ambiguous phrase can produce a schedule you did not intend, quietly, at four in the morning.

Write the frequency the way you would say it out loud to a colleague, then read the confirmation as if you were checking someone else's work. First Friday of each month at two in the afternoon leaves no room for interpretation. Monthly does.

Telling a colleague when something is due is the model we built around at Sistava. You describe the recurring work to an AI Employee in the same sentence you would use with a person, and it checks back with you when the instruction is ambiguous rather than committing to a reading of it.

Can an agent schedule itself?

Yes. Dust's changelog describes a wake-up capability that lets an agent set a reminder for itself inside a conversation, to check back on something, run a recurring task, or wait for a response before continuing.

The agent can set either a specific time, such as checking back in a couple of hours, or a recurring rhythm, and then wakes up and continues where it left off. It is a small feature with a large implication: the agent is no longer bound to the length of one conversation.

Scheduling also changes what a mistake costs. A wrong answer in a live chat gets corrected in ten seconds by the person who asked. The same wrong answer produced at seven every morning quietly accumulates until somebody notices, which is why the first week of any schedule deserves supervision.

What should you schedule first?

Pick a job with a stable input and an obvious tell when it goes wrong. A Monday digest of last week's support themes qualifies, because you will notice immediately if it is empty or nonsense. An automated customer reply does not, at least not first.

• Start read-only. Summaries, digests, and checks are the safe first category because a bad run wastes a minute rather than reaching a customer.
• One schedule per agent to begin. Multiple overlapping schedules on one agent make it very hard to work out which run produced which output.
• Name it for the outcome. Monday support themes tells you what broke. Weekly job one tells you nothing at all.

Watch the first three runs properly. Not the fact that it fired, which is the easy part, but whether the content is something you would have been happy to send yourself. If it is not, the fix is nearly always in the agent's instructions or its data, not in the schedule.

Recurring work is exactly where we started at Sistava. An AI Employee already treats routine work as part of the job, so instead of configuring a trigger you tell it in plain English what should happen and how often, and it handles the rhythm and tells you when something looks off.

If you are building this in Dust, the rule of thumb is simple. Schedule the boring, verifiable jobs first, read the parsed frequency before saving, and supervise the first runs like you would a new hire's first week. That is how a schedule becomes something you trust rather than something you eventually switch off.

Sources

• Dust documentation, Schedules
• Dust documentation, Create your first agent
• Dust changelog, Wake-ups: agents can schedule themselves to continue work later
• DeepWiki analysis of the open-source Dust repository, Trigger system
• Dust documentation, Managing Agents
• Dust documentation, Access Controls and Permissions

Scheduling is the point where an AI tool starts producing work you did not ask for that morning. Start with one small recurring job, watch it properly, and add the second only once you would miss the first if it stopped.