Dawn now treats long-running work as a first-class task in the thread. When a request needs more than a few seconds — a deep investigation, a larger artifact, a broad pass over connected sources, a multi-step run — a task badge appears alongside the conversation, the work continues in the background, and you choose when to apply the result. Cancelling, deleting, and clearing finished tasks are all part of the surface, so a long run stops being something the thread has to wait at the bottom for.
The shape this gives Dawn is closer to how teams already work in their other tools. A task that takes a minute does not freeze the experience. A task you no longer want is one click to cancel. A task that produced something useful waits patiently in the rail until you decide to bring the result into the conversation. The thread stays a thread; the work stays work.
Why Long Runs Needed a Place to Live
Most Dawn requests finish quickly. The ones that do not — investigations, larger artifacts, multi-step generations, anything that has to read several connected sources before it can answer — are the ones where the previous experience showed its age. The response was generated inline, the rest of the thread was effectively paused while you watched it run, and if you switched away you had to keep a mental note of which thread was still working.
That model is fine for a single waiting room. It breaks once teams start using Dawn for the kind of work that is genuinely slower than chat: drafting a long HTML artifact, generating a multi-page document, running a broad investigation across connected sources, or working a complex prompt through several tool steps. None of those should hold the rest of the thread hostage, and none of them should require a sticky note next to the keyboard saying “Dawn is still doing the thing”.
Background tasks make that work explicit. The thread keeps moving; the slow piece of work has its own surface; the result lands when you decide it should.
A Task Badge That Stays Out of the Way
The most visible change is the task badge rail in Dawn Web. When a long-running request kicks off, Dawn creates a task and attaches a compact badge to the right side of the thread. The badge shows the task state at a glance — running, complete, failed, cancelled — and expands when you interact with it to reveal the task name and the actions available right now.
The actions are the ones a task list should have, with no surprises. While the task is still running, the primary action is Cancel. Once it has finished, the action becomes Delete, and a completed task that produced a usable result also exposes Apply. Destructive actions use inline confirmation, so cancelling or deleting does not pull you into a separate modal just to clear something out of the rail.
This sounds like UI plumbing, but the effect on the rhythm of the conversation is what matters. Long-running work no longer has to sit at the bottom of the thread asking for your attention. It can keep going while you carry on talking to the agent above it, switch to another thread, or step away from the workspace entirely.
Apply, Don’t Auto-Insert
The second decision worth being explicit about is that completed results are not pushed into the conversation automatically. They wait for you.
When a task finishes, the badge exposes an Apply action. Applying imports the result into the thread and removes the badge. The transcript ends up clean: the task was created, Dawn worked on it, and when the result was something you wanted, it appeared in the conversation at the moment you chose. Nothing slips silently into the middle of an active discussion.
This matters most for tasks that produce artifacts. If you ask Dawn to draft an HTML page or generate a longer document, you probably want to glance at the result before it lands in the transcript. The task lets you do that. If the output is not what you wanted, delete the task and the conversation stays as it was. If it is exactly right, apply it and the transcript carries forward with the artifact attached. Either way, the choice is yours.
The same logic applies in reverse. The task does not vanish just because you stopped paying attention. Walk away for an hour, come back, and the badge is still there, still attached to the thread it belongs to, still ready to apply or delete. Long work survives a closed tab and a new browser session — the task is part of the thread, not part of the page.
Cancellation as a First-Class Action
Long-running work needs a clean escape hatch. A task that stops being useful — because the answer was already obvious from the first paragraph, because the question turned out to be wrong, because the run is heading somewhere unhelpful — should not have to finish before you can move on.
Cancel, on a running task, asks Dawn to halt the work and finalise whatever partial output already exists. The task badge flips from running to cancelled, the partial output stays attached so the transcript is honest about what happened, and the thread is free for the next message. Cancelling one task does not affect any other; tasks are scoped per thread, and a thread can have several in flight without them stepping on each other.
For tasks that involve writes — anything that changes the state of a connected source or schedules follow-up work — Dawn cleanly closes whatever step it is currently running and reports what was and was not completed. The result is a transcript that tells an accurate story of the run, not one that quietly hides what the agent had already done.
This pairs with the existing cancellable and parallel threads work. Threads run in parallel; tasks within a thread run in the background; either layer can be stopped on its own without disturbing the other. The cancel action does what you would expect at whichever level you press it.
Cleanup Without Erasing the Conversation
As a thread accumulates completed, failed, and cancelled tasks, the rail can fill up with badges that no longer need attention. The cleanup action at the top of the rail handles that.
Cleanup removes finished tasks — completed, failed, or cancelled — and leaves anything still running alone. It does not touch the conversation transcript itself. The messages, the prompts, and any results you already applied stay exactly where they were. What disappears is the rail furniture for tasks whose work is already done. The thread becomes easier to scan again, and any new task that starts after cleanup is easy to spot because it is the only one in the rail.
That distinction — cleanup is for the task rail, not the thread — is worth keeping in mind. Applying a result is the action that brings work into the conversation. Cleanup is the action that removes work that is no longer asking for your attention.
Built for the Way Teams Actually Use Dawn
Background tasks pair naturally with how teams have already started using Dawn. A support engineer working a hard ticket may have one thread chasing logs, another drafting a customer reply, and a third generating a follow-up artifact, with several background tasks running across them. A product manager preparing for a planning meeting may kick off a project brief in one thread and three ticket plans in others, then read the answers as the badges flip from running to ready. A platform engineer may ask Dawn to investigate a noisy area of the system and continue editing a memory page in the same thread while the investigation runs.
The previous shape of work was serial: ask, wait, read, ask again. The new shape is closer to how the rest of the team’s work already happens: start the work, let it run, keep moving, and return when there is something to act on. Dawn does not get smarter because of background tasks. It gets less in the way.
What This Does Not Change
A few things are deliberately out of scope. Background tasks do not change what Dawn can reason about — the same agent capabilities, the same connected sources, the same models, the same memory. They do not turn every request into a background task; short answers stay short answers, with no new ceremony. They do not introduce a separate task inbox sitting outside the thread, because a task without a thread loses the context that makes the result useful.
What they do change is how visible and controllable longer work is while it is happening, and how cleanly the result lands when it finishes. That is enough to shift the experience without adding a new product to learn.
Getting Started
There is nothing new to configure. Use Dawn as usual. When a request creates background work, the task appears in the thread automatically — watch the right side of the conversation for the badge.
A task is most useful when you treat it as a piece of work in progress rather than a pending message. Expand the badge to see the task name and current state. Cancel it as soon as you know it is no longer needed. Apply the result when you want it in the conversation. Use cleanup when the rail gets cluttered with finished tasks you no longer need to see.
This release makes Dawn better at the work that does not fit neatly into a single instant reply. Long-running work can now stay visible, cancellable, and useful without taking over the rest of the workspace.