Dawn now has Workflows: agents that run automatically when a connected source emits an event. The most common use is automating pull request review on GitHub and Azure DevOps when a PR is opened or updated, and workflows can also be set up for other supported events from those connected sources.
Until now, Dawn could only help once someone asked. A pull request opens and needs a first-pass review. A PR changes after feedback and should be checked again. A work item changes and someone needs to know whether it affects a plan. These are repeatable moments in the team’s day, and Workflows make them event-driven.
When a supported event arrives, Dawn runs the workflow in the background, records the result, and lets the team open the output when it is ready.
Start With Pull Request Review
The most useful place to start is automating pull request review on GitHub or Azure DevOps.
A workspace owner or manager can open Dawn Web, go to Workflows, create a new workflow, pick the agent and source, choose the pull request opened and updated events, write the review instructions, and enable it. After that, new or updated pull requests trigger the selected agent to inspect the PR and produce a review-style result.
Practical review instructions ask Dawn to look for correctness bugs, regressions, security issues, missing tests, and maintainability problems, using the connected provider context available to the agent: PR details, changed files, comments, linked work items or issues, and CI state where available. Findings come first, ordered by severity. If there are no findings, the result should say that clearly and call out any residual risk.
This does not replace human review. It gives the team a consistent first pass that runs when the work changes, not only when someone remembers to ask for it.
Workflows Respect Agent Access
Workflows use the same access model as normal Dawn conversations.
Connecting GitHub or Azure DevOps is not enough on its own. The relevant source still has to be linked, enabled, and assigned to the agent that runs the workflow. If the agent cannot normally read a repository or pull request source, a workflow does not magically grant that access.
That matters because workflows are automation. A team should be able to create a PR review workflow for one repository without giving every agent in the workspace access to every repository. The source boundary remains explicit.
Run History And Results
Automations are only useful if people can tell what happened.
Dawn keeps workflow run history in the Workflows screen. Each run records the workflow, provider event, subject, status, timing, and step output. If a run fails, the failure stays visible instead of disappearing into a background log. If a run completes, the output can be inspected before anyone turns it into follow-up work.
When a run finishes with useful output, Dawn lets the user start a discussion from that result. That keeps automated work available without making every repository event noisy. For PR review, the automated pass can sit in run history until a teammate needs it; when the review flags something real, the team can open the result as a Dawn thread and continue from the exact output instead of copying text around.
Beyond Pull Request Review
PR review is the most common starting point, but the workflow model is broader.
Current event support includes GitHub pull requests, issues, and Actions runs, plus Azure DevOps pull requests, work items, builds, and pipeline runs. Teams can create a workflow for any of those events with the agent, source, and instructions of their choice.
A good workflow is still narrow. Pick one trigger, one source, one agent, and instructions that describe a repeatable result. For example: summarise new high-priority work items, inspect failed workflow runs, or triage issue comments that mention a release blocker. If the work only happens once, use a normal chat or a prompt command instead.
Handling Event Bursts
Connected-source events can arrive quickly. A PR can be updated several times in a minute; an issue can receive multiple edits and comments; CI can report several state changes in sequence.
Each workflow has a concurrency policy:
- Queue — keep every event and process them in order.
- Skip if running — ignore new events while a previous run is still active.
- Debounce by subject — combine rapid updates for the same subject and run after the debounce window.
For PR review, debounce by subject is the right default, so a quick sequence of commits on the same PR does not create several nearly identical reviews.
Where This Fits
Workflows sit beside Dawn’s existing ways to ask for work.
Use chat for live questions. Use prompt commands when a person is starting a repeatable task with a short brief. Use scheduled tasks for time-based digests and checks. Use Workflows when a connected-source event should start the work.
This release keeps the workflow shape narrow on purpose: no visual builder and no branching yet — both of which arrive with the visual workflow canvas. Workflow steps are agent-run instructions, and completed output is made available in Dawn instead of being pushed everywhere by default. The first version should be understandable, auditable, and safe to enable on real repositories.
Getting Started
Open Dawn Web and go to Workflows. If you already have a supported GitHub or Azure DevOps source connected and assigned to an agent, create a workflow that triggers on pull request opened and updated events for that source. For other use cases, choose any of the supported event types and write the instructions you want the agent to follow.
The setup guide is here:
Workflows are the start of Dawn moving from “ask when you remember” to “run when the work changes.” The first release keeps that simple: connected-source events, agent-run steps, durable run history, and a clean path from automated output back into a Dawn discussion.