Dawn now supports provider-hosted web search for workspaces that allow it, and ships a new /web-research command for the kind of question that has to start on the public web rather than inside a connected source. Owners and managers turn web search on from workspace settings; once it is on and the selected model supports it, the agent can pull in current public information when a question genuinely needs it, and /web-research appears in the slash command list.
The shape of the change matters as much as the capability. Web search is workspace-scoped, model-aware, and explicit. Workspaces that want their agents to stay strictly inside approved company context can leave it off. Workspaces that want Dawn to reach for current public information when a question depends on it can turn it on, and trust that it only happens when the model can actually do the work.
Why Web Access Is a Workspace Decision
Dawn is strongest when it works from the workspace. The agent can already lean on tickets, pull requests, design files, connected sources, memory pages, and the running thread to ground its answer. That covers a large share of real work. It does not cover every useful answer.
Some questions are public and current by nature. A platform team comparing how two cloud providers describe a new capability, a frontend lead checking the current guidance for a framework feature, a support engineer collecting up-to-date references before writing a memory page — that work used to sit outside the agent. Someone searched the web manually, copied links into chat, and asked Dawn to make sense of them. That worked, but it pushed the most fragile part of the task — picking the right sources — onto the human.
Letting the agent do the search itself fixes that, but it also shifts where the trust boundary sits. A workspace agent that can browse the web is doing something different from a workspace agent that cannot. Some teams want that capability; others, by policy or preference, do not. Tying web search to the workspace, and putting the toggle in the hands of owners and managers, makes the choice concrete instead of implicit. There is one place in workspace settings to look at, one switch to flip, and an honest agent surface either way: when web search is off, web-search commands are hidden and agent runs are configured without the capability.
Model Support Is Part of the Surface
The second decision worth being explicit about is that Dawn only exposes hosted web search when the selected model supports it. Several frontier models offer hosted web search as a first-party capability; others do not. Some custom models a team registers in Dawn may, others may not.
Dawn treats that as part of the agent surface, not a hidden footnote. Each model in the catalog declares whether it supports hosted web search, and Dawn only offers web-aware behaviour — including the /web-research command — when the active model actually has it. If a workspace owner has enabled web search but the agent is configured against a model that cannot perform it, the command does not appear and runs do not pretend the capability is there. That keeps the user experience honest. The presence of /web-research in the slash command list is a real signal that the workspace allows it and the model can run it.
This also means a team can opt into web search globally and still control where it shows up by choosing models per agent. An agent pinned to a model without hosted web search will simply behave the way Dawn always has. An agent on a web-capable model will pick up the new behaviour. There is no separate toggle to keep in sync per agent.
/web-research Makes the Source Explicit
/web-research is the new command. It is for tasks that start on the public web — a question whose useful answer depends on current information that is not already in your workspace.
The shape of a good /web-research brief is the shape of a good research request to a colleague: a specific question, a clear lens, and a useful output in mind. The thinner the brief, the thinner the result.
/web-research compare current guidance for React Server Components and summarise what our frontend team should know/web-research find recent Azure App Service outbound request timeout guidance and turn it into a memory page draft/web-research research OAuth device login UX patterns for CLI tools and call out the ones that work without a browser fallbackThe command tells Dawn that the source of truth is the public web for this turn. The agent searches, evaluates the useful sources, and produces the kind of focused result the brief asks for: a summary, a recommendation, a comparison, a memory page draft. That intent makes the result more useful than a general “search and tell me what you find” prompt, because the agent knows what to discard and what to weigh.
It also makes /web-research the wrong tool for a chunk of everyday work. If the answer is already in a connected source, the normal agent flow or a focused command like /explore, /ticket-plan, or /pr-review will be sharper. If the question is about private company policy, internal code, or a customer-specific issue, public search adds noise rather than clarity. /web-research earns its keep when the public web is genuinely the place the answer lives.
Where Workspace Context Still Pulls Its Weight
Web search does not replace connected sources. It composes with them.
A plain search engine gives you a page of links and leaves the synthesis to the reader. The thing that makes Dawn’s web research useful is that it happens inside the workspace context the agent already has. The team’s stack, the team’s existing memory pages, the connected repos, the running thread — all of that stays available while the agent reads what it found on the web. A research result for “current guidance on background job retries” reads differently when the agent already knows you run on .NET 9 with PostgreSQL than it does when it has nothing to anchor against.
The same composition is what makes the next step practical. A team can ask Dawn to research a topic on the public web, synthesise the relevant points against the workspace, and turn the result into a memory page draft. That is the workflow /web-research is shaped for: a one-off public-web research run becomes durable workspace knowledge if it deserves to. The agent can use it later through the same memory the rest of the workspace already trusts. If the research does not deserve to stick, you read the answer and move on without leaving anything behind.
Writing a Brief That Actually Earns the Search
The honest limitation of web search is that it amplifies the question. A vague request — “research React” — sends the agent at a topic the size of an ocean. A specific request — “research current React guidance around server components for teams using Vite and client-heavy dashboards, and call out the practical migration friction” — gives the agent a target it can hit.
Two things tend to make briefs better in practice. The first is naming the lens: who is this for, what stack are they on, what decision are they making. The second is naming the output: a summary, a recommendation, a comparison table, a memory page draft, a paragraph for a release note. Most of the difference between a useful research result and a generic one is in those two pieces, not in how clever the underlying search is.
/web-research does not change what good research briefs look like. It just makes the public-web ones a first-class shape inside Dawn instead of a workaround.
How It Sits Alongside the Rest of Dawn
Web research is most useful in combination with the workflows Dawn already has for longer-running work. A /web-research run that synthesises several sources is a natural fit for background tasks — start the research, keep working in the thread, and apply the result when it is ready. A research output worth keeping pairs with memory pages so the team does not have to redo the same homework next quarter. A research result that points at follow-up engineering work flows into /ticket-plan or /explore without losing context, because the same thread carries both.
The point is not that /web-research does everything. It does one thing — start from the public web — and lets the rest of Dawn handle what happens after.
Getting Started
Workspace owners and managers can open workspace settings and check whether Web Search is enabled. If it is on and the agent is configured against a web-capable model, /web-research appears in the slash command list for everyone in the workspace.
A useful first run is one that has a clear question and a concrete output in mind. Pick a topic the team keeps re-researching, ask /web-research to produce the kind of result that would have saved someone an afternoon, and then decide whether the answer should stay in the conversation, become a memory page, or feed into a follow-up task. That is the loop the feature is designed for.
Web research is now part of Dawn for the workspaces that want it, on the models that can run it, and only when a user asks. Public sources stay public, the workspace stays in control, and the agent gets a clean way to start from the web when the web is where the answer lives.