Dawn now has a first-party plugin catalog for connecting workspace tools, choosing exactly what agents can do, and starting workflows from provider events.
Dawn Team
Product Engineering
Dawn now has Plugins: a first-party catalog for connecting the tools your team already uses, giving agents access to the right sources and actions, and starting workflows when supported providers emit events. Plugins bring connection setup, agent tools, and event-driven work into one consistent experience.
A connection is where two questions get decided: what an agent can see, and what it can do. Plugins keep those separate. Connecting a provider gives read access to the sources you link, and every action that changes something is a capability you switch on for the job that needs it.
The plugin catalog covers the systems where product, engineering, support, operations, and marketing teams already spend their time. That includes code and delivery tools such as GitHub, GitLab, Bitbucket, and Azure DevOps; work trackers such as Jira, Linear, and Trello; documents in Notion, Confluence, Google Drive, OneDrive, Dropbox, and Box; design work in Figma and Framer; marketing data from Google Analytics, Google Ads, and Google Search Console; and specialist services such as Mailjet, SendGrid, FourA, and MCP Gateway.
Each plugin guides you through the setup it actually needs. A repository provider can help you link the repositories or projects an agent should use. A document provider can expose selected folders or spaces. An analytics provider can discover the properties or accounts available to the connected identity. You do not have to translate every provider into the same generic connection model.
Once connected, the plugin becomes part of normal Dawn work. Ask an agent to compare a product brief in Notion with open Jira work, inspect a pull request against acceptance criteria, turn current campaign data into a report, or find the latest contract in a linked cloud drive. The provider stays where the source data lives; Dawn uses it when the task needs it.
Plugins distinguish between reading information and changing it. Read access is the natural starting point. Actions that create, update, send, merge, close, or delete something are separate capabilities and can be enabled only when the workflow calls for them.
That matters because useful access is rarely all or nothing. A release agent may need to inspect repositories, pull requests, work items, and pipeline status but never merge code. A support agent may need to read customer context and draft a response without sending it. A campaign agent may need reporting access without permission to edit a live campaign.
The result is a more honest setup: connect the provider, choose the sources, and allow the operations that match the job. Agents do not gain a provider’s entire action catalog simply because a credential exists.
Plugins preserve the boundary you choose when connecting a source. If you link one project, repository, folder, property, or workspace, the agent works inside that scope. Adding another source is an explicit step rather than an accidental consequence of broad credentials.
This makes it practical to use several agents with different jobs. A product agent can work from the roadmap and customer research while an engineering agent uses repositories and delivery data. Both may use the same provider, but they do not need the same view of it.
The connection also remains a live relationship rather than a one-time import. Dawn reads current information from the provider when a task runs. Removing or disabling access stops future use without leaving a separate copied index for the team to clean up.
Supported plugins can do more than answer a question on demand. Provider events can start a Dawn Workflow, letting the same agent and source permissions handle work as it happens.
A pull request opening can start a first-pass review. A work item changing can prompt an impact summary. A pipeline result can trigger an investigation or a release update. The workflow receives the event context, uses only the plugin capabilities it has been given, and leaves a run the team can inspect.
Event support varies by provider, and creating a connection does not automatically create a workflow. Teams choose which events matter, apply the available filters, and decide which agent should respond. That keeps event-driven work focused instead of turning every provider notification into another noisy automation.
Open Plugins in Dawn, choose a provider, and follow its setup flow. Link the smallest useful set of sources, keep the initial capabilities read-focused, and test the connection with a concrete request:
Find the open work for the next release and compare it with the latest product brief.Review the pull requests waiting for feedback and tell me which ones have failing checks.Once the agent consistently finds the right information, add the specific actions or workflow events the team wants to automate.
Plugins make connected work a first-class part of Dawn. Teams can bring their tools into the conversation, keep access bounded to the job, and move from one-off questions to repeatable workflows without giving up control over where agents can read or act.