Healthcare and Life Sciences Blog articles

Agents: Snack Pack

samhitaraman — Fri, 06 Mar 2026 01:07:32 GMT

It’s not just you.

Agents are everywhere, and everyone else seems to know exactly what they are.

If you’ve been nodding along while secretly thinking “I should probably look this up"... you've found the right place!

This Agents Snack Pack contains easy‑to‑digest content designed to help you understand agents, one piece at a time. Content is arranged from left to right in order of increasing complexity. If you're starting out, begin with Column 1 (Access) and progress as you build confidence!

#1. Discover

#2. Use

#3. Build

Drill in the fundamentals:

What are Microsoft 365 Copilot agents and how to use them | Microsoft

Ask big questions, let Researcher do the investigation.

Researcher: A reasoning agent in Microsoft 365 Copilot

Create your first agent:

Microsoft 365 Copilot Chat - Agent builder demo

Explore the Agent Store:

Agent Store in Microsoft 365 Copilot

When spreadsheets get messy, call in Analyst.

Analyst: A reasoning agent in Microsoft 365 Copilot - YouTube

*Create an Epic Tip Sheet Agent: https://youtu.be/ilL5j5qBdpE

*Agent requires premium Copilot license

Practical use cases:

Sales: Microsoft 365 Copilot Chat - Sales agent demo

Customer Service: Microsoft 365 Copilot Chat - Customer service agent demo

Demo: Leveraging Analyst to break down hospital occupancy data

https://youtu.be/0OG6yTpZoMU

*Build your first autonomous agent:

How to create an autonomous agent with Copilot Studio

*Agent requires premium Copilot license

Hungry for more? Join our live, instructor-led AgentRx sessions to get hands on guidance with Microsoft experts.

Bringing Organizational Knowledge into the Clinical Workflow

BertHoorne — Thu, 05 Mar 2026 17:40:47 GMT

This blog is co-authored by Hadas Bitran, Partner GM, Health AI, Microsoft Health & Life Sciences

Every day, clinicians spend valuable time looking for information that lives in different places. An email thread from a specialist colleague. A Microsoft Teams discussion about a complex case. Updated organizational processes buried in SharePoint or OneDrive. This information provides context that could be critical to their workflows or help inform their decisions. But that context is not part of their clinical workflow.

The result? Clinicians are forced to break their clinical workflow, searching manually across organizational resources, and mentally combining scattered data points, all while a patient is waiting. This isn't a knowledge problem. It's a retrieval problem. And it's costing time, focus, cognitive burden and clinical confidence every single day.

That's exactly the gap we're closing by bringing clinical intelligence and your organization's knowledge into one seamless, workflow-native experience.

Clinical workflow, now with your organizational context

Within Dragon Copilot, clinicians will be able to securely surface relevant information across Microsoft 365, without leaving the clinical workflow:

Email: retrieve relevant information that was exchanged with patients, colleagues or from specialist correspondence, referral communications, or care coordination threads.

find me the email from Dr. Ting that mentioned the latest research about this mutation.
In this example, the chat functionality in Dragon Copilot uses the patient and encounter context to resolve the referenced mutation, then leverages Microsoft 365 Copilot behind the scenes to locate the email from Dr. Ting that mentions it.
Microsoft Teams: surface information from Microsoft Teams chats that the clinician had with colleagues, discussions or group chat conversations.

The patient is traveling to Florida. Identify dialysis centers near the patient’s destination based on information shared by Dr. Salomon in Microsoft Teams and provide practical travel guidelines I can share with the patient.
In this example, Dragon Copilot uses trusted sources for travel guidelines and Microsoft 365 Copilot to retrieve relevant Microsoft Teams messages from Dr. Salomon, identifying nearby dialysis centers in Florida.
SharePoint and OneDrive: access organizational knowledge on demand: HR policies, facility procedures, compliance guidelines, shift schedules, and more

Who is on call for nephrology tonight and who is covering tomorrow morning?

In this example, Dragon Copilot leverages Microsoft 365 Copilot behind the scenes to locate the most up‑to‑date Excel file with upcoming shift and coverage information from the hospital’s SharePoint, and surfaces the answer directly in the conversation, without disrupting the clinician’s workflow.

With Microsoft 365 Copilot, work context is available directly inside Dragon Copilot, clinicians can choose if, and when to access their work information. Within Dragon Copilot, they can ask questions in natural language and receive the most relevant information, grounded in patient context, from trusted clinical sources and their Microsoft 365 data. One conversational flow. Full clinical and work context. No tab switching, no manual searching, no lost focus.

Trusted by design, built for healthcare

Security and privacy are built in from the ground up. Information is always accessed on behalf of the individual user, fully respecting existing Microsoft 365 identity and access management, compliance, and privacy controls, meaning clinicians see only what they're authorized to see, and that Dragon Copilot will only use their work context if the clinician consented to it. This also means no new security risks to manage, and no changes to how your organization governs access to information.

For healthcare organizations where data sensitivity, regulatory compliance, and patient privacy are non-negotiable, this better-together experience is designed to meet that bar from day one.

Join the Private Preview

If you're a Dragon Copilot customer, and your organization is using Microsoft 365 Copilot, we invite you to be among the first to experience this new capability. Register now for early access to the private preview and play a role in shaping the future of clinical workflow intelligence.

Register for private preview

Dragon Copilot centralizes trusted medical content and relevant contextual information in-workflow

hadasb — Fri, 06 Mar 2026 15:00:20 GMT

This blog is co-authored by Bert Hoorne, Principal Program Manager & Ksenya Kveler, Principle Medical Science Manager

Dragon Copilot delivers medical intelligence from trusted sources directly within clinical workflows for healthcare organizations in one solution.

We are pleased to announce that we are expanding those knowledge sources with additional best‑in‑class content providers and enabling broader access to your organization’s internal sources with Microsoft 365 Copilot integration.

Access information from new credible medical content providers

Dragon Copilot users will gain access to an additional robust collection of

trusted clinical content from leading evidence-based resources. We are partnering with renowned publishers to bring you the best, most trusted content, safely and securely, within clinician’s workflows while helping to reduce the use of unauthorized AI tools and applications, commonly referred to, as “shadow AI.”

Access content from Wolters Kluwer UpToDate

We’ve partnered with Wolters Kluwer UpToDate to bring trusted, evidence-based clinical guidance directly into Dragon Copilot. Customers with an active Wolters Kluwer UpToDate license will be able to access UpToDate content in Dragon Copilot, within the context of their clinical workflows.

This integration allows clinicians to ask both general questions and patient specific questions and receive answers grounded in UpToDate evidence, with clear references to supporting sources. Over time, it will also introduce contextual links to UpToDate concepts layered on top of Dragon Copilot–generated notes, further enhancing clinical insight at the point of care.

“Clinicians need reliable guidance that supports fast, confident decision-making without disrupting care delivery. We are excited to partner with Microsoft to bring UpToDate’s gold standard evidence and expertise-based clinical insights to Dragon Copilot, helping clinicians quickly access, actionable answers that reduce cognitive burden and support better patient care.”

Yaw Fellin, Senior Vice President and General Manager, UpToDate Clinical Decision Support and Provider Solutions
Wolters Kluwer Health

Here’s an example of UpToDate content embedded in the Dragon Copilot workflow:

Wolters Kluwer UpToDate powering Dragon Copilot Chat answers

Obtain trusted clinical evidence with Elsevier ClinicalKey AI

Elsevier’s ClinicalKey AI will be available in Dragon Copilot. This integration enables customers with an active Elsevier ClinicalKey AI license to surface trusted medical literature and clinical evidence directly within clinicians’ workflows.

“Clinicians are navigating a complex and rapidly changing healthcare landscape and need solutions they can trust. The ClinicalKey AI extension for Dragon Copilot transforms how clinicians interact with trusted medical literature and clinical answers. The conversational interface makes evidence discovery faster and more intuitive.”

Jukka Valimaki, SVP Clinical Solutions
Elsevier

Here’s an example of ClinicalKey AI content embedded in the Dragon Copilot workflow:

Support clinical decisions with EBMcalc

With the integration of EBMcalc medical calculators, Dragon Copilot enables clinicians to use evidence-based calculators directly within their workflows—applied in context to the patient they’re caring for.

“Clinicians need trusted, evidence-based insights exactly at the point of care. By integrating EBMcalc’s rigorously curated clinical calculators and references into Dragon Copilot, we’re helping make high quality medical evidence more accessible, more actionable, and easier to use within everyday clinical workflows”.

Louis Leff, MD, MACP, Founder and CEO
EBMcalc

Access independent evidence in Dragon Copilot with Wiley and Cochrane

Wiley and Microsoft are partnering to bring scientific literature and clinical evidence directly into the healthcare workflow, starting with the Cochrane Library. Through this integration, customers with an active Cochrane Library AI license will be able to access Cochrane’s high-quality, independent evidence, systematic reviews, and clinical answers, to inform more reliable and efficient decision-making. This includes the Cochrane Database of Systematic Reviews (CDSR), the home of gold-standard evidence syntheses, widely used to inform clinical guidelines worldwide.

"Working with Microsoft to bring the Cochrane Library into Dragon Copilot reflects a shared commitment to meeting researchers and clinicians where they are. Healthcare Institutions can now access independent, peer-reviewed evidence— right within their clinical workflow”

Josh Jarrett, SVP & GM of AI Growth
Wiley

Access work context with Microsoft 365 Copilot in Dragon Copilot

With the Microsoft 365 Copilot integration, Dragon Copilot enables clinicians to seamlessly access information from their emails, chats, OneDrive and SharePoint, within the flow of their clinical work. Clinicians can combine this information with additional questions and actions, all governed by existing organizational and user access controls. Use of this data within Dragon Copilot workflow remains fully at the user’s discretion.

Here’s an example of content from an email surfaced by Microsoft 365 Copilot accessible through the Dragon Copilot workflow:

Microsoft 365 organizational context in Dragon Copilot

Read more for a deeper dive on how Dragon Copilot enables work context access with Microsoft 365 Copilot integration.

Safe web search

Dragon Copilot safe web search delivers trusted, evidence linked answers when curated sources are unavailable—ensuring clinicians continue to receive timely support without disrupting their workflow.

The goal of safe web search is to prevent broken workflows and eliminate unsafe external browsing. Clinicians remain within their clinical context, focused on the patient—without tab hopping or the risk of landing on unreliable or unverified websites.

Safe web search eliminates “no response” dead ends by maintaining a seamless conversational experience in Dragon Copilot and reducing unanswered prompts.

This capability is enabled by using verified, secure, and responsible mechanisms designed for safe clinical experiences. It enforces multilayer protection through evidence validation, provenance linked responses, content filtering, and regulated search with built in safeguards.

Here’s an example of content from a safe web search in the Dragon Copilot workflow:

Conclusion

These advancements represent an important step forward in how Dragon Copilot delivers trusted medical intelligence - bringing together best‑in‑class clinical evidence, organizational knowledge, and safe web access in one governed, in‑workflow experience. We will continue to expand our partner ecosystem, deepen integrations with leading evidence providers, and evolve Dragon Copilot conversational extensibility to meet clinicians where they work.

Why nursing needs a different kind of AI—and how Dragon Copilot delivers

Allison_Novick — Thu, 05 Mar 2026 14:30:00 GMT

The Dragon Copilot experience for nurses was made generally available (GA) in December 2025 with a clear mission: help nursing staff focus on care, not the computer.

From the start, the goal was to create a comprehensive AI clinical assistant—one that works alongside nurses throughout their shift, reduces cognitive load, captures the full scope of care delivered, and translates real clinical work into automated next steps, including documentation—fundamentally transforming workflows to keep patient care at the center.

Microsoft has continued to execute on that vision. Recent enhancements include extended mobile access with Android support—enabling nurses to record care in Epic Rover on Android devices—as well as significant expansion in ambient documentation coverage. Together, these advances reflect a consistent approach: adoption follows when technology aligns with how nurses work.

Expansive nursing documentation coverage

Nursing work spans multiple flowsheet templates, assessments, state changes, and, at times, narrative notes. When solutions support only a subset of this work, nurses are left filling gaps after the fact—reintroducing cognitive load and eroding the value of this technology.

Microsoft has expanded Dragon Copilot’s ambient documentation capabilities by broadening the range of supported nursing value types—and by extending it to deliver complete coverage across all flowsheet templates in supported departments and settings. The result is comprehensive documentation generated from each recording including:

Lines, Drains, Airways, and Wounds (LDAs) documentation, including assessments, additions, and removals
Nurse notes, automatically generated from natural nurse-patient conversations and voice memos captured on the go
Full flowsheet template coverage—not just a subset—including admission and discharge flowsheets, blood administration, CIWA-Ar, and care plan-related flowsheets
Adaptations to each organizations charting philosophy, including macros support, chart-by-exception, pertinent positives, and more

This breadth matters because nursing work is rarely captured within only a narrow set of flowsheets—nor does it typically result in just narrative notes. Yet many solutions labeled “for nurses” prioritize what is easiest to automate, rather than what nurses need. The result can be a false sense of completeness, with nurses still managing gaps across their shift.

Why nursing ambient documentation is hard—and what makes Dragon Copilot unique

Achieving comprehensive, high‑quality nursing documentation has required specialized technology designed to address the structural, workflow, and feedback challenges unique to nursing—challenges that general narrative ambient models and physician‑oriented solutions are not built to solve:

Flowsheets are messy, complex, and frequently changing
Flowsheets are large, hospital-specific, internally ambiguous, and constantly evolving under governance. Complex logic—such as cascading rows, documentation‑by‑exception patterns, and duplicative or overlapping rows—makes it far from straightforward to accurately map a clinical observation to the correct field and value. Microsoft works directly with real hospital schemas, handling hierarchy, ambiguity, and multiple valid documentation destinations—without requiring flowsheet redesign or sacrificing quality.
Nurses don’t speak for documentation
Bedside language is optimized for care delivery, not chart completeness. Critical details are often implied or never spoken aloud. Microsoft’s technology translates natural nursing communication into accurate documentation without changing nurse behavior. Built on industry‑leading transcription accuracy and decades of speech recognition expertise, Dragon Copilot is informed by real‑world integration across diverse EHR environments, preserving accurate translation and clinical intent that directly impact downstream documentation accuracy.
Nursing audio is diverse
Recordings mix shorthand, dialogue, monologue, and unit-specific language. Dragon Copilot accounts for mixed speaking modes instead of flattening audio through a generic pipeline or requiring nurses to speak in constrained ways.
Feedback loops are noisy
Nurse corrections to AI output often reflect hindsight or personal preferences rather than model error. Microsoft’s approach analyzes correction patterns with clinical context, enabling calibration at the institution, department, and even individual user level.
Bedside workflows demand predictability
Baseline LLMs are not suited for real-world nursing accuracy, latency, and cost requirements — especially with tens-of-thousands of possible flowsheet values. Dragon Copilot is optimized for consistent performance across real nursing environments, exceeding the reliability and latency characteristics of baseline models.

Beyond specialized nursing architecture, Dragon Copilot enforces strict quality and safety gates for new documentation outputs—including oversight by Microsoft’s internal, nurse-led Clinical Integrity team, phased validation, and Responsible AI review—ensuring new documentation covered meets defined nursing standards before being introduced at scale.

Dragon Copilot represents a fundamental shift in how nursing work is supported by AI by meeting the full complexity of bedside care head-on. By delivering comprehensive ambient documentation across live inpatient care environments, Dragon Copilot helps ensure that the care nurses provide is accurately captured, trusted, and usable downstream. The result is an AI clinical assistant that keeps nurses focused on what matters most: their patients.

From dictation to intelligence at the cursor with Dragon Copilot Desktop

James_Jeffries — Thu, 05 Mar 2026 17:49:06 GMT

This blog is co-authored by Dr. David Ting, Chief Clinical Product Lead, and Sarah Grey, Senior Product Manager.

Today’s patient encounters are packed with friction that breaks clinicians’ flow, clouds clinical thinking, and drains the joy from practice. Instead of focusing on patients, listening, assessing, and collaborating on care, clinicians spend visits staring at a screen, wrestling with bloated EHRs, and acting as data entry clerks. They type into endless fields, check boxes, click buttons, and memorize arcane text shortcuts and key sequences designed to satisfy computer hard-stops, regulatory tests, and payer demands, not to deliver compassionate, high-quality care.

And it doesn’t stop with the EHR. Clinicians bounce between imaging systems, referral portals, messaging apps, mobile devices, specialty tools, and the nonstop demands of email, policies, training, credentialing, and CME. Managing care across dozens of disconnected systems every day makes one thing clear: clinicians and healthcare organizations are desperate for relief.

Can artificial intelligence help? Of course it can. But hope in AI is too often disappointed by the reality of AI solutions that are poorly integrated with each other and with clinicians’ holistic workflow. AI risks being trapped in a single application like the EHR, leading to disjointed and suboptimal experiences.

But if AI lives in a separate window from where clinicians actually work, it risks adding another source of friction, forcing context switching and manual copying and pasting across the EHR and other systems.

What clinicians need is a way to access a seamless clinical intelligence everywhere they work. This is precisely what Dragon Copilot brings to the beleaguered physician, nurse, and advanced practice provider.

Extending the power of AI to remove friction

The reality for most clinicians is that their patients’ information and care coordination is managed in an EHR and via complementary apps living on the Windows desktop. If an AI clinical assistant is to be helpful, it must be available anywhere the clinician is working, regardless of which of the many desktop applications happen to be in focus. As the clinician moves from the EHR to a PAX viewer, web browser, email client, or Teams meeting, the AI should be able to understand the underlying context and offer ways to streamline the clinician’s flow.

Dragon Copilot’s AI changes the dynamic. When editing text anywhere – in the EHR, in Outlook, Word, a web browser app, or within Dragon Copilot’s own editor – a clinician simply selects desired text, speaks or types a natural language instruction (e.g., “Expand this paragraph to reflect more of the patient’s description of the car accident”), and receives an inline rewrite or insertion directly in the target application.

A clinician searching for information can simply place their cursor over the text, and Dragon Copilot understands the context, allowing the clinician to make multi-part requests: “Given this diagnosis, what is the recommended treatment, and are any of those covered by the patient’s insurance plan?” Dragon Copilot gathers context, searches through approved, trusted knowledge sources, and provides the answer within the Dragon Copilot workflow.

Here’s another example: while reviewing an online guideline or internal protocol in the organization’s SharePoint, a clinician can select a passage and ask, “Give me the three key takeaways from this reading and summarize them in patient-friendly language to include in the after-visit summary.” The clinician receives the in-context summary directly in workflow.

Dragon Copilot overcomes EHR-constrained AI and disconnected tools by unifying and delivering intelligence in one centralized workspace.

Dragon Copilot is the AI clinical assistant connecting fragmented systems

Care doesn’t happen in a single app. Even though the EHR is the system of record, clinicians still do significant work outside of it. Yet EHR-based AI cannot reach outside the EHR itself. And most third-party tools don’t (and won’t) ship deep AI integrations quickly.

The result is a frustrating array of AI-powered experiences that can only perform a part of the required task – such as an EHR ordering agent that cannot read the hospital formulary in SharePoint, or a third-party coding

solution that cannot automatically map the provider’s visit diagnoses. That leaves the clinician in an unhappy position of needing to be data courier, manually copying information from one application to the other, rather than spending time taking care of the patient.

Dragon Copilot acts as the connective tissue across that fragmentation. By working with standard text controls, it can bring a consistent interaction model, including dictation, commands, and cursor-native AI, across the clinical workflow.

Shifting from speech dictation to natural language editing

Over 650,000 providers worldwide have benefited from computerized speech-to-text dictation using Dragon Medical One. Traditional speech-to-text systems, like Dragon Medical One convert spoken audio into text word for word, like a courtroom transcript. But Dragon Copilot provides a new way to turn language into clinical content, in addition to capturing patient encounters ambiently.

With Dragon Copilot, clinicians can just say what they want by speaking naturally. They can instruct Dragon Copilot to perform targeted edits (“Summarize the HPI in two sentences”) and issue high-leverage whole-document edits that used to be tedious. Clinicians can even talk naturally to create documentation from scratch in new ways:

“Using only the details already documented, draft an HPI and list a few clarifying questions to ask.”

“Update the patient’s pronouns throughout the note (don’t change clinical facts).”

“Rewrite the entire note in a more concise style, preserving meaning and keeping all facts the same.”

“Write the A&P using my standard knee template with a conservative treatment plan.”

These are new use cases where a short instruction can yield large, efficient edits. And for Dragon Medical One users who have benefitted from Dragon Medical One voice macros (called Step-By-Step commands) and custom vocabularies, these are all transferrable to Dragon Copilot.

The cursor becomes a reusable (and extensible) primitive

The cursor provides a dependable, ubiquitous interface for AI. While EHRs and complementary clinical and non-clinical applications may present vastly different UIs, they generally rely on the underlying operating system to provide the same cursor. Hence, users have come to expect a common behavior and access to a core set of functions associated with the cursor, regardless of the underlying application. Thus, the cursor defines scope (selected text vs. current field), intent (summarize, rewrite, extract), and placement (results appear where the clinician expects them).

In-workflow, cursor-anchored AI like Dragon Copilot’s turn that repeatable pattern into a platform primitive—a foundational, reusable building block that developers can rely on to deliver consistent experiences across applications. For Microsoft developers as well as third-party extension partners, this platform primitive provides experience extensibility: app teams and agent developers will be able to deliver new skills at the cursor through Dragon Copilot. Rapid expansion of Dragon Copilot capabilities becomes possible, because internal and partner developers can focus on the capabilities themselves instead of reinventing the UI. And end-users benefit from a coherent, always-discoverable, always-available experience.

Cursor-anchored AI can be safer and more trustworthy, especially with integrations

Healthcare demands trust. Cursor-anchored AI keeps actions tied to what the clinician can see and edit, and it makes output reviewable, editable, and reversible.

That doesn’t mean ignoring backend-integrated context. The goal is to combine the value of integrations with an interaction model that keeps scope clear: what the AI acted on, what it used, and what it produced, so clinicians stay in control.

Conclusion: Dragon Copilot on the desktop unifies fragmented systems and delivers a seamless cross-application intelligence in one solution

Dragon Copilot represents the next and necessary step in the evolution of healthcare AI. With today’s status quo, clinical use of generative AI is largely restricted to algorithmic clinical decision support or ambient documentation creation. Clinicians are still faced with disparate AI systems that are either tightly bound to EHRs but limited in scope beyond the EHR, or poorly integrated with the EHR, such that the AI systems lack sufficient visibility into patient context or require manual data extract, transform and load. In either case, clinicians are stuck with the role of being human data couriers; and that is still a far cry from the patient-clinician relationship they went to medical school or nursing school to practice.

With Dragon Copilot, AI isn’t “somewhere else.” It is intelligence embedded in the act of information gathering, analyzing, synthesizing, writing, revising, deciding, and executing. It is AI assistance right where you work. It represents less context switching, better notes, and stronger knowledge work support.

Dragon Copilot brings AI into revenue cycle workflows

James_Jeffries — Thu, 05 Mar 2026 17:51:44 GMT

This blog is co-authored by Josh Waldo, Product Manager, Joeri Van der Vloet, Principal Research Manager, and Koen Mertens, Senior Research Manager.

Many health systems treat revenue cycle performance solely as a downstream problem. Clinicians complete documentation, teams send notes to coders, queries follow, and everyone works backward to recover what was missed. In some cases, recovery isn’t even possible in this model. With the rise and pervasiveness of AI, there is an opportunity to rethink the model by improving documentation quality and comprehensiveness at the point of care. In this new model, reimbursement accuracy can be captured before the opportunity has been lost.

In this blog post, we walk through three powerful approaches we use in Dragon Copilot to support revenue cycle management (RCM):

Embed revenue cycle intelligence directly into the clinical workflow, delivering built-in guidance as documentation is created—while the patient is still in the room—to ensure critical details are captured.
Deliver that intelligence directly into existing EHR workflows wherever possible.
Extend RCM capabilities through an open ecosystem, enabling specialized partners to bring their coding expertise directly into the same workflow.

Clinicians document using Dragon Copilot while revenue relevant insights surface in context before notes ever move downstream. The result is better reimbursement accuracy, fewer back and forth exchanges, and less rework for clinicians and revenue cycle teams.

The problem, the opportunity, and the shape of a workflow solution

Most revenue cycle friction traces back to incomplete or imprecise documentation. Missing specificity, unclear assessments, and undocumented work create queries, denials, delays, and rework. The opportunity is to move RCM support upstream to the point where documentation is being created, with help that is context aware, transparent, and clinician controlled.

Solutions must analyze the patient, context and resulting documentation as they are created and surface opportunities related to:

Diagnosis specificity and diagnostic comprehensiveness

HCC capture and recapture opportunities

Evaluation and management (E/M) level considerations

Completeness of documentation relative to established criteria, like MEAT (monitor, evaluate, assess, treat)

Prior authorization guidelines

Complete capture of CC’s/MCC’s and other inpatient guidance

The shape of the solution must also provide assistance that shows up inside the documentation flow. It should feel like a light touch and not a separate destination or a stream of alerts. The design goal is to minimize distraction, avoid overwhelming notifications, and make every suggestion easy to review with clear evidence. Further, the nudges need to be actionable. With the click of a button, a clinician should be able to accept/reject the insight and have the appropriate actions then ensue, such as updating documentation automatically.

Small improvements may look modest in a single note, but they compound across clinicians and visits when applied consistently. If we can help clinicians capture the full clinical picture once, downstream processes inherit better inputs without asking clinicians to do a second pass.

Recognizing the scope of RCM opportunities in both ambulatory and inpatient, we are taking a three-pronged approach to help healthcare organizations enable the broadest and deepest set of coding skills into their Dragon Copilot workflows.

Built-in suggestions

Dragon Copilot already provides built-in capabilities that support RCM by improving the note itself, and we are continuing to expand them. We start by capturing all the minute details of what happened during the encounter and helping clinicians turn that into clear and comprehensive documentation. The goal is accurate and complete capture of the work performed and the patient complexity.

Dragon Copilot also supports on-demand billing code support. For each documented diagnosis, we can suggest relevant ICD-10 code options with supporting evidence so clinicians can quickly validate what is being proposed. We can also generate a coding summary report for each note to support downstream review.

Next, Dragon Copilot includes built‑in, proactive diagnosis specificity suggestions designed to support clinicians in selecting the most accurate and specific diagnoses at the point of documentation. As clinical notes are created, Dragon Copilot analyzes the documented clinical context and identifies opportunities where a diagnosis may be underspecified or incomplete.

When applicable, Dragon Copilot surfaces suggestions to refine a diagnosis (for example, laterality, acuity, severity, underlying cause, or associated conditions). For risk‑adjusted conditions, it helps clinicians identify diagnoses that may impact Hierarchical Condition Categories (HCCs), while emphasizing the need for complete, clinically appropriate, and defensible documentation.

All suggestions are advisory and designed to fit naturally into the clinician’s workflow. Clinicians remain fully in control, able to review, accept, modify, or ignore suggestions based on their clinical judgment. It does not add diagnoses automatically and does not replace clinical decision‑making. Its goal is to reduce missed specificity, support accurate clinical representation of patient complexity, and help ensure documentation aligns with coding and compliance expectations.

At a user experience level, we want this to be simple and predictable as outlined in this workflow:

The clinician documents using Dragon Copilot’s suite of documentation tools.
Once the note is drafted, a set of relevant suggestions to refine a diagnosis is surfaced discreetly in workflow
Each opportunity includes the why, the evidence, and a suggested improvement.
The clinician can accept, ignore, or defer, and stays in control at every step.
The note is improved before it reaches coding, reducing the need for back-and-forth exchanges later.

Done well, this approach improves documentation quality without changing clinical practice. It reduces avoidable queries, supports more consistent coding outcomes, and helps revenue cycle teams spend less time on cleanup.

Looking ahead, these built-in proactive capabilities will be extended into additional high value areas such as E/M level considerations and completeness expectations such as MEAT (monitor, evaluate, assess, treat).

Integrated EHR context and workflow

Deep EHR connectivity is a force multiplier because it provides context and continuity. With the right backend integrations, Dragon Copilot can leverage chart data to understand the patient history, current problems, and the broader clinical picture that surrounds the encounter.

For example, this can include access to relevant prior notes, the problem list, medications, allergies, labs, imaging results, and structured diagnoses already documented in the chart.

This context helps us enrich the completeness and accuracy of notes before anything is presented to the clinician.

Connecting directly to EHR workflows also matters. When insights and supporting evidence can be presented in the same places clinicians already review the chart, reconcile problems, place orders, and finalize documentation, we reduce context switching and increase the likelihood that improvements happen at the right moment.

We are already building these powerful workflows with some of the most widely used EHRs in the world and are bringing the ability to get diagnosis specificity directly in workflow as one example.

This is also where we can align RCM support with clinical actions. Suggestions should appear when they are most useful, such as while the diagnoses are reviewed and the note finalized.

This strategy is also about trust and safety. Clinicians should be able to see where a suggestion comes from, what it is based on, and why it matters, without leaving their workflow.

Partner extensions

RCM is complex and it looks different across organizations, service lines, and care settings. No single approach fits every health system and covers all the targeted needs. An ecosystem approach allows specialized partners to bring their expertise into the same workflow. With an open ecosystem, any partner can integrate coding into workflow in a self-service and standardized fashion, opening coding at scale and giving health systems the widest range of options to choose from.

We see some of the most developed expertise and exciting innovations coming from our partners. Dragon Copilot now serves as a consistent channel into the workflow, so our partners can deliver value without having to reinvent access to encounter context, user experience patterns, and distribution inside the EHR.

Examples of what partner extensions can enable include:

Specialty specific documentation guidance that reflects local policy and payer mix.
HCC program support that includes organization specific rules for capture and recapture.
Prior authorization support that highlights requirements earlier, when care decisions are being made.
CC’s/MCC’s identification to accurately capture O/E ratios

The goal is to let health systems choose what to enable, where to enable it, and for whom, while keeping the clinician experience consistent and limiting disruption.

Patient-first is the best revenue cycle strategy

The most effective revenue cycle strategy starts with patients, not paperwork. Dragon Copilot augments clinician care, helps capture the full patient story, and supports accurate reimbursement as a byproduct of good clinical documentation.

When technology fades into the background and supports clinicians without interrupting care, everyone benefits: clinicians reclaim time, revenue cycle teams see fewer issues, and health systems are reimbursed accurately for the care they provide.

Can you use AI to implement an Enterprise Master Patient Index (EMPI)?

dondinulos — Thu, 05 Mar 2026 05:54:21 GMT

The Short Answer: Yes. And It's Better Than You Think.

If you've worked in healthcare IT for any length of time, you've dealt with this problem.

Patient A shows up at Hospital 1 as "Jonathan Smith, DOB 03/15/1985." Patient B shows up at Hospital 2 as "Jon Smith, DOB 03/15/1985." Patient C shows up at a clinic as "John Smythe, DOB 03/15/1985."

Same person? Probably. But how do you prove it at scale — across millions of records, dozens of source systems, and data quality that ranges from pristine to "someone fat-fingered a birth year"?

That's the problem an Enterprise Master Patient Index (EMPI) solves. And traditionally, it's been solved with expensive commercial products, rigid rule engines, and a lot of manual review.

We built one with AI. On Azure. With open-source tooling. And the results are genuinely impressive.

This post walks through how it works, what the architecture looks like, and why the combination of deterministic matching, probabilistic algorithms, and AI-enhanced scoring produces better results than any single approach alone.

1. Why EMPI Still Matters (More Than Ever)

Healthcare organizations don't have a "patient data problem." They have a patient identity problem.

Every EHR, lab system, pharmacy platform, and claims processor creates its own patient record. When those systems exchange data via FHIR, HL7, or flat files, there's no universal patient identifier in the U.S. — Congress has blocked funding for one since 1998.

The result:

Duplicate records inflate costs and fragment care history
Missed matches mean clinicians don't see a patient's full medical picture
False positives can merge two different patients into one record — a patient safety risk

Traditional EMPI solutions use deterministic matching (exact field comparisons) and sometimes probabilistic scoring (fuzzy string matching). They work. But they leave a significant gray zone of records that require human review — and that queue grows faster than teams can process it.

What if AI could shrink that gray zone?

2. The Architecture: Three Layers of Matching

Here's the core insight: no single matching technique is sufficient. Exact matches miss typos. Fuzzy matches produce false positives. AI alone hallucinates.

But layer them together with calibrated weights, and you get something remarkably accurate.

Let's break each layer down.

3. Layer 1: Deterministic Matching — The Foundation

Deterministic matching is the bedrock. If two records share an Enterprise ID, they're the same person. Full stop.

The system assigns trust levels to each identifier type:

Identifier	Weight	Why
Enterprise ID	1.0	Explicitly assigned by an authority
SSN	0.9	Highly reliable when present and accurate
MRN	0.8	System-dependent — only valid within the same healthcare system
Date of Birth	0.35	Common but not unique — 0.3% of the population shares any given birthday
Phone	0.3	Useful signal but changes frequently
Email	0.3	Same — supportive evidence, not proof

The key implementation detail here is MRN system validation. An MRN of "12345" at Hospital A is completely unrelated to MRN "12345" at Hospital B. The system checks the identifier's source system URI before considering it a match. Without this, you'd get a flood of false positives from coincidental MRN collisions.

If an Enterprise ID match is found, the system short-circuits — no need for probabilistic or AI scoring. It's a guaranteed match.

4. Layer 2: Probabilistic Matching — Where It Gets Interesting

This is where the system earns its keep. Probabilistic matching handles the messy reality of healthcare data: typos, nicknames, transposed digits, abbreviations, and inconsistent formatting.

Name Similarity

The system uses a multi-algorithm ensemble for name matching:

Jaro-Winkler (60% weight): Optimized for short strings like names. Gives extra credit when strings share a common prefix — so "Jonathan" vs "Jon" scores higher than you'd expect.
Soundex / Metaphone (phonetic boost): Catches "Smith" vs "Smythe," "Jon" vs "John," and other sound-alike variations that string distance alone would miss.
Levenshtein distance (typo detection): Handles single-character errors — "Johanson" vs "Johansn."

These scores are blended, and first name and last name are scored independently before combining. This prevents a matching last name from compensating for a wildly different first name.

Date of Birth — Smarter Than You'd Think

DOB matching goes beyond exact comparison. The system detects month/day transposition — one of the most common data entry errors in healthcare:

Scenario	Score
Exact match	1.0
Month and day swapped (e.g., 03/15 vs 15/03)	0.8
Off by 1 day	0.9
Off by 2–30 days	0.5–0.8 (scaled)
Different year	0.0

This alone catches a category of mismatches that pure deterministic systems miss entirely.

Address Similarity

Address matching uses a hybrid approach:

Jaro-Winkler on the normalized full address (70% weight)
Token-based Jaccard similarity (30% weight) to handle word reordering
Bonus scoring for matching postal codes, city, and state
Abbreviation expansion — "St" becomes "Street," "Ave" becomes "Avenue"

5. Layer 3: AI-Enhanced Matching — The Game Changer

This is where the architecture diverges from traditional EMPI solutions.

OpenAI Embeddings (Semantic Similarity)

The system generates a text embedding for each patient's complete demographic profile using OpenAI's text-embedding-3-small model. Then it computes cosine similarity between patient pairs.

Why does this work? Because embeddings capture semantic relationships that string-matching can't. "123 Main Street, Apt 4B, Springfield, IL" and "123 Main St #4B, Springfield, Illinois" are semantically identical even though they differ character-by-character.

The embedding score carries only 10% of the total weight — it's a signal, not a verdict. But in ambiguous cases, it's the signal that tips the scale.

GPT-5.2 LLM Analysis (Intelligent Reasoning)

For matches that land in the human review zone (0.65–0.85), the system optionally invokes GPT-5.2 to analyze the patient pair and provide structured reasoning:

{ "match_score": 0.92, "confidence": "high", "reasoning": "Multiple strong signals: identical last name, DOB matches exactly, same city. First name 'Jon' is a common nickname for 'Jonathan'.", "name_analysis": "First name variation is a known nickname pattern.", "potential_issues": [], "recommendation": "merge" }

The LLM doesn't just produce a number — it explains why it thinks two records match. This is enormously valuable for the human reviewers who make final decisions on ambiguous cases. Instead of staring at two records and guessing, they get AI-generated reasoning they can evaluate.

When LLM analysis is enabled, the final score blends traditional and LLM scores:

Final Score = (Traditional Score × 0.8) + (LLM Score × 0.2)

The LLM temperature is set to 0.1 for consistency — you want deterministic outputs from your matching engine, not creative ones.

6. The Graph Database: Modeling Patient Relationships

Records and scores are only half the story. The real power comes from how the system stores and traverses relationships.

We use Azure Cosmos DB with the Gremlin API — a graph database that models patients, identifiers, addresses, and clinical data as vertices connected by typed edges.

(:Patient)──[:HAS_IDENTIFIER]──▶(:Identifier) │ ├──[:HAS_ADDRESS]──▶(:Address) │ ├──[:HAS_CONTACT]──▶(:ContactPoint) │ ├──[:LINKED_TO]──▶(:EmpiRecord) ← Golden Record │ ├──[:POTENTIAL_MATCH {score, confidence}]──▶(:Patient) │ └──[:HAS_ENCOUNTER]──▶(:Encounter) └──[:HAS_OBSERVATION]──▶(:Observation)

Why a Graph?

Three reasons:

Candidate retrieval is a graph traversal problem. "Find all patients who share an identifier with Patient X" is a natural graph query — traverse from the patient to their identifiers, then back to other patients who share those same identifiers. In Gremlin, this is a few lines. In SQL, it's a multi-table join with performance that degrades as data grows.
Relationships are first-class citizens. A POTENTIAL_MATCH edge stores the match score, confidence level, and detailed breakdown directly on the relationship. You can query "show me all high-confidence matches" without any joins.
EMPI records are naturally hierarchical. A golden record (EmpiRecord) links to multiple source patients via LINKED_TO edges. When you merge two patients, you're adding an edge — not rewriting rows in a relational table.

Performance at Scale

Cosmos DB's partition strategy uses source_system as the partition key, providing logical isolation between healthcare systems. The system handles Azure's 429 rate-limiting with automatic retry and exponential backoff, and uses batch operations for bulk loads to avoid RU exhaustion.

7. FHIR-Native Data Ingestion

The system ingests HL7 FHIR R4 Bundles — the emerging interoperability standard for healthcare data exchange.

Each FHIR Bundle is a JSON file containing a complete patient record: demographics, encounters, observations, conditions, procedures, immunizations, medication requests, and diagnostic reports.

The FHIR loader:

Maps FHIR identifier systems to internal types (SSN, MRN, Enterprise ID)
Handles all three FHIR date formats (YYYY, YYYY-MM, YYYY-MM-DD)
Extracts clinical data for comprehensive patient profiles
Uses an iterator pattern for memory-efficient processing of thousands of patients
Tracks source system provenance for audit compliance

This means the service can ingest data directly from any FHIR-compliant EHR — Epic, Cerner, MEDITECH, or Synthea-generated test data — without custom integration work.

8. The Conversational Agent: Matching via Natural Language

Here's where it gets fun.

The system includes a conversational AI agent built on the Azure AI Foundry Agent Service. It's deployed as a GPT-5.2-powered agent with OpenAPI tools that call the matching service's REST API.

Instead of navigating a complex UI to find matches, a data steward can simply ask:

"Search patients named Aaron"

"Compare patient abc-123 with patient xyz-456"

"What matches are pending review?"

"Approve the match between patient A and patient B"

The agent is integrated directly into the Streamlit dashboard's Agent Chat tab, so users never leave their workflow. Under the hood, when the agent decides to call a tool (like "search patients"), Azure AI Foundry makes an HTTP request directly to the Container App API — no local function execution required.

Available Agent Tools

Tool	What It Does
searchPatients	Search patients by name, DOB, or identifier
getPatientDetails	Get detailed patient demographics and history
findPatientMatches	Find potential duplicates for a patient
compareTwoPatients	Side-by-side comparison with detailed scoring
getPendingReviews	List matches awaiting human decision
submitReviewDecision	Approve or reject a match
getServiceStatistics	MPI dashboard metrics

This same tool set is also exposed via a Model Context Protocol (MCP) server, making the matching engine accessible from AI-powered IDEs and coding assistants.

9. The Dashboard: Putting It All Together

The Patient Matching Service includes a full-featured Streamlit dashboard for operational management.

Page	What You See
Dashboard	Key metrics, score distribution charts, recent match activity
Match Results	Filterable list with score breakdowns — deterministic, probabilistic, AI, and LLM tabs
Patients	Browse and search all loaded patients with clinical data
Patient Graph	Interactive graph visualization of patient relationships using streamlit-agraph
Review Queue	Pending matches with approve/reject actions
Agent Chat	Conversational AI for natural language queries
Settings	Configure match weights, thresholds, and display preferences

The match detail view provides six tabs that walk reviewers through every scoring component: Summary, Deterministic, Probabilistic, AI/Embeddings, LLM Analysis, and Raw Data. Reviewers don't just see a number — they see exactly why the system scored a match the way it did.

10. Azure Architecture

The full solution runs on Azure:

Service	Role
Azure Cosmos DB (Gremlin + NoSQL)	Patient graph storage and match result persistence
Azure OpenAI (GPT-5.2 + text-embedding-3-small)	LLM analysis and semantic embeddings
Azure Container Apps	Hosts the FastAPI REST API
Azure AI Foundry Agent Service	Conversational agent with OpenAPI tools
Azure Log Analytics	Centralized logging and monitoring

The separation between Cosmos DB's Gremlin API (graph traversal) and NoSQL API (match result documents) is intentional. Graph queries excel at relationship traversal — "find all patients connected to this identifier." Document queries excel at filtering and aggregation — "show me all auto-merge matches from the last 24 hours."

11. What We Learned

AI doesn't replace deterministic matching. It augments it.

The three-layer approach works because each layer compensates for the others' weaknesses:

Deterministic handles the easy cases quickly and with certainty
Probabilistic catches the typos, nicknames, and formatting differences that exact matching misses
AI provides semantic understanding and human-readable reasoning for the ambiguous middle ground

The LLM is most valuable as a reviewer's assistant, not a decision-maker.

We deliberately keep the LLM weight at 20% of the final score. Its real value is the structured reasoning it produces — the "why" behind a match score. Human reviewers process cases faster when they have AI-generated analysis explaining the matching signals.

Graph databases are naturally suited for patient identity.

Patient matching is fundamentally a relationship problem. "Who shares identifiers with whom?" "Which patients are linked to this golden record?" "Show me the cluster of records that might all be the same person." These are graph traversal queries. Trying to model this in relational tables works, but you're fighting the data model instead of leveraging it.

FHIR interoperability reduces integration friction to near zero.

By accepting FHIR R4 Bundles as the input format, the service can ingest data from any modern EHR without custom connectors. This is a massive practical advantage — the hardest part of any EMPI project is usually getting the data in, not matching it.

12. Try It Yourself

The Patient Matching Service is built entirely on Azure services and open-source tooling https://github.com/dondinulos/patient-matching-service :

Python with FastAPI, Streamlit, and the Azure AI SDKs
Azure Cosmos DB (Gremlin API) for graph storage
Azure OpenAI for embeddings and LLM analysis
Azure AI Foundry for the conversational agent
Azure Container Apps for deployment
Synthea for FHIR test data generation

The matching algorithms (Jaro-Winkler, Soundex, Metaphone, Levenshtein) use pure Python implementations — no proprietary matching engines required.

Whether you're building a new EMPI from scratch or augmenting an existing one with AI capabilities, the three-layer approach gives you the best of all worlds: the certainty of deterministic matching, the flexibility of probabilistic scoring, and the intelligence of AI-enhanced analysis.

Final Thoughts

Can you use AI to implement an EMPI?

Yes. And the answer isn't "replace everything with an LLM." It's "use AI where it adds the most value — semantic understanding, natural language reasoning, and augmenting human reviewers — while keeping deterministic and probabilistic matching as the foundation."

The combination is more accurate than any single approach. The graph database makes relationships queryable. The conversational agent makes the system accessible. And the whole thing runs on Azure with FHIR-native data ingestion.

Patient matching isn't a solved problem. But with AI in the stack, it's a much more manageable one.

Tags: Healthcare, Azure, AI, EMPI, FHIR, Patient Matching, Azure Cosmos DB, Azure OpenAI, Graph Database, Interoperability

🚀 The Great Foundry Shift: Microsoft Foundry New vs Classic Explained

VinodSoni — Thu, 05 Mar 2026 00:16:49 GMT

Introduction

If you've been working in the Azure AI ecosystem, you've likely noticed a seismic shift happening at ai.azure.com. What was once Azure AI Studio, then became Azure AI Foundry, and has now been rebranded as Microsoft Foundry — but the rebrand is the least interesting part. The architecture, portal experience, agent capabilities, and developer workflows have been fundamentally redesigned.

Microsoft now ships two portal experiences side by side — Foundry (New) and Foundry (Classic) — accessible via a toggle in the portal banner. But this isn't just a UI facelift. Under the hood, the resource model, project hierarchy, agent framework, tool ecosystem, and governance surface have all changed in meaningful ways.

This article breaks down every major difference across every layer of the stack so you can make an informed decision about when to migrate, what you'll gain, and what still requires the Classic experience.

1. The Branding & Naming Evolution

Era	Name	Portal URL
Pre-2024	Azure AI Studio	ai.azure.com
Mid-2024 to Late 2025	Azure AI Foundry	ai.azure.com
2026 (Current)	Microsoft Foundry	ai.azure.com

💡 Key Point: "Azure AI Foundry" is now "Microsoft Foundry." Screenshots across Microsoft Learn documentation are still being updated. Both portals live at the same URL — a toggle in the top banner lets you switch between (New) and (Classic).

2. Portal Philosophy: When to Use Which

Portal	Best For
Foundry (Classic)	Working with multiple resource types: Azure OpenAI resources, Foundry resources, hub-based projects, and Foundry projects. Use this when you need features not yet available in the new experience (e.g., Prompt Flow, open-source model deployments on managed compute, Azure ML workloads).
Foundry (New)	A streamlined, agent-first experience for building, managing, and scaling multi-agent applications. Only Foundry projects are visible. Hub-based projects, Azure OpenAI standalone resources, and legacy project types are not shown.

The new portal is not a superset of the classic portal — it is a focused reimagining for the agentic AI era. If you need legacy ML capabilities, you still switch back to Classic.

3. Resource Architecture & Project Hierarchy

Foundry (Classic): The Hub-Based Model

Classic supports two project types:

Hub-Based Projects — Built on the Microsoft.MachineLearningServices resource provider. A "Hub" (Azure AI Hub) acts as the parent resource, and projects are children of that hub. Hubs required provisioning extra resources: Azure Storage, Azure Key Vault, and optionally Azure Container Registry as mandatory sibling resources.
Foundry Projects — A newer project type introduced under the Microsoft.CognitiveServices provider. These are child resources of a Foundry Resource (kind: AIServices).

Foundry (New): One Project Type to Rule Them All

The new portal only surfaces Foundry Projects. The resource hierarchy is simplified:

Foundry Resource (Microsoft.CognitiveServices/account, kind: AIServices)
└── Foundry Project (Microsoft.CognitiveServices/account/project)
└── Project Assets (agents, evaluations, files, indexes)

Aspect	Classic (Hub-Based)	New (Foundry Project)
Resource Provider	Microsoft.MachineLearningServices	Microsoft.CognitiveServices
Parent Resource	AI Hub	Foundry Resource (AIServices)
Required Sibling Resources	Storage Account, Key Vault (mandatory)	None required by default
Project Isolation	Via Hub RBAC	Native project-level RBAC
Agent Service GA	Preview only	General Availability
Foundry SDK & API	Limited	Full support
ML Training (AutoML, Pipelines)	Yes	No (use hub-based project)
Prompt Flow	Yes	No
Managed Compute (HuggingFace)	Yes	No

💡 Critical Takeaway: New generative AI and model-centric features are available only through the Foundry Resource and its Foundry projects. Hub-based projects will not receive new agent or model features.

4. Resource Provider Unification

One of the most impactful architectural changes is the consolidation under the Microsoft.CognitiveServices provider namespace:

Resource	Provider	Kind
Microsoft Foundry	Microsoft.CognitiveServices/account	AIServices
Foundry Project	Microsoft.CognitiveServices/account/project	AIServices
Azure Speech	Microsoft.CognitiveServices/account	Speech
Azure Language	Microsoft.CognitiveServices/account	Language
Azure Vision	Microsoft.CognitiveServices/account	Vision

This means:

Unified RBAC: The same Azure RBAC actions work across Foundry, Azure OpenAI, Speech, Vision, and Language.
Unified Azure Policy: Existing custom Azure Policies continue to apply if you're upgrading from Azure OpenAI to Foundry.
Unified Networking: Private Link, VNet configuration, and network isolation share the same management patterns.

In contrast, hub-based projects under Microsoft.MachineLearningServices had a completely separate RBAC model, networking stack, and policy surface.

5. Security & Governance: Separation of Concerns

Foundry (New) — Clear Control Plane vs. Data Plane Separation

Layer	Scope	Who	Examples
Control Plane	Foundry Resource (top-level)	IT Admins	Create deployments, configure networking, manage projects, set encryption
Data Plane	Foundry Project (child)	Developers	Build agents, run evaluations, upload files, test in playground

This means IT can set up governance once at the resource level, and developers can self-serve by creating projects as isolated workspaces without needing admin intervention.

Starter RBAC Assignments:

Azure AI User for each developer at the Foundry Resource scope
Azure AI User for each project managed identity at the Foundry Resource scope

Foundry (Classic) — Hub-Centric Governance

In Classic, hub-based projects relied on the Hub as the governance boundary. This worked but required IT to manage the Hub and its dependent resources (Storage, Key Vault). Foundry projects under Classic had the same new governance model as above, but the portal experience was merged with hub-based projects, adding confusion.

6. Agent Service: The Biggest Leap Forward

The Foundry Agent Service is arguably the reason Microsoft rebuilt the portal experience. Here's how agent capabilities differ:

Foundry (Classic) — Agent Service in Preview

Agents available in preview only within hub-based projects
Agents in GA within Foundry projects (accessed through Classic portal)
Single-agent interactions primarily
Limited tool selection
Basic observability
Required connection strings for SDK authentication

Foundry (New) — Agent Service, Fully Realized

a) Multi-Agent Orchestration & Workflows

Build advanced automation with the visual workflow builder using SDKs for C# and Python. Supports:

Sequential workflows — Agent A → Agent B → Agent C in defined order
Group Chat — Dynamic control passing between agents based on context
Human-in-the-loop — Approval steps, clarifying questions mid-workflow
Visual YAML editor — Edit workflows visually or in YAML; changes sync in real-time
Power Fx integration — Excel-like formulas for conditional logic, variable handling, data transformations
Versioning — Every save creates an immutable version with full history

b) Agent Types

Type	Kind	Description
Prompt Agent	prompt	LLM-backed agent defined declaratively with model config, instructions, tools, and prompts
Hosted Agent	hosted	Containerized agent running custom code, deployed and managed by Foundry
Workflow	YAML-based	Orchestrates multiple agents together using agentic patterns

c) Memory (Preview — New Only)

Long-term agent memory is a brand-new capability:

User Profile Memory: Stores preferences, dietary restrictions, language preferences — persists across sessions
Chat Summary Memory: Distilled summaries of conversation topics for cross-session continuity
Three Phases: Extraction → Consolidation → Retrieval
Memory search tool or low-level Memory Store APIs
Supports up to 10,000 memories per scope, 100 scopes per store

d) Foundry IQ — Knowledge Integration (Preview — New Only)

A managed, multi-source knowledge base for enterprise content:

Connects to Azure Blob Storage, SharePoint, OneLake, and public web
Automated document chunking, vector embedding generation, metadata extraction
Agentic retrieval engine: Decomposes complex questions into subqueries, executes in parallel, semantically reranks, returns unified responses with citations
Permission-aware: Synchronizes ACLs, honors Microsoft Purview sensitivity labels, enforces permissions at query time
One knowledge base can serve multiple agents

e) Expanded Tool Catalog (Preview — New Only)

The new portal introduces a Foundry Tool Catalog with 1,400+ tools:

Tool Category	Examples
Built-in	Azure AI Search, Code Interpreter, File Search, Grounding with Bing, Image Generation, Computer Use, SharePoint, Microsoft Fabric, Browser Automation, Web Search
MCP Servers (Remote)	Publisher-hosted servers using Model Context Protocol
MCP Servers (Local)	Self-hosted MCP servers connected to Foundry
Custom	OpenAPI 3.0 specs, Agent-to-Agent (A2A) endpoints, custom MCP endpoints
Private Catalog	Organization-scoped tools visible only to your team

Classic had a much smaller tool surface: primarily Azure AI Search, File Search, Code Interpreter, and custom functions.

f) Integration & Publishing Capabilities

The new portal supports:

Publish agents to Microsoft 365, Teams, and BizChat
Containerized deployments for portability
Open protocol support: MCP and A2A with full authentication
AI Gateway integration (Azure API Management)
Azure Policy integration for agent governance

7. Model Deployment: What Changed?

The model deployment story is shared across both portals but the new portal streamlines the experience significantly.

Deployment Types (Available in Both)

Deployment Type	SKU	Data Processing	Billing
Global Standard	GlobalStandard	Any Azure region	Pay-per-token
Global Provisioned	GlobalProvisionedManaged	Any Azure region	Reserved PTU
Global Batch	GlobalBatch	Any Azure region	50% discount, 24-hr target
Data Zone Standard	DataZoneStandard	Within data zone (EU/US)	Pay-per-token
Data Zone Provisioned	DataZoneProvisionedManaged	Within data zone	Reserved PTU
Data Zone Batch	DataZoneBatch	Within data zone	50% discount
Standard (Regional)	Standard	Single region	Pay-per-token
Regional Provisioned	ProvisionedManaged	Single region	Reserved PTU
Developer	DeveloperTier	Any Azure region	Fine-tuned eval only, no SLA

Key Differences by Portal

Capability	Classic	New
Models sold directly by Azure (Azure OpenAI, DeepSeek, xAI)	Via connections in hub-based; native in Foundry projects	Native
Partner/Community Models (via Marketplace)	Via connections in hub-based; native in Foundry projects	Native
Models on Managed Compute (HuggingFace etc.)	Hub-based projects only	Not supported
Serverless API Endpoints	Hub-based projects	Standard deployment only
Model Catalog Browsing	Available without sign-in	Requires project context

8. Observability & Monitoring

Capability	Classic	New
Azure Monitor metrics	Scoped to resource level	Scoped to resource + project level
Application Insights integration	Manual setup	Built-in for Agent Service
Conversation-level tracing	SDK-based (manual)	Real-time in portal with built-in metrics
Evaluation workflows	Available (preview)	Available with continuous evaluation via Python SDK
Agent monitoring dashboard	Not available	Built-in "Operate" section
Model tracking	Basic	Enhanced with centralized AI asset management

The new portal introduces a dedicated "Operate" section for centralized AI asset management — agents, models, and tools in one place. You can register agents from other clouds, get alerts when agents or models need attention, and manage fleet health at scale.

9. SDK & API Experience

Aspect	Classic	New
Authentication	Connection strings	Project endpoint + DefaultAzureCredential
SDK	azure-ai-projects (preview)	azure-ai-projects (GA), unified Foundry SDK
Languages	Python, C# (GA); JS/TS, Java (preview)	Same
API Surface	Foundry API (limited for hub-based)	Full Foundry API — agents, evaluations, models, indexes, data
VS Code Extension	Available	Available (enhanced)

Migration Example

Classic (Hub-Based, Preview SDK):

# Used connection strings
client = AIProjectClient.from_connection_string(
conn_str="your_connection_string",
credential=DefaultAzureCredential()
)

New (Foundry Project, GA SDK):

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient

project = AIProjectClient(
endpoint="your_project_endpoint",
credential=DefaultAzureCredential()
)

10. Data Storage & Encryption

Feature	Classic	New
Default Storage	Microsoft-managed (logical separation)	Microsoft-managed (logical separation)
Bring Your Own Storage	Supported	Supported
BYOS for Agent State	Standard setup available	Standard setup available
Customer-Managed Key Encryption	Supported (FIPS 140-2, 256-bit AES)	Supported (same)
Bring Your Own Key Vault	Supported	Supported
BCDR for Agents	Customer-provisioned Cosmos DB	Customer-provisioned Cosmos DB

The storage layer is largely unchanged between portals — both support the same bring-your-own patterns for compliance.

11. Networking & Private Access

Feature	Classic	New
Private Link	Fully supported	Supported (some limitations for end-to-end isolation)
VNet Integration (Container Injection)	Supported	Supported
End-to-End Network Isolation	Fully supported (SDK, CLI, Portal)	Partially supported — use Classic, SDK, or CLI for fully isolated deployments

💡 Important: If you require end-to-end network isolation in production, Microsoft currently recommends using the Classic experience, SDK, or CLI until the new portal reaches full parity.

12. Navigation & UX Differences

Classic Portal

Left pane navigation organized by development stages: Define & Explore → Build & Customize → Observe & Improve
Customizable left pane per project, per user (pin/unpin items)
Management Center — centralized hub for projects, quotas, permissions, usage metrics
Breadcrumb navigation showing project type (Hub vs. Foundry)
Supports browsing model catalog without signing in

New Portal

Top menu bar with Build/Operate sections
Project selector in upper-left corner — switch between recently used projects
"Operate" section for centralized AI asset management (agents, models, tools)
Streamlined navigation with redesigned interface
Faster load times with dynamic prefetching
Only shows default project per Foundry resource; "View all resources" opens Classic portal

13. Foundry Local — Runs Everywhere

A capability that works across both experiences: Foundry Local lets you run LLMs on your own device for free. Integrates with inference SDKs, supports HuggingFace model compilation, and provides a local development loop.

14. Feature Availability Matrix (Comprehensive)

Feature	Classic — Hub-Based	Classic — Foundry Project	New — Foundry Project
Agents (GA)	Preview only	GA	GA
Multi-Agent Workflows	No	No	Yes
Memory (Long-Term)	No	No	Yes (Preview)
Foundry IQ Knowledge Base	No	No	Yes (Preview)
Tool Catalog (1,400+ tools)	No	No	Yes (Preview)
MCP & A2A Protocol Support	No	No	Yes
Publish to M365/Teams/BizChat	No	No	Yes
Centralized AI Asset Mgmt	No	No	Yes
Models (Azure OpenAI, etc.)	Via connections	Native	Native
Models on Managed Compute	Yes	No	No
Prompt Flow	Yes	No	No
AutoML / ML Pipelines	Yes	No	No
Evaluations	Yes	Yes (Preview)	Yes (Preview)
Playgrounds	Yes	Yes	Yes
Content Understanding	Yes	Yes	Yes
Fine-Tuning	Yes	Yes	Yes
Datasets & Indexes	Yes	Yes	Yes
Full Foundry SDK & API	Limited	Full	Full
E2E Network Isolation	Full	Full	Partial
RBAC (Resource + Project)	Hub-level	Resource + Project	Resource + Project
Azure Policy Integration	Yes	Yes	Enhanced
Disable Preview Features	RBAC or Tags	RBAC or Tags	RBAC or Tags

15. Migration Path: Classic → New

Microsoft provides a clear migration guide:

Step 1: Locate your existing Foundry resource (the AIServices kind resource created alongside your hub)
Step 2: Create a new Foundry project under that resource
Step 3: What transfers automatically: Model deployments, data files, fine-tuned models, assistants, vector stores
Step 4: What doesn't transfer: Preview agent state (threads, messages, files), open-source model deployments, hub project access
Step 5: Update SDK code — replace connection strings with project endpoints
Step 6: Optionally recreate connections for tools and data sources
Step 7: Optionally clean up hub-based projects (keep them if you still need ML training or Prompt Flow)

Estimated migration time: 5–10 minutes for project creation; additional time for agent code migration depending on complexity.

16. When Should You Move to Foundry (New)?

Move now if:

You're building agentic applications and want GA Agent Service
You need multi-agent orchestration (workflows, sequential, group chat)
You want the Tool Catalog, Memory, or Foundry IQ
You want to publish agents to Microsoft 365/Teams
You're starting greenfield and want simplified governance

Stay on Classic (for now) if:

You depend on Prompt Flow for orchestration
You deploy open-source models on managed compute (HuggingFace, etc.)
You need Azure Machine Learning features (AutoML, ML Pipelines, training)
You require fully isolated end-to-end networking in the portal (not just SDK/CLI)
You have extensive hub-based project investments you're not ready to migrate

Final Thoughts

Microsoft Foundry (New) isn't just a portal redesign — it's a platform pivot from "AI Studio for building chatbots" to "the enterprise AI agent factory." The introduction of multi-agent workflows, long-term memory, Foundry IQ knowledge bases, a 1,400+ tool catalog with MCP/A2A support, and centralized fleet management represents a generational leap.

But it's also an honest work-in-progress. Network isolation parity, Prompt Flow, and managed compute for open-source models are still reasons to keep the Classic experience bookmarked. The good news is that both portals coexist at the same URL, and switching between them is a single toggle.

The direction is clear: Foundry (New) is the future. Start building there. Fall back to Classic only when you must.

Useful Links

What is Microsoft Foundry?: https://learn.microsoft.com/en-us/azure/foundry/what-is-foundry
Microsoft Foundry Architecture: https://learn.microsoft.com/en-us/azure/foundry/concepts/architecture
Foundry Agent Service Overview: https://learn.microsoft.com/en-us/azure/foundry/agents/overview
Migrate from Hub-Based to Foundry Projects: https://learn.microsoft.com/en-us/azure/foundry-classic/how-to/migrate-project
Foundry Tool Catalog: https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/tool-catalog
Foundry IQ Knowledge Base: https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/what-is-foundry-iq
Agent Memory: https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/what-is-memory
Workflow Builder: https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/workflow
Deployment Types: https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/deployment-types
Microsoft Foundry Portal: https://ai.azure.com

Note: All information sourced from Microsoft Learn documentation as of March 2026. Feature availability may change as Microsoft continues updating both portal experiences.

Claude in Copilot? Excel on Steroids!!

michaelgoad — Mon, 02 Mar 2026 21:18:15 GMT

If you’ve been paying attention to Claude lately, you’ve probably noticed one thing.

It’s really good at Excel.

Not formulas.
Not basic charts.

I mean understanding structured data. Reasoning across multiple sheets. Spotting correlations. Pulling out insights. The kind of work that usually takes a data analyst or data scientist a lot of time.

Here’s the part most people miss.

You already get that capability inside Microsoft 365 Copilot.

Let me show you what that actually looks like in the real world.

If you want to rebuild it yourself or follow along, I’ve published everything on GitHub:
- The mock Excel data
- All of the analyst and executive prompts
- Step‑by‑step flow used in the demo

Github Resources

The scenario: a very real executive ask

This is how the work showed up for me.

In this example scenario (all data is built using Copilot for demonstration purposes), an executive leader reached out and said:

“My CFO wants a Q2 financial summary of paramedic overtime across multiple counties.”

What I got back was raw data.

Messy.
Unstructured.
No story.

Normally, this turns into hours of work:

Cleaning data
Building formulas
Creating pivot tables
Designing dashboards
Writing an executive summary

Instead, I used Copilot in Excel with Agent Mode.

Six prompts.

That’s it.

Why Agent Mode matters

Copilot in Excel with Agent Mode is where Copilot goes from “helpful assistant” to something much closer to a reasoning partner.

Under the hood, it’s doing things like:

Reasoning across multiple sheets
Writing and running Python
Catching its own errors and fixing them
Structuring data so it can be reused for dashboards and reports

This is also where you might notice model selection.

If your IT admin has enabled Anthropic, you’ll see Claude as an option. If you don’t, that’s an admin setting, not a missing feature.

And that matters, because this is exactly the type of work Claude has been getting attention for.

From raw data to executive‑ready in minutes

Here’s what I built using natural language.

Data framing

I asked Copilot to take raw overtime data and turn it into structured tables that could actually support dashboards and reporting.

Dashboard creation

Without telling it which charts to build or how to lay things out, Copilot created a working dashboard and an SBAR‑style report structure.

Storytelling

I prompted it to explain what was happening in the data. It called out overtime spikes in May and flagged operational risk.

Executive brief

I asked for CFO talking points.

Copilot generated:

Key insights
Questions a CFO should be asking
Decisions that needed to be made

What‑if analysis

One prompt created an entirely new sheet to stress‑test scenarios.

All of this happened inside Excel.

No exporting.
No rework.
No separate AI tool.

Real Talk: The part people get wrong about AI and jobs

This is where the conversation usually goes sideways.

“Isn’t this replacing data scientists?”

No.

What it replaced was busy work.

AI is very good at:

Processing structured data
Generating insights
Updating models
Iterating quickly

Humans are very good at:

Understanding context
Knowing when something feels off
Asking the right questions
Applying judgment

In this sceanrio, I knew what the CFO cared about.
I knew the story that needed to be told.
I knew what to stress‑test.

Copilot didn’t replace that. It sped it up.

What used to take hours took about half an hour, including review.

That’s not a loss of skill. That’s leverage.

Copilot as a delegation tool

This is the mindset shift.

Stop thinking about Copilot as “AI that answers questions.”

Start thinking about it as delegation.

I delegated:

Data cleanup
Analysis
Visualization
First‑draft insights

Then I reviewed it, applied judgment, and refined.

When I handed this back to the CFO, I didn’t even use Agent Mode. I switched to standard Copilot and asked:

“Summarize this in one paragraph and give me three bullets a CFO would care about.”

That was it.

Copilot understood the entire workbook and produced executive‑ready talking points.

The real takeaway

Claude’s Excel capabilities are impressive.

What matters more is where you can actually use them.

Copilot brings that level of reasoning into the tools people already work in. Excel.
Teams.
Word.

AI isn’t here to think for you.

It’s here to handle the mechanics so you can focus on judgment, context, and decisions.

That’s the difference.

Go try it.
Have some fun.
And start delegating.

HLS Copilot Use Case Webinar Series

MichaelGannotti — Fri, 20 Feb 2026 22:36:29 GMT

Friday 2/27 - Taming the Excel Jungle of Clinician Scheduling
Nurse clinicians face enough pressure without spending hours wrestling with six‑week schedules in Excel. Even with time‑tracking systems in place, many teams still export schedules, staff details, and skills into spreadsheets to manually resolve conflicts and coverage gaps—adding frustration and stress to an already demanding role. In this HLS webinar on February 27 at 12:00 PM ET, Microsoft’s Michael Gannotti will demonstrate how Microsoft 365 Copilot can transform clinician scheduling—reducing work from hours or days to mere minutes, and making last‑minute changes easy to reconcile as new schedules go live.
Meeting link active on 2/27
Friday 3/13 - Supercharging Your Marketing Research and Executive Reporting with Microsoft 365 Copilot
Marketing and executive teams are under constant pressure to deliver high‑quality research, insights, and reporting—faster than ever. In this webinar on Friday, March 13 at 12:00 PM ET, Microsoft’s Michael Gannotti will demonstrate how Microsoft 365 Copilot can streamline and turbocharge marketing research, report creation, and supporting collateral—condensing days of manual work into minutes. Learn how Copilot helps teams move from raw information to executive‑ready insights with greater speed, consistency, and impact.
Meeting link active on 3/13

🚀 Git-Driven Deployments for Microsoft Fabric Using GitHub Actions

VinodSoni — Fri, 20 Feb 2026 15:48:00 GMT

👋 Introduction

If you've been working with Microsoft Fabric, you've likely faced this question:

"How do we promote Fabric items from DEV → QA → PROD reliably, consistently, and with proper governance?"

Many teams default to the built-in Fabric Deployment Pipelines — and they work great for simpler scenarios. But what happens when your enterprise demands:

🔒 Centralized governance across all platforms (infra, app, and data)
📜 Full audit trail of every change tied to a Git commit
✅ Approval gates with reviewer-based promotion
🔑 Per-environment service principal isolation
🧩 Alignment with your existing DevOps standards

That's exactly the problem we set out to solve. In this post, I'll walk you through a production-ready, enterprise-grade CI/CD solution for Microsoft Fabric using the fabric-cicd Python library and GitHub Actions — with zero dependency on Fabric Deployment Pipelines.

🎯 What Problem Are We Solving?

Traditional Fabric promotion workflows often look like this:

Step	Method	Problem
Build in DEV workspace	Fabric Portal UI	✅ Works fine
Promote to QA	Fabric Deployment Pipeline or manual copy	⚠️ No Git traceability
Promote to PROD	Fabric Deployment Pipeline with approval	⚠️ Separate governance model from app/infra CI/CD
Rollback	🤷 Manual recreation	❌ No deterministic rollback path
Audit	"Who clicked what, when?"	❌ Limited trail

The Core Issue

Fabric Deployment Pipelines introduce a parallel governance model that's disconnected from how your platform and application teams already work. You end up with:

🔀 Two different promotion systems (GitHub Actions for apps, Fabric Pipelines for data)
🕳️ Governance blind spots between the two
😰 Cultural friction ("Why do data teams have a different process?")

Our Approach: Git as the Single Source of Truth 📖

┌─────────────┐ push to main ┌─────────────┐ │ Developer │ ──────────────────▶ │ GitHub │ │ commits to │ │ Actions │ │ Git repo │ │ Workflow │ └─────────────┘ └──────┬──────┘ │ ┌─────────────────┼─────────────────┐ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ 🟢 DEV │ │ 🟡 QA │ │ 🔴 PROD │ │ Auto │────▶│ Approval │────▶│ Approval │ │ Deploy │ │ Required │ │ Required │ └──────────┘ └──────────┘ └──────────┘

Every deployment originates from Git. Every promotion is traceable to a commit SHA. Every environment has its own approval gate. One pipeline model — across everything.

🏗️ Solution Architecture

📁 Repository Structure

fabric-cicd-project/ │ ├── 📂 .github/ │ ├── 📂 workflows/ │ │ └── 📄 fabric-cicd.yml # GitHub Actions pipeline │ ├── 📄 CODEOWNERS # Review enforcement │ └── 📄 dependabot.yml # Automated dependency updates │ ├── 📂 config/ │ └── 📄 parameter.yml # Environment-specific parameterization │ ├── 📂 deploy/ │ ├── 📄 deploy_workspace.py # Main deployment entrypoint │ └── 📄 validate_repo.py # Pre-deployment validation │ ├── 📂 workspace/ # Fabric items (Git-integrated / PBIP) │ ├── 📄 .env.example # Environment variable template ├── 📄 .gitignore ├── 📄 ruff.toml # Python linting config ├── 📄 requirements.txt # Pinned dependencies ├── 📄 SECURITY.md # Vulnerability disclosure policy └── 📄 README.md

🔧 Key Components

Component	Purpose
fabric-cicd Python library	Deploys Fabric items from Git to workspaces (handles all Fabric API calls internally)
deploy_workspace.py	CLI entrypoint — authenticates, configures, deploys, logs
parameter.yml	Find-and-replace rules for environment-specific values (connections, lakehouse IDs, etc.)
validate_repo.py	Pre-flight checks — validates repo structure, parameter.yml presence, .platform files
fabric-cicd.yml	GitHub Actions workflow — orchestrates validate → DEV → QA → PROD

✨ Feature Deep Dive

1️⃣ Per-Environment Service Principal Isolation 🔐

Instead of a single shared service principal, each environment gets its own:

DEV_TENANT_ID / DEV_CLIENT_ID / DEV_CLIENT_SECRET QA_TENANT_ID / QA_CLIENT_ID / QA_CLIENT_SECRET PROD_TENANT_ID / PROD_CLIENT_ID / PROD_CLIENT_SECRET

Why this matters:

🛡️ Least-privilege access — the DEV SP can't touch PROD
🔍 Audit clarity — you know which identity deployed where
💥 Blast radius reduction — a compromised DEV secret doesn't affect PROD

The deploy script automatically resolves the correct credentials based on TARGET_ENVIRONMENT, with fallback to shared FABRIC_* variables for simpler setups.

2️⃣ Environment-Specific Parameterization 🎛️

A single parameter.yml drives all environment differences:

find_replace: - find: "DEV_Lakehouse" replace_with: DEV: "DEV_Lakehouse" QA: "QA_Lakehouse" PROD: "PROD_Lakehouse" - find: "dev-sql-server.database.windows.net" replace_with: DEV: "dev-sql-server.database.windows.net" QA: "qa-sql-server.database.windows.net" PROD: "prod-sql-server.database.windows.net"

✅ Same Git artifacts → different runtime bindings per environment
✅ No manual edits between promotions
✅ Easy to review in pull requests

3️⃣ Approval-Gated Promotions ✅

The GitHub Actions workflow uses GitHub Environments with reviewer requirements:

Environment	Trigger	Approval
🟢 DEV	Automatic on push to main	None — deploys immediately
🟡 QA	After successful DEV deploy	✅ Requires reviewer approval
🔴 PROD	After successful QA deploy	✅ Requires reviewer approval

Reviewers see a rich job summary in GitHub showing:

📌 Git commit SHA being deployed
🎯 Target workspace and environment
📦 Item types in scope
⏱️ Deployment duration
✅ / ❌ Final status

4️⃣ Pre-Deployment Validation 🔍

Before any deployment runs, a dedicated validate job checks:

Check	What It Does
📂 workspace exists	Ensures Fabric items are present
📄 parameter.yml exists	Ensures parameterization is configured
📄 .platform files present	Validates Fabric Git integration metadata
🐍 ruff check deploy/	Lints Python code for syntax errors and bad imports

If validation fails, no deployment runs — across any environment.

5️⃣ Full Git SHA Traceability 📜

Every deployment logs and surfaces the exact Git commit being deployed:

Why this matters:

🔄 Rollback = git revert <sha> + push → pipeline redeploys previous state
🕵️ Audit = every PROD deployment tied to a specific commit, reviewer, and timestamp
🔀 Diff = git diff v1..v2 shows exactly what changed between deployments

6️⃣ Concurrency Control 🚦

concurrency: group: fabric-deploy-${{ github.ref }} cancel-in-progress: false

Two rapid pushes to main won't cause parallel deployments fighting over the same workspace. The second run queues until the first completes.

7️⃣ Smart Path Filtering 🧠

paths-ignore: - "**.md" - "docs/**" - ".vscode/**"

A README-only commit? A docs update? No deployment triggered. This saves runner minutes and avoids unnecessary approval requests for QA/PROD.

8️⃣ Retry Logic with Exponential Backoff 🔁

The deploy script wraps fabric-cicd calls with retry logic:

Attempt 1 → fails (HTTP 429 rate limit) ⏳ Wait 5 seconds Attempt 2 → fails (HTTP 503 transient) ⏳ Wait 15 seconds Attempt 3 → succeeds ✅

Transient Fabric service issues don't break your pipeline — the deployment retries automatically.

9️⃣ Orphan Cleanup 🧹

Set CLEAN_ORPHANS=true and items that exist in the workspace but not in Git get removed:

Workspace has: Notebook_A, Notebook_B, Notebook_C Git repo has: Notebook_A, Notebook_B → Notebook_C gets removed (orphan)

This ensures your workspace exactly matches your Git state — no drift, no surprises.

🔟 Dependency Management with Dependabot 🤖

# .github/dependabot.yml updates: - package-ecosystem: "pip" schedule: interval: "weekly" - package-ecosystem: "github-actions" schedule: interval: "weekly"

fabric-cicd, azure-identity, and GitHub Actions versions are automatically monitored. When updates are available, Dependabot opens a PR — keeping your pipeline secure and current.

1️⃣1️⃣ CODEOWNERS Enforcement 👥

# .github/CODEOWNERS /deploy/ @platform-team /config/ @platform-team /.github/workflows/ @platform-team

Changes to deployment scripts, parameterization, or the workflow require review from the platform team. No one accidentally modifies the pipeline without oversight.

1️⃣2️⃣ Job Timeouts ⏱️

Job	Timeout
Validate	10 minutes
Deploy (DEV/QA/PROD)	30 minutes

A hung process won't burn 6 hours of runner time. It fails fast, alerts the team, and frees the runner.

1️⃣3️⃣ Security Policy 🛡️

A dedicated SECURITY.md provides:

📧 Responsible vulnerability disclosure process
⏰ 48-hour acknowledgement SLA
📋 Best practices for contributors (no secrets in code, least-privilege SPs, 90-day rotation)

🔄 The Complete Workflow

Here's what happens end-to-end when a developer merges a PR:

1. 👨‍💻 Developer merges PR to main │ 2. 🔍 VALIDATE job runs │ ✅ Repo structure checks │ ✅ Python linting (ruff) │ ✅ parameter.yml validation │ 3. 🟢 DEPLOY-DEV job runs (automatic) │ 🔑 Authenticates with DEV SP │ 📦 Deploys all items to DEV workspace │ 📝 Logs commit SHA + summary │ 4. 🟡 DEPLOY-QA job waits for approval │ 👀 Reviewer checks job summary │ ✅ Reviewer approves │ 🔑 Authenticates with QA SP │ 📦 Deploys all items to QA workspace │ 5. 🔴 DEPLOY-PROD job waits for approval │ 👀 Reviewer checks job summary │ ✅ Reviewer approves │ 🔑 Authenticates with PROD SP │ 📦 Deploys all items to PROD workspace │ 6. 🎉 Done — all environments in sync with Git

🆚 Comparison: This Approach vs. Fabric Deployment Pipelines

Capability	Fabric Deployment Pipelines	This Solution (fabric-cicd + GitHub Actions)
Source of truth	Workspace	✅ Git
Promotion trigger	UI click / API call	✅ Git push + approval
Approval gates	Fabric-native	✅ GitHub Environments (same as app teams)
Audit trail	Fabric activity log	✅ Git commits + GitHub Actions history
Rollback	Manual	✅ git revert + auto-redeploy
Cross-platform governance	Separate model	✅ Unified with infra/app CI/CD
Parameterization	Deployment rules	✅ parameter.yml (reviewable in PR)
Secret management	Fabric-managed	✅ GitHub Secrets + per-env SP isolation
Drift detection	Limited	✅ Orphan cleanup (CLEAN_ORPHANS=true)

🚀 Getting Started

Prerequisites

3 Fabric workspaces (DEV, QA, PROD)
Service principal(s) with Contributor role on each workspace
GitHub repository with Actions enabled
GitHub Environments configured (dev, qa, prod)

Quick Setup

# 1. Clone the repo git clone https://github.com/<your-org>/fabric-cicd-project.git # 2. Install dependencies pip install -r requirements.txt # 3. Copy and fill environment variables cp .env.example .env # 4. Run locally against DEV python deploy/deploy_workspace.py

GitHub Actions Setup

Create GitHub Environments: dev, qa (add reviewers), prod (add reviewers)
Add secrets to each environment:
- DEV_TENANT_ID, DEV_CLIENT_ID, DEV_CLIENT_SECRET
- QA_TENANT_ID, QA_CLIENT_ID, QA_CLIENT_SECRET
- PROD_TENANT_ID, PROD_CLIENT_ID, PROD_CLIENT_SECRET
- DEV_WORKSPACE_ID, QA_WORKSPACE_ID, PROD_WORKSPACE_ID
Push to main — the pipeline takes over! 🎉

💡 Lessons Learned

After implementing this pattern across several engagements, here are the key takeaways:

✅ What Works Well

Teams love the Git traceability once they experience a clean rollback
Approval gates in GitHub feel natural to platform engineers
Parameter.yml changes in PRs create great review conversations about environment differences
Job summaries give reviewers confidence to approve without digging into logs

⚠️ Watch Out For

Cultural resistance is the #1 blocker — invest in enablement, not just automation
Fabric items with runtime state (data in lakehouses, refresh history) aren't captured in Git
Secret rotation across 3+ environments needs process discipline (consider OIDC federated credentials)
Run a "portal vs. pipeline" side-by-side demo early — it changes minds fast

🤝 For CSAs: Sharing This With Customers

This solution is ideal for customers who:

☑️ Already use GitHub Actions for application or infrastructure CI/CD
☑️ Have governance requirements that demand Git-based audit trails
☑️ Operate multiple Fabric workspaces across environments
☑️ Want to standardize their promotion model across all workloads
☑️ Are moving from Power BI Premium to Fabric and want to modernize their DevOps practices

🗣️ Conversation Starters

"How are you promoting Fabric items between environments today?"

"Is your data team using the same CI/CD patterns as your app teams?"

"If something goes wrong in production, how quickly can you roll back to the previous version?"

📚 Resources

🏁 Conclusion

The shift from UI-driven promotion to Git-driven CI/CD for Microsoft Fabric isn't just a technical upgrade — it's a governance and cultural alignment decision. By using fabric-cicd with GitHub Actions, you get:

📖 One source of truth (Git)
🔄 One promotion model (GitHub Actions)
✅ One approval process (GitHub Environments)
🔍 One audit trail (Git history + Actions logs)
🔐 One security model (GitHub Secrets + per-env SPs)

No parallel governance. No hidden drift. No "who clicked what in the portal."

Just Git, code, and confidence. 💪

Have questions or want to share your experience? Drop a comment below — I'd love to hear how your team is approaching Fabric CI/CD! 👇

Compliance Meets AI: What’s New in Insider Risk Management for Copilot

Jay_Cotton — Fri, 06 Feb 2026 18:57:17 GMT

AI is moving fast—and so are the risks. That’s exactly why our latest Compliance Meets AI session, “What’s New – Insider Risk Management for Copilot,” focused on how organizations can confidently secure data in an increasingly agent-driven world.

In this session, Kevin Uy walked through what’s new (and what’s next) in Microsoft Purview Insider Risk Management, with a strong spotlight on Copilot, AI agents, and Security Copilot integration. From real-world risk scenarios to live demos, this was a practical deep dive into protecting your organization while still empowering innovation.

If you missed the session we have you covered! You can find the recording below.

https://aka.ms/Compliance-Meets-Ai-Insider-Risk-Management

🔍 Key highlights included:

Insider Risk for Copilot & Agents – How Microsoft now monitors both humans and AI agents with purpose-built policies.
Risky Agents (Preview) – New capabilities that provide visibility and governance for agents built in Copilot Studio and Azure AI Foundry.
Security Copilot Triage Agents – A powerful look at AI helping security teams prioritize what truly matters by summarizing and contextualizing Insider Risk and DLP alerts.
DSPM for AI – How organizations can gain insight into risky AI usage, prompts, and responses—inside and outside the Microsoft ecosystem.

💡 One of the biggest takeaways? AI security no longer stops at users. Agents operate at machine speed, and organizations need the same level of governance, risk scoring, and investigation capabilities to keep pace.

If you’re responsible for security, compliance, data protection, or AI governance, this session is packed with insights you can apply right away.

All past recordings Can be found here Jay Cotton - YouTube and dont forget to register for our session over the next three weeks here

Compliance Meets Ai 2026: Microsoft Purview in the Age of Ai | Microsoft Community Hub

Strategic Data Replication Enhances a Single Source of Truth Architecture for Analytics & AI

Greg_Beaumont — Fri, 06 Feb 2026 17:56:16 GMT

Strategic Data Replication is not Many Sources of Truth, and can be complimentary to a Single Source of Truth architectural design. Even in a highly regulated Healthcare data ecosystem, strategic replication can maintain a compliant source of truth as part of a larger strategy to scale and control costs.

The concepts of single source of truth, data replication, data redundancy, and data duplication are often convoluted and can lead to misunderstandings that result in poorly performing and unnecessarily expensive architectures. I've published a new video that attempts to unwind the problem. No matter what data tools or cloud platforms you work with, hopefully you can find value in the content. I've added some fun analogies to data replication for cryptocurrency (such as Bitcoin) and Biology (DNA) to help explain the benefits of data replication in a multi-cloud world of analytics and AI.

How can you plan for a highly scalable, cost optimized analytics and AI architecture with high query concurrency, global users, and rapidly evolving technology having an AI Agentic future? How did Kimball vs Inmon influence the single source of truth discussion? How do you have a multi-tool environment with both corporate reporting and self-service tools that provide consistent metrics? How can you prevent the self-service spreadmarts and shadow IT nightmares of the past without stifling innovation and progress? Hopefully the content in the video below helps explain the history and frames up the future:

Introduction to Copilot Role Stories

Christina_Tillbrook — Wed, 04 Feb 2026 14:23:51 GMT

AI is becoming a core part of how people across every industry get work done. From marketers creating content faster, to clinicians improving patient care, to insurance teams automating claims and authorizations, Microsoft Copilot and AI Agents are helping people focus on what matters most.

In Role Stories we walk through real-world scenarios in specific industries and job roles using M365 Copilot & Agents. Today we are focused on Marketing & Content Creation.

Marketing teams are under constant pressure to produce more content quickly and tell better stories. That’s exactly why Role Stories exists, it's a program designed to show real, practical examples of how different jobs can use Microsoft Copilot and AI Agents to get meaningful time back.

But, Marketing isn’t just making content, it’s shaping brand voice, driving engagement, and keeping teams ahead of tight deadlines. But the work takes time. Copilot changes that by helping marketers brainstorm, write, edit, and repurpose content in minutes.
Check out the story and video below.

Let's learn about Maya the Marketer
The Role Story: Marketing - Create Better Content

On Monday morning, Maya opened a blank doc and felt that familiar knot: new blog due, socials to plan, no time. So she asked Copilot for help.

Chapter 1: Finding the angle
Maya opened Copilot in Word and prompted: “Give me 10 SEO keywords to attract people ages 20–30 who want to reduce their carbon footprint.” Copilot gave back a tight list in seconds. Maya picked a theme, and keywords, and the fog started to lift.

Chapter 2: From idea to draft
“Draft a friendly, confident blog post using Chicago Style grammar using these keywords."
Copilot in Word shaped a clean outline, wrote sections, and matched her brand voice. Maya tweaked examples and added a customer quote. The draft felt like her, just faster.

Chapter 3: One draft, many moments

“Turn this into a 100‑word LinkedIn blurb with emojis and a headline.” Done. 👍
“Create an email to advertise this blog and give me 3 different subject lines to choose from.” Done. 👍
Then she used Copilot Create to generate a photo‑realistic image that fit the story’s vibe, no endless stock‑photo hunt.
"Generate a photo‑realistic image that fit a story’s vibe about people between ages 20–30 who want to reduce their carbon footprint." 👍
“Pull short captions for Instagram.” Done. 👍

Chapter 4: Result: Less work, more impact
By lunch, Maya had a polished blog, a LinkedIn teaser, captions, headlines, and a hero image. She saved hours and widened reach without burning out. That afternoon, the post went live, and the team had time left to plan the next story.

Marketing - Content Creation: Marketing scenario: Content creation (Copilot Scenario Library) – Microsoft Adoption
Find Your Role and Your Story: Microsoft Scenario Library – Microsoft Adoption

Compliance Meets AI: DLP for Copilot Is Better Than Ever.

Jay_Cotton — Wed, 28 Jan 2026 00:51:35 GMT

Last week we hosted Session 2 of our “Compliance Meets AI” series, and the focus couldn’t be more timely: Data Loss Prevention (DLP) for Microsoft 365 Copilot. The conversation was practical, candid, and packed with real-world guidance for organizations navigating AI adoption responsibly.

If you missed it, no worries we have you covered. You can view the recording below.

https://aka.ms/Compliance-Meets-Ai-2026-DLP

💡 Key takeaways from the session:

DLP now extends directly into Copilot—including Copilot Chat and Copilot experiences in Word, Excel, and PowerPoint—allowing organizations to block sensitive data from being processed or returned in AI responses.
We walked through how policies can restrict prompts (using Sensitive Information Types and Sensitivity Labels) and responses , giving security teams precise control without shutting down productivity.
A live demo showed how Copilot respects Purview policies in real time—no theoretical slides, just real enforcement.
We also addressed one of the biggest questions we hear from customers: AI doesn’t create new risk—it exposes existing oversharing, and DLP is a critical safety net while organizations mature their data governance.

🔥 Bonus highlights included discussions on endpoint DLP, blocking uploads to generative AI websites, role-based access for investigations, and what’s coming next—like network DLP and agent governance.

If you’re exploring Copilot (or already rolling it out), this session made one thing clear: you don’t have to choose between innovation and compliance—you can have both.

📅 Next up: Defender for Cloud Apps & AI applications
📺 Recording and slides will be shared with all registered attendees

Please register for all sessions here Compliance Meets Ai 2026: Microsoft Purview in the Age of Ai | Microsoft Community Hub

Thanks to everyone who joined, asked thoughtful questions, and helped make this such a strong discussion. More to come—this series is just getting started. 🚀

#ComplianceMeetsAI #MicrosoftPurview #DataLossPrevention #Copilot #ResponsibleAI #Security #Compliance

Compliance Meets AI 2026 Kickoff: DSPM for AI

Jay_Cotton — Mon, 26 Jan 2026 23:39:02 GMT

🚀 Compliance Meets AI 2026 Kickoff: DSPM for AI

What a great way to kick off the Compliance Meets AI 2026 series! For the first session we took a deep dive into Data Security Posture Management (DSPM) for AI and explored how organizations can govern, protect, and gain visibility into generative AI usage—without slowing innovation.

If you missed the session, don't worry you can watch the recording here

https://aka.ms/Compliance-Meets-Ai-2026-DSPM

🔍 Key highlights from the session:

How Microsoft Purview DSPM for AI provides visibility into Copilot, Copilot Studio, and AI agents
What’s new in the DSPM (Preview) experience and how it unifies AI observability with data security
Tracking prompts and responses, sensitive data exposure, and risky AI behaviors
Governing agents (first‑party, declarative, and custom) across Microsoft 365
How DSPM integrates with DLP, Insider Risk, Communication Compliance, and SharePoint Advanced Management

This session set the foundation for the weeks ahead, where we’ll go even deeper into DLP for Copilot & AI, Defender for Cloud Apps, Insider Risk, Network protection, and agent governance.

👏 Huge thanks to everyone who joined, asked thoughtful questions, and made the discussion so engaging.

👉 If you missed it—or want to register for the upcoming sessions—check out the series here: https://aka.ms/Compliance-Meets-Ai-2026

AI is moving fast. Governance needs to move smarter. Looking forward to what’s next!

#ComplianceMeetsAI #MicrosoftPurview #Copilot #AIandSecurity #DataProtection #DSPM #AgentGovernance #Microsoft365

Supercharging SharePoint Metadata with the Knowledge Agent in Microsoft 365 Copilot

NicholasAquino — Mon, 26 Jan 2026 14:02:55 GMT

Organizations adopting Microsoft 365 Copilot are quickly realizing that great AI outcomes depend on great data foundations. But for many teams, keeping SharePoint content well‑structured, tagged, and optimized for search has always been a challenge.

Enter Knowledge Agent (Preview) - now included with Microsoft 365 Copilot (premium) - a powerful new capability that automates metadata enrichment inside SharePoint. In just a few minutes, it can transform an under‑tagged document library into a rich, AI‑ready resource that dramatically improves your Copilot experiences.

In a recent internal walkthrough, I tested the setup and was surprised by two things:

How simple it was to enable, even as an administrator.
How quickly it added meaningful metadata across an entire library.

Here’s what I learned - and why this matters for organizations.

Fast Setup With Zero Friction

To enable Knowledge Agent, I connected to SharePoint Online via PowerShell and configured the tenant settings. Even in a demo environment, the process was quick: scope your sites, validate the configuration, and Knowledge Agent becomes visible and active almost immediately.

No lengthy provisioning.
No complex dependencies.
Just turn it on and it lights up.

Automated Metadata That Powers Better Search & Better AI

Once enabled, Knowledge Agent is available to analyze your SharePoint libraries and:

Reads documents and extracts meaningful context
Automatically generates new metadata columns
Populates those columns with structured information
Applies improvements across the entire library when requested

I tested this with a library full of medical procedure documents. Within moments, Knowledge Agent:

Identified key attributes across all files
Suggested and created metadata columns
Added structured classifications to each document

This enriched data is then available to improve your:

Copilot search index
SharePoint embeddings
Custom agents you build on top of SharePoint
Future Microsoft 365 Copilot experiences

The result?
More accurate responses, better grounding, and a significant boost in AI performance.

Why This Matters for AI Readiness

Customers often ask:
“Why can’t Copilot find the right documents?”
or
“Why does our AI agent return inconsistent results?”

The answer is usually metadata - or the lack of it.

Knowledge Agent solves this by automating the hard part: reading files, extracting meaning, and generating structure at scale. Even a single well-optimized SharePoint library can dramatically improve:

Governance controls
Document discovery
Copilot Chat answers
SharePoint‑based Agents
Enterprise search reliability

It’s one of the fastest ways to uplift AI accuracy without requiring major data cleanup projects.

A Simple Way to Boost AI Value Immediately

The Knowledge Agent is one of the most practical additions to the Microsoft 365 ecosystem this year. It gives administrators a powerful way to modernize file libraries with minimal effort while helping organizations get the most out of Copilot.

If your team relies on SharePoint, Copilot, or is exploring custom agent development, turning on Knowledge Agent should be at the top of your checklist. It’s fast, impactful, and unlocks meaningful value across your AI stack.

Links
SharePoint Showcase: How Metadata and the Knowledge Agent Elevate Microsoft 365 Copilot Responses | Microsoft Community Hub

Microsoft 365 Copilot hub | Microsoft Learn

Get ready for Microsoft 365 Copilot with SharePoint Advanced Management - SharePoint in Microsoft 365 | Microsoft Learn

Unlocking Information with Microsoft 365 Copilot Agents in SharePoint

Fabric Data Agent for Semantic Model added to our free CMS Github Repo

Greg_Beaumont — Wed, 21 Jan 2026 21:35:29 GMT

For the past two years I’ve been working with my colleague Inder Rana to build out a GitHub repo that can be leveraged by Fabric users for training and testing purposes. In the most recent update we have added a new Fabric Data Agent that works with the semantic model using Direct Lake mode. The new AI Instructions for the Direct Lake Semantic Model will also work with Power BI Copilot (see examples for Power BI Copilot standalone version in the video below!). Alongside the existing Lakehouse/Warehouse Fabric Data Agent, you can now compare and contrast both versions.

The updated GitHub repo that deploys 275 million rows of real CMS Medicare Part D healthcare data to your Fabric environment for an end-to-end demo and testing solution can be found at this link: fabric-samples-healthcare/analytics-bi-directlake-starschema at main · isinghrana/fabric-samples-healthcare

If you have already deployed the GitHub repo, you can add the new Semantic Model Data Agent by following these instructions:

https://github.com/isinghrana/fabric-samples-healthcare/blob/main/analytics-bi-directlake-starschema/docs/5-CreateAISkill.md#optimize-semantic-model-for-power-bi-copilot-and-fabric-data-agent

The GitHub repo can deploy all of the following Fabric components in a single quick install script:

Lakehouse
Notebooks
Data Factory Pipeline
Semantic Model (optimized for Power BI Copilot and Fabric Data Agents)
Power BI Report
Data Agent for Lakehouse

The following components can be deployed manually after running the quick install script:

Warehouse
Data Agent for Semantic Model

Copilot: Data Loss Prevention with Sensitive Information Types

Jay_Cotton — Wed, 21 Jan 2026 00:30:52 GMT

Curious about how to protect sensitive data while leveraging Microsoft Copilot and Copilot Chat? In my latest session, I walk through setting up Data Loss Prevention (DLP) policies using sensitive information types—making it easier than ever to safeguard your organization’s data across Copilot, Word, Excel, and PowerPoint.

Whether you’re in healthcare, compliance, or just passionate about security, this demo shows how simple and powerful these new controls are. Watch to see real-world examples, alerting in action, and tips for rolling out DLP at scale.

https://aka.ms/DLP-for-copilot

Stay tuned for more insights—let’s keep our data safe and our innovation moving forward! 💡🔒

#MicrosoftCopilot #DLP #CloudSecurity #DataProtection #Compliance #ComplainceMeetsAi

AgentRx & Copilot: Agentic Skills for Healthcare Professionals

samhitaraman — Fri, 20 Feb 2026 22:35:12 GMT

Join us for a new wave of expert-led Copilot Agents training, designed to help healthcare professionals demystify the agentic world and unlock the full potential of AI in their daily workflows.

Why Agents & Copilot Matter Now

Human labor is reaching its limits:

80% of the global workforce lack enough time or energy to do their work
53% of leaders say productivity must increase
82% expect to use agents to meet the demand for more workforce capacity

Source: https://aka.ms/2025WorkTrendIndex

Agents and Copilot are transforming how healthcare organizations operate—moving from AI assistants to digital colleagues and, eventually, agent-operated workflows.

What You’ll Learn:

Introduction of Agents: what they are and why they matter
Explore types of agents: both free and first-party agents, including Analyst agent!
Live Demo: Build an agent in minutes using natural language. Follow along and you will leave the session an agent builder!
Healthcare Use Cases & Tips: Demonstrations of agents in real world scenarios for the healthcare space.

Join thousands of healthcare professionals who have transformed their workflows with Agents and Copilot. Reserve your spot to start your journey below!

Date	Time	Registration Link
~~January 30th~~	~~12:00 - 1:00PM ET~~	~~AgentRx \| Jan 30~~
~~February 6th~~	~~12:00 - 1:00PM ET~~	~~AgentRx \| Feb 6~~
~~February 13th~~	~~12:00 - 1:00PM ET~~	~~AgentRx \| Feb 13~~
~~February 20th~~	~~12:00 - 1:00PM ET~~	~~AgentRx \| Feb 20~~
Friday Feb 27th	12:00 - 1:00PM ET	AgentRx \| Feb 27
Friday March 6th	12:00 - 1:00PM ET	AgentRx \| Mar 6
Friday March 13th	12:00 - 1:00PM ET	AgentRx \| Mar 13
Friday March 20th	12:00 - 1:00PM ET	AgentRx \| Mar 20
Friday March 27th	12:00 - 1:00PM ET	AgentRx \| Mar 27