Some work should happen even when nobody is looking at the thread.
A reminder to follow up on an open issue tomorrow morning. A daily check for items that need attention. A recurring summary that should arrive in the same place the team is already working. If every one of those jobs depends on somebody remembering to come back and ask again, the system is doing too little.
Scheduled tasks are how Dawn handles that gap. They let an agent run later, or run repeatedly, without someone manually reopening the conversation each time — and the result comes back into the same workspace context the rest of your work already lives in.
What a Scheduled Task Does
A scheduled task stores three things: a prompt, a schedule, and a destination.
When the time arrives, Dawn runs the prompt in the background and posts the result back into the relevant thread or channel. The important detail is that the result lands where the work already lives. You do not have to go to a separate automation product or a hidden job log just to see what happened.
That makes scheduled tasks feel like a continuation of normal Dawn usage rather than a detached background system. You ask for something once, Dawn remembers when it should happen, and the output comes back into the conversation context where it is useful.
Just as important, the posted message is the result of the run, not a noisy trace of every step the agent took to get there. The scheduled task behaves like background work on your behalf, not like a log of raw agent activity. If a scheduled task produces a morning summary, the summary is what the team sees — not the intermediate queries, source reads, or drafts the agent went through to arrive at it.
Reminders and Recurring Background Work
The first pattern is the obvious one: reminders.
If you ask Dawn to remind you tomorrow at 9, or next Friday afternoon, or on the 15th of next month, the prompt is stored and the reminder comes back later in the same conversation context. That is the simplest use of scheduled tasks and still one of the most practical, because it keeps personal follow-ups and team reminders inside Dawn instead of scattering them across separate reminder tools. A reminder to check whether a customer’s issue was resolved can live in the support thread where the original ticket was discussed. A reminder to revisit a product decision next sprint can live in the channel where the decision was made. Nothing has to leave the context that gave the reminder its meaning.
The second pattern is recurring background work.
That might be a weekday morning summary of urgent items, a recurring check on open pull requests or unreviewed tickets, a prompt that surfaces outstanding work items before a daily stand-up, or a regular operational scan that should produce a readable result rather than a wall of alerts. In these cases the scheduled task is not only “remind me later.” It is “run this useful piece of work later and post back what matters” — which is a fundamentally different level of ambition.
A recurring pull request digest is a good illustration of the difference. Instead of someone manually checking open PRs every morning, a scheduled task runs a prompt like “summarise the pull requests in this repository that have been open more than two working days, grouped by author, and highlight anything waiting on review.” The task runs before the team’s stand-up each weekday and posts the summary into the engineering channel. The engineers get a consistent shape of information at a consistent time, without anyone having to remember to ask. When the same pattern is right for a different team, the shape of the prompt and the schedule change, but the mechanism is the same.
That is where scheduled tasks become more than a convenience feature. They let a workspace turn repetitive prompting into durable behaviour — the kind of recurring work that previously lived in someone’s todo list now lives in the workspace itself, and the team stops being the single point of failure for remembering it.
The Destination Matters
One of the better parts of Dawn’s scheduling model is that the delivery destination is inherited from the place where the task is created.
If the scheduled task comes from an ongoing conversation, the result returns to that conversation. If it comes from a channel context, the result goes back there. If you set it up from a Slack DM, the result arrives in the same DM. That keeps follow-up work close to the people and threads that already have the context for it.
This matters more than it first appears. A reminder is not very useful if it shows up somewhere disconnected from the original work. A recurring summary is less useful if the team has to remember a separate inbox for it. By sending the result back to the existing context, Dawn keeps the automation legible — you can scroll up and see why this thing is arriving now, which thread produced the schedule, and what the earlier runs looked like.
The destination also shapes who sees the result. A scheduled task created in a shared workspace channel is visible to everyone in that channel. A scheduled task created in a personal conversation stays personal. The visibility model inherits from the conversation rather than needing a separate permission layer, which means the default is usually right — the result goes to the people who were already in the loop for the original request.
Tasks That Use the Rest of Your Workspace
A scheduled task is not an isolated prompt running in a vacuum. When it runs, the agent has the same workspace context available that it would have in a live conversation.
That means connected sources are in play. A scheduled task that asks the agent to summarise recent activity in a repository reads the live repository at run time, not a stale snapshot. A task that checks for overdue tickets reaches into the ticket system each time it runs. A task that reviews recent entries in a Confluence space or Notion tree picks up the current state of those pages. Nothing needs to be re-plumbed per task — the workspace’s existing connections are what the scheduled run uses.
Memory pages are available too. A recurring support summary can answer from the team’s escalation policy pages. A daily engineering digest can reflect the deployment constraints the team has written down. If a memory page changes between runs, the next run inherits that change automatically — the task does not need to be rewritten to stay current with the team’s evolving context. The shared memory layer is what makes scheduled tasks feel less like scripts and more like a team member returning to the same knowledge base each morning.
Skills are the third piece. Because the agent running the task is the same one you would use in chat, it carries whatever skills are assigned to it — the formatting rules, tone, and checklists that shape its answers in live conversations apply to scheduled runs too. A support summary generated at 8am reads the same way a support summary generated interactively at noon would read, because the same skills are in effect. That consistency is part of what makes the output trustworthy when nobody was watching the run happen.
The practical effect is that you do not need to restate context in the scheduled prompt itself. “Summarise yesterday’s customer issues” is enough when the agent already has access to the ticket system, knows the team’s escalation policy from memory, and has a support skill describing how to format the output. The prompt stays short because the workspace carries most of the weight.
Managing Tasks After They Are Created
Once scheduled tasks exist, you need a way to see what is active and whether it is behaving correctly. That is what the Scheduled Tasks view in Dawn Web is for.
The list shows each task’s title, type, status, schedule, next run time, and last run time. That gives you a quick read on whether the workspace is carrying the right background work and whether anything has quietly stopped moving. A task that has not run in a week despite a daily schedule is visible at a glance — the last run time tells you something has gone wrong without you needing to hunt for it.
Opening a task shows the more detailed view: the prompt it carries, the pattern it follows, the timezone it uses, where it delivers its results, and the history of recorded runs. That history is particularly useful when a task has been running for a while and a team member wants to see how the output has evolved, or trace back to the run that produced a specific earlier message.
When things go wrong, the run history makes that visible rather than leaving teams guessing. If a task has been silently failing, the failed runs are recorded there alongside the successful ones. If something is no longer relevant, the task can be paused or deleted. If a temporary pause should end, it can be resumed without recreating the whole thing from scratch.
That management surface matters because background work should stay visible. Automation that nobody can inspect becomes something teams stop trusting, and a scheduled task that silently stops posting is worse than no scheduled task at all — because the team assumes the work is still happening when it is not. The Scheduled Tasks view is what keeps that from happening.
Good Uses for Scheduled Tasks
The strongest scheduled tasks are the ones that save repetition without introducing ambiguity.
A reminder to revisit an open decision next week is strong because the future action is clear. A daily request to summarise urgent changes in a connected repository is strong because the team wants the same shape of output every time. A recurring operational check is strong when the result should come back as a short answer the team can act on, not as raw telemetry. A Monday-morning digest of what is outstanding from last week is strong because it nudges the team toward the work they already know needs to happen.
The weaker use cases are the ones where the prompt is vague or the destination is unclear. “Check in about the launch” without specifying what “check in” means will produce something different each time the task runs. “Keep me updated on progress” asked into a space with no defined scope will either flood the channel or produce nothing useful. If the future run would still require someone to reinterpret what the original request meant, the task probably needs a better prompt before it becomes useful.
That is why it helps to think of a scheduled task as a future instruction to an agent, not just a timestamp. The time matters, but the quality of the prompt matters just as much. A good rule is that you should be able to read the prompt alone and understand what the agent is expected to produce — no additional context from the conversation where the task was created.
There is a second rule worth applying: can the natural answer fit into the channel or thread where it will land? Scheduled tasks work best when the result is a concise, readable message the team can act on. If the natural answer is a multi-paragraph report, that still works. If the natural answer is “it depends — let me ask you some follow-up questions,” the scheduling model is not the right fit, because there will be no one to answer the follow-ups at the moment the task runs.
Getting Started
The easiest way to start is with a real reminder rather than a grand automation plan.
Ask Dawn to remind you later about something concrete — following up on a customer ticket, checking whether a deploy completed, revisiting a decision on Monday. Then open the Scheduled Tasks view in Dawn Web and look at the task that was created: the title, the schedule, the status, and eventually the result when it runs. That makes the model clear very quickly — the task is a first-class object in the workspace, not a hidden setting.
Once that feels normal, move to recurring work that already happens often enough to be annoying. A daily summary, a recurring follow-up, a weekly rollup of open items, or a routine review prompt is usually the right next step. A useful starting point is to think about the questions the team asks the agent more than once a week — those are the prompts most likely to earn a schedule. If your team already has memory pages capturing policies, runbooks, or decisions, those are exactly the kinds of contexts a scheduled task can lean on without you restating them in the prompt.
The goal is not to automate everything. It is to stop manually re-asking for the work that should already be happening on a schedule.
That is where scheduled tasks pay off: not as an abstract automation layer, but as a way to keep background work inside the same Dawn workspace where the rest of the team’s work is already happening.