Microsoft previews Deep Research in Azure AI Foundry

Source record: Deep Research entered limited public preview

On July 7, 2025, Microsoft announced Deep Research in Azure AI Foundry Agent Service. The announcement described an API and SDK offering of OpenAI's research capability, grounded with Bing Search and designed to produce source-backed output. Microsoft presented Deep Research as a composable tool that applications, workflows, or other agents could invoke, and described integration with Foundry connectors, Logic Apps, and Azure Functions.

Microsoft stated that Deep Research was available in limited public preview for Foundry Agent Service customers. The article described a multi-step flow that scoped the task, gathered web information through Bing Search, executed the research task, and returned a structured report with citations and clarifications. This is a July 2025 preview record. A team considering research automation still needs its own source policy, task boundary, review standard, and record of how a conclusion was used.

Research output needs an explicit decision context

A research report becomes more reliable when the request is specific about the decision it supports. Define the question, allowed sources, date range, jurisdiction or market where relevant, audience, desired evidence type, and unanswered questions that should remain visible. These inputs keep a broad web search from becoming a generic summary. They also give a reviewer a clear basis for judging whether the returned citations address the task that was actually assigned.

Citations provide traceability to sources, while source quality still depends on recency, authorship, primary evidence, and the relationship between a claim and the cited material. A system can preserve this context by returning a claim list, a citation for each claim, source dates, retrieval time, and explicit uncertainty labels. The result becomes a research artifact that can be inspected, revised, or declined before it informs a consequential business decision.

Hypothetical example: prepare a regulatory landscape brief

Consider a hypothetical product team preparing a briefing about a proposed regulation. The request names the jurisdiction, date cutoff, preferred primary sources, and the decisions the team expects to make. A research agent gathers public materials and returns a draft with section-level citations, publication dates, and a list of questions where the source record is incomplete. It has no access to the team's customer data, internal contracts, or publication channels.

A policy reviewer compares the draft against the named sources and decides whether the brief is sufficient for internal discussion. If a source has moved, is outside the allowed jurisdiction, or conflicts with another primary record, the report highlights the issue rather than smoothing it into a single conclusion. The hypothetical workflow converts research into a reviewable input for a human decision, with a preserved chain from question through evidence.

Architecture: separate research, synthesis, and action

Treat research collection, synthesis, and downstream action as different system stages. The research stage queries approved sources and captures provenance. The synthesis stage organizes claims, citations, and unresolved questions. The action stage receives a reviewed artifact and applies a separate policy for any change to a system of record. This separation lets teams improve research quality without accidentally granting the research tool authority over communication, purchasing, publishing, or operational changes.

Use structured task state across these stages: request identifier, source policy version, query log reference, result version, reviewer, and terminal status. A connector or workflow tool should receive only the fields it needs for its task. For example, a reporting workflow can receive an approved brief identifier and approved destination, rather than the broad web-search session. This approach limits data movement and makes each transition inspectable when a report requires correction.

Failure modes: source coverage and confident synthesis

Research automation can miss a primary record, over-weight a highly ranked secondary page, use an outdated source, or combine claims that apply to different dates and jurisdictions. A polished summary can make these gaps hard to notice. Design the output to show source dates, source type, direct support for material claims, and open questions. Require the system to preserve uncertainty when the evidence does not resolve it.

Test an ambiguous question, a query with conflicting sources, a source that becomes unavailable, an instruction embedded in a retrieved page, and a task that requests a conclusion beyond the evidence. Review whether citations point to the claim they support and whether the agent distinguishes research from recommendation. These tests are useful even when the research system produces correct summaries on common cases, because they expose the boundaries that matter when a report informs a high-stakes choice.

Evaluation checklist: assess evidence quality and workflow fit

Create a benchmark of research tasks with independently reviewed source sets and known uncertainty. Score factual support, citation accuracy, coverage of required questions, handling of stale or conflicting information, and the usefulness of the unresolved-questions list. Measure the time required for a reviewer to verify the report, not just the time required to generate it. A fast report that is expensive to check may be a poor operational trade.

For a limited rollout, select one recurring research task, define its source policy, and keep publication and external communication outside the automated path. Record model and tool configuration, input policy, retrieval date, review outcomes, and corrections. Re-run the benchmark when sources, tools, prompts, or workflow routing changes. This establishes whether the system improves a specific research process while keeping the decision owner and evidence trail clear.

Related capabilities

• SI infrastructure development