AutoPlay, the pop-up that asks what to do when you plug in a USB drive or SD card, is next in line for a WinUI 3 rebuild. Microsoft confirmed it in a July 31 update on its Windows quality commitment.

So, the AutoPlay dialog is finally getting proper dark mode support, Fluent typography, and the rounded, consistent design language the rest of Windows 11 has had.

Windows 11 still runs on a patchwork of code from wildly different eras, some dialogs redesigned for Fluent Design, others untouched since Windows 7 or earlier. It’s a running joke that the OS can look modern in one window and decades old if you go into deeper settings.

Considering the complexity and risk, rebuilding it all at once wasn’t realistic, so Microsoft has been working through it dialog by dialog.

Microsoft has already been chipping away at this. Windows Latest has covered the File Explorer Properties dialog getting rebuilt in WinUI, a growing list of other legacy dialogs headed the same way, and most recently, Print Management getting an early WinUI-based test build. AutoPlay is the next name on that list, and testing is already underway ahead of a planned drop into Windows Insider Preview Experimental builds.

AutoPlay in Windows 11 is getting a WinUI 3 update

AutoPlay first showed up in Windows XP in 2001, and refined the older AutoRun feature so that inserting a disc or drive prompted you with choices instead of silently launching whatever program the media pointed to.

Vista tightened it for security, and from Windows 7 onward, AutoPlay has looked basically the same with a plain white background, basic Win32 controls, and a list of app icons to pick from. It’s one of the most-seen dialogs in Windows, and one of the least changed.

Fortunately, this will be the last year that we have to see this, as Microsoft’s blog says:

“We’ve strengthened the fundamentals of WinUI 3 and extended it into more of the Windows shell, including Widgets and the new Run experience, with Autoplay dialog and more File/Folder Properties dialogs coming soon to Windows Insider Preview Experimental builds.”

Technically, that means AutoPlay is being rebuilt from scratch on WinUI 3. Win32 dialogs like AutoPlay don’t inherit Windows’ system-wide dark mode automatically; each one has to explicitly opt in and paint itself for it, which is why so many old dialogs flashed white even with dark mode switched on everywhere else.

WinUI 3 framework handles theming, scaling, and Fluent styling natively instead of requiring a manual patch. Marcus Ash, CVP Design and Research for Windows, while replying to a request for AutoPlay to get modernized back in May, said he was looking forward to the day he could confirm it was happening, instead of promising a quick dark mode fix.

Microsoft is making WinUI 3 even better

The Windows President’s blog post also mentions extending WinUI 3 into more of the Windows shell, the collective term for the interface layer users interact with directly, including the taskbar, Start menu, File Explorer, and system dialogs like this one.

Widgets and the new Run experience are already strengthened, with more File and Folder Properties dialogs coming next to Experimental builds.

Microsoft also mentions “substantial improvements in memory efficiency and latency” behind this work. WinUI 3 apps are tuned to use less memory by design, and the company has also confirmed a more efficient memory allocator and reduced overhead in the Chromium and WebView2 components still running inside parts of the OS.

That said, every dialog moved off legacy Win32 or WebView2 code and onto native WinUI is one less piece of inefficiency in Windows.

A lighter Windows 11 is Microsoft’s goal

Microsoft has previously admitted Windows 11 has become a memory hog and promised optimization work for PCs with 8GB of RAM and above by the end of 2026.

The company is also going back on their previous statements recommending 32GB RAM as a “no-worries upgrade” for serious gamers, as RAM prices climbed and 8GB machines became the reality Microsoft has to build for.

AutoPlay in Windows 11 is one more legacy dialog that stops carrying Win32’s dead weight, and with WinUI-based Widgets, Run, Properties, Print Management, and everything still left on Microsoft’s list, Windows 11 will finally stop feeling inconsistent.

The post Microsoft is burying Windows 11’s legacy UI one by one, and AutoPlay is next for WinUI 3 appeared first on Windows Latest

By Aditya Duvuri, Anil Dogra, Pranay Lohia, AI Omar Rajawat, Gautam Juneja, Vikas Nimmagadda

We’re seeing significant interest in migrating database workloads from Oracle to Azure Database for PostgreSQL. Historically, schema conversion has been one of the most technically challenging and expensive steps in that journey, demanding specialist knowledge of both engines and stretching migration timelines before a single row of data moves. Recent advances in AI-assisted schema conversion are changing that, turning what used to be a long, manual effort into a faster, more accessible, and lower-cost proposition. This post looks at what that shift means in practice for teams moving to Azure Database for PostgreSQL flexible server.

Oracle schema conversion is where the complexity of translating schema and code objects to PostgreSQL becomes visible. Packages, procedures, triggers, custom types, and dependencies built up over years must be mapped to PostgreSQL-compatible definitions while preserving the relationships that make the schema work.

Generally available since May 2026, the feature is built into the PostgreSQL extension for Visual Studio Code, published by Microsoft. It helps teams convert Oracle schema and code objects — tables, views, constraints, packages, procedures, functions, and triggers — into PostgreSQL-compatible definitions for Azure Database for PostgreSQL flexible server, with no separate conversion utility to install and no disconnected workflow to manage.

It brings schema discovery, conversion, compile validation, and review into one project-based experience. Teams can connect to Oracle, select schemas, and configure a Microsoft Foundry connection in the same project. The extension then translates Oracle-specific constructs, compiles and syntax-checks converted DDL into scratch schemas on Azure Database for PostgreSQL flexible server and surfaces unresolved items as review tasks that teams can work through with GitHub Copilot agent mode.

Why schema conversion deserves a better workflow

Traditional conversion tools can produce a useful first pass, but the long tail of the process is rarely solved by generating replacement DDL alone. Teams still need clear answers to practical questions: What converted successfully? What needs attention? Which Oracle constructs require a PostgreSQL design decision? Which items should be reviewed first?

We designed the schema conversion experience around those questions. The goal is not to hide complexity behind a single score. It is to help teams make steady progress while keeping the work visible and reviewable.

What the schema conversion experience provides

The experience guides teams through a schema conversion project rather than a collection of separate scripts. It discovers the selected Oracle schemas and converts both the relational model and the code that runs on it: tables, indexes, sequences, primary key, unique, check and foreign key constraints, views and materialized views, synonyms, and Oracle object types — along with the PL/SQL that is usually the hardest part of the migration. Packages and package bodies, package-level state, standalone procedures and functions, and triggers are translated into PostgreSQL functions, procedures, and trigger functions.

Oracle-specific constructs are mapped to PostgreSQL equivalents rather than dropped or stubbed out. REF CURSOR and SYS_REFCURSOR become PostgreSQL refcursor; CLOB and BLOB columns become text and bytea ; and NUMBER and VARCHAR2 are mapped by precision and length to their closest PostgreSQL types. Oracle date functions such as ADD_MONTHS, LAST_DAY, MONTHS_BETWEEN, and TRUNC are resolved through the orafce extension, which the project detects and flags for you before deployment. Every converted definition is compiled against scratch schemas on Azure Database for PostgreSQL flexible server, so the deployment script you end up with is an organized, dependency-ordered set of PostgreSQL SQL artifacts that has already been proven to build.

Objects that still require human judgment are surfaced as review tasks. Teams can inspect the source and converted definitions side by side, work through the remaining items, and use GitHub Copilot agent mode for guided assistance — keeping automation and human review in the same workflow.

How it works: the system architecture

Under the hood, the conversion engine follows one principle — the language model is a single, bounded stage; it never has the first or the last word. Deterministic steps decide what the model sees and what it is allowed to produce.

• Deterministic in. Rule-based extraction reads the Oracle DDL and metadata, then a dependency-graph decomposition splits the estate into bounded, dependency-ordered chunks — so every object is converted in the context that keeps it correct.
• Bounded conversion. A tiered model strategy through the Microsoft Foundry connection translates each chunk with structured, contract-wrapped input and output. Even very large PL/SQL packages are split and converted member by member, so nothing is trusted as a monolith.
• Deterministic out. Converted objects pass through review, then compile-and-verify against scratch schemas on Azure Database for PostgreSQL flexible server, and finally dependency-ordered deploy assembly. Unresolved items become review tasks, and every object carries a per-object audit trail.

A continuous-improvement loop closes the system: the engineering team maintains a versioned regression suite of supported conversion patterns, and an executable benchmark tracks regressions as the pipeline evolves.

Proven in production

The approach has been exercised on real enterprise estate. Across representative production runs totaling more than 60,000 schema objects; conversion reached roughly 98% overall — with several schemas converting at a full 100%. The hardest tail, PL/SQL package members, now compiles at 96% across more than 20,000 members thanks to targeted coverage and a resilient compile stage.

Conversion outcome and review status are separate measures. Objects that convert and compile cleanly are safe to deploy as they are; the rest are deliberately routed into a prioritized review queue rather than silently accepted. In a representative single-schema run, no object ended in a hard conversion failure, and a cleanly generated object can still involve a PostgreSQL design decision. That is the workflow operating as intended: automation absorbs the volume, and review tasks to keep the remaining judgment calls visible, ordered, and auditable.

Measured, not asserted: the SchemaBench eval

Quality is verified by running it. SchemaBench, the evaluation framework, deploys each converted schema to a live PostgreSQL database and probes real behavior — whether constraints still fire and whether objects still resolve — rather than comparing DDL text. It scores seven weighted dimensions: semantic fidelity, structure, constraints, completeness, performance, target idioms, and maintainability, behind hard gates. On the e-commerce benchmark, the strongest model scored 96.1 overall with 100% semantic fidelity and a ~98% behavioral-probe pass rate. Every failure a migration hits becomes a permanent regression test the next run has to pass.

Learn more: Oracle to Azure Database for PostgreSQL schema conversion overview

WCF Relay listeners that still negotiate TLS 1.0 can fail to connect through Azure Relay. The symptom appears on the sender, which connected successfully before and now fails every call with System.ServiceModel.EndpointNotFoundException: no connected listeners accepted the connection within timeout. If you run a WCF Relay listener on the .NET Framework, and especially one built against an older version of the WindowsAzure.ServiceBus package or Microsoft.ServiceBus.dll, it is worth checking how it negotiates TLS.

Azure Relay Hybrid Connections are not affected and need no action. They use HTTP and WebSockets through the Microsoft.Azure.Relay package, a different stack from the WCF Relay path described here.

What is happening

TLS 1.0 and TLS 1.1 are deprecated. We retired them across Azure services, and have since retired them at the operating system level as well. The rendezvous path kept accepting TLS 1.0 until that operating system change landed, which is why a listener that had run until now can fail going forward.

These failures come from a listener that still asks for TLS 1.0 when it opens its rendezvous connection to Relay, which older .NET Framework defaults, application configuration, registry settings, or startup code can all cause. Relay requires TLS 1.2 or later, so the rendezvous connection never completes, or the listener fails to connect at all. Either way no listener is registered, and the sender sees the endpoint as unreachable.

Recommended actions

Start with the listener application, since that change is scoped to the one you are fixing and is usually enough to resolve this. Check whether it sets a TLS or SSL version explicitly in code or configuration, and if it does, remove the explicit setting so the operating system chooses the protocol, or set TLS 1.2 or later.

The quickest change is configuration-only. Two AppContext switches in the application configuration file put the listener back on a supported protocol, and both go in a single semicolon-delimited value attribute.

<configuration> <runtime> <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=false;Switch.System.Net.DontEnableSystemDefaultTlsVersions=false" /> </runtime> </configuration>

Rebuilding against a current .NET Framework resolves it as well. Where startup code is easier to change than configuration, setting ServiceBusEnvironment.SystemConnectivity.Mode to ConnectivityMode.Https and ServicePointManager.SecurityProtocol to SecurityProtocolType.Tls12 moves the connection to HTTPS and TLS 1.2. Applications that target .NET Framework 3.5 and use TCP transport security are pinned to SSL 3.0 and TLS 1.0, so those need to be retargeted.

Where the application cannot be changed, the same behavior can be set for the whole machine through two registry values, SchUseStrongCrypto and SystemDefaultTlsVersions, added as DWORD 1 under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 and HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319, using v2.0.50727 in place of v4.0.30319 for .NET Framework 3.5. Both values must be created, and they apply to every .NET Framework application on the machine, so treat this as the fallback. The .NET Framework TLS best practices guidance covers both approaches in full.

Once the change is in place, restart the application and confirm that the listener and sender both connect. The call that previously failed with EndpointNotFoundException should complete as soon as the Relay connection negotiates a supported TLS version.

For more about the service itself, see the Azure Relay overview, the Azure Relay API overview, and the Azure Relay port settings.

Help and support

If you have questions, get answers from community experts in Microsoft Q&A or GitHub. If you have a support plan and you need technical help, create a support request.

As organizations race to automate decision-making, content generation, analysis, and execution at scale, the future is shifting from isolated AI agents to multi-agent workflows where specialized agents collaborate, delegate, challenge, and refine each other's work. By allowing multiple AI agents to work together, organizations can tackle complex business processes more efficiently, improve accuracy, and scale operations in ways that would be difficult for a single agent to achieve alone.

In this blog, we will explore 5 types of multi-agent workflows offered by the Microsoft Agent Framework to design, manage, and scale complex multi-agent workflows.

Prerequisites for the Tutorial:

1. Azure Subscription
2. Microsoft Foundry resource deployed in a resource group. Deploy any model (such as gpt-4.1-mini) in the Foundry project.

1. Concurrent Orchestration

In this orchestration, the same input is sent to multiple agents simultaneously and consolidated. Each agent handles tasks independently and the results are combined. All agents work at the same time.

Used when:

1. You need different approaches/perspectives for a problem
2. Group decision making-based scenarios
3. Voting-based scenarios

Use Case: Ticket Assessment on Various Criteria

Consider a customer-support use case in which a new ticket must be assessed quickly and routed correctly. With concurrent orchestration, the same incoming ticket is sent to three specialized agents at the same time.

import os import asyncio from typing import cast from agent_framework import Message from agent_framework.foundry import FoundryChatClient from azure.identity import DefaultAzureCredential from agent_framework.orchestrations import ConcurrentBuilder from dotenv import load_dotenv load_dotenv() async def main(): credential = DefaultAzureCredential() chat_client = FoundryChatClient( credential=credential, project_endpoint=os.getenv("AZURE_AI_PROJECT_ENDPOINT"), model=os.getenv("AZURE_AI_MODEL_DEPLOYMENT_NAME") ) sentiment_agent = chat_client.as_agent( name="Sentiment Agent", instructions="You are a helpful assistant that analyzes the sentiment of a support ticket." ) category_agent = chat_client.as_agent( name="Category Agent", instructions="You are a helpful assistant that categorizes a support ticket into categories such as Billing, Technical, Refund, or Account." ) priority_agent = chat_client.as_agent( name="Priority Agent", instructions="You are a helpful assistant that determines the priority of a support ticket as High, Medium, or Low." ) workflow = ConcurrentBuilder( participants = [sentiment_agent, category_agent, priority_agent] ).build() result = await workflow.run("I was charged twice and I'm furious — refund me now!") outputs = result.get_outputs() i = 1 for response in outputs: for msg in cast(list[Message], response.messages): name = msg.author_name or ("assistant" if msg.role == "assistant" else "user") print(f"{'-' * 60}\n{i:02d} [{name}]\n{msg.text}") i += 1 if __name__ == "__main__": asyncio.run(main())

 

2. Sequential Orchestration

Used when the output of one agent is consumed by subsequent agents one after another. This pattern is ideal for workflows where each step depends on the previous one.

Used When:

1. There is a multi-step process, where each step relies on the output of the previous one.
2. Situations that benefit from iterative refinement, such as drafting, reviewing, and improving content.
3. Each stage produces an output and the next output builds upon that output.

Use Case: Automated Support Ticket Triage

Consider a customer-support operation that receives large volumes of unstructured tickets and must route each one accurately. In this sequential workflow, a Summarizer Agent first condenses the raw ticket into one or two sentences that capture the customer’s core intent. Its output is then passed to a Classifier Agent, which assigns exactly one category—Billing, Technical, Refund, or Urgent.

import os import asyncio from typing import cast from agent_framework import Message from agent_framework.foundry import FoundryChatClient from azure.identity import DefaultAzureCredential from agent_framework.orchestrations import SequentialBuilder from dotenv import load_dotenv load_dotenv() async def main(): credential = DefaultAzureCredential() chat_client = FoundryChatClient( credential=credential, project_endpoint=os.getenv("AZURE_AI_PROJECT_ENDPOINT"), model=os.getenv("AZURE_AI_MODEL_DEPLOYMENT_NAME") ) summarizer_agent = chat_client.as_agent( name="Summarizer Agent", description="Summarizes a support ticket into 1-2 sentences of core intent.", instructions="You are a helpful assistant that summarizes support tickets into concise summaries." ) classifier_agent = chat_client.as_agent( name="Classifier Agent", description="Classifies a ticket summary into: Billing, Technical, Refund, or Urgent.", instructions="You are a helpful assistant that classifies a support ticket summary strictly into one of the following categories: Billing, Technical, Refund, or Urgent." ) workflow = SequentialBuilder( participants=[summarizer_agent, classifier_agent], output_from = "all" ).build() ticket = "I was charged twice for my subscription this month and need a refund ASAP." result = await workflow.run(ticket) outputs = result.get_outputs() i = 1 for response in outputs: for msg in cast(list[Message], response.messages): name = msg.author_name or ("assistant" if msg.role == "assistant" else "user") print(f"{'-' * 60}\n{i:02d} [{name}]\n{msg.text}") i += 1 if __name__ == "__main__": asyncio.run(main())

 

3. Group Chat Orchestration

Manages a collaborative conversation between multiple agents, optionally involving a human in the process (Human-in-the-Loop). There is a central chat manager that decides which agent responds next and when to request for human input.

Used when:

1. Scenarios that require debates or group brainstorming.

Use Case: Cross-Functional Feature Proposal Review

A product team uses specialist agents to review a feature proposal in one shared discussion. Product Agent assesses value, Engineering Agent feasibility, Design Agent usability, and Security Agent compliance. A Manager Agent guides the debate and concludes with a recommendation to proceed, revise, or reject.

import os import asyncio from typing import cast from agent_framework import AgentResponseUpdate, Message from agent_framework.foundry import FoundryChatClient from azure.identity import DefaultAzureCredential from agent_framework.orchestrations import GroupChatBuilder from dotenv import load_dotenv load_dotenv() async def main(): credential = DefaultAzureCredential() chat_client = FoundryChatClient( credential=credential, project_endpoint=os.getenv("AZURE_AI_PROJECT_ENDPOINT"), model=os.getenv("AZURE_AI_MODEL_DEPLOYMENT_NAME") ) product_agent = chat_client.as_agent( name="Product Agent", instructions="You are a helpful assistant that argues for user value and business priority.", default_options={"store": False} # turn off server-side storage, so the client keeps history in the local session and re-sends the full conversation every turn. ) engineering_agent = chat_client.as_agent( name="Engineering Agent", instructions="You are a helpful assistant that raises engineering feasibility, effort, and technical risks.", default_options={"store": False} ) design_agent = chat_client.as_agent( name="Design Agent", instructions="You are a helpful assistant that focuses on UX and usability concerns.", default_options={"store": False} ) security_agent = chat_client.as_agent( name="Security Agent", instructions="You are a helpful assistant that flags compliance and data-protection issues.", default_options={"store": False} ) manager_agent = chat_client.as_agent( name="Manager Agent", instructions=( "You moderate a design-review discussion. Each turn, choose the SINGLE next " "participant to speak from: Product Agent, Engineering Agent, Design Agent, " "Security Agent. Never select the same participant twice in a row. Once every " "perspective has been heard and a clear decision is reached, terminate the " "conversation with a short recommendation." ), default_options={"store": False} ) workflow = GroupChatBuilder( participants=[product_agent, engineering_agent, design_agent, security_agent], orchestrator_agent=manager_agent, max_rounds=5, intermediate_output_from="all", ).build() stream = await workflow.run("Proposal: add biometric login to the mobile app. Should we build it next quarter?", stream=True) last_executor = None async for event in stream: if event.type in ("intermediate", "output") and isinstance(event.data, AgentResponseUpdate): executor = event.data.author_name if executor != last_executor: print(f"\n{'-' * 60}\n{executor}:\n") last_executor = executor print(event.data.text, end="", flush=True) result = await stream.get_final_response() print(f"\n{'=' * 60}\nFinished ({len(result.get_outputs())} output messages).") if __name__ == "__main__": asyncio.run(main())

 

4. Handoff Orchestration

This orchestration lets agents assign a task to other agents based on their expertise.

Used when:

1. Multiple agents are involved, but the order of execution is unknown/non-deterministic.

Use Case: Dynamic Customer Support Routing

A Triage Agent greets the customer, identifies the issue, and hands the conversation to the right specialist: a Refund Agent for refunds and returns, or an Order Status Agent for shipping updates. If the customer’s need changes, the specialist hands the conversation back to triage for seamless rerouting.

import os import asyncio from typing import cast from agent_framework import AgentResponseUpdate, Message from agent_framework.foundry import FoundryChatClient from azure.identity import DefaultAzureCredential from agent_framework.orchestrations import HandoffBuilder from dotenv import load_dotenv load_dotenv() async def main(): credential = DefaultAzureCredential() chat_client = FoundryChatClient( credential=credential, project_endpoint=os.getenv("AZURE_AI_PROJECT_ENDPOINT"), model=os.getenv("AZURE_AI_MODEL_DEPLOYMENT_NAME"), ) triage_agent = chat_client.as_agent( name="triage_agent", instructions=( "Greet the customer and briefly acknowledge their issue in one sentence, " "then hand off to the right specialist." ), default_options={"store": False}, require_per_service_call_history_persistence=True ) refund_agent = chat_client.as_agent( name="refund_agent", instructions="You process refunds and returns. Ask for the order number and resolve the request.", default_options={"store": False}, require_per_service_call_history_persistence=True ) order_status_agent = chat_client.as_agent( name="order_status_agent", description="Answers questions about order status and shipping.", instructions="You answer order status and shipping questions.", default_options={"store": False}, require_per_service_call_history_persistence=True ) workflow = ( HandoffBuilder(participants=[triage_agent, refund_agent, order_status_agent]) .with_start_agent(triage_agent) .add_handoff(triage_agent, [refund_agent, order_status_agent]) # triage can route to either .add_handoff(refund_agent, [triage_agent]) # specialists can hand back .add_handoff(order_status_agent, [triage_agent]) .build() ) # Interactive loop: run once, then answer each request_info until it ends. user_message: str | None = "Hi, I was charged twice for order #12345 and want a refund." responses: dict | None = None last_executor = None while True: if responses is not None: stream = workflow.run(responses=responses, stream=True) else: stream = workflow.run(user_message, stream=True) pending_request_id = None async for event in stream: if event.type in ("intermediate", "output") and isinstance(event.data, AgentResponseUpdate): executor = event.data.author_name if executor != last_executor: print(f"\n{'-' * 60}\n{executor}:\n") last_executor = executor print(event.data.text, end="", flush=True) elif event.type == "request_info": pending_request_id = event.request_id # workflow is waiting for the user if pending_request_id is None: break # no input requested -> conversation finished user_text = input("\n\nYou: ") if not user_text.strip(): break # empty answer terminates the handoff workflow responses = {pending_request_id: [Message(role="user", contents=[user_text])]} if __name__ == "__main__": asyncio.run(main())

 

5. Magentic Orchestration

This orchestration allows for dynamic collaboration of multiple agents. Used when the exact workflow is not known upfront, and for complex open-ended problems.

There is a task ledger which keeps track of the tasks that need to be done. The progress ledger keeps track of the tasks completed and what all was learnt.

The manager agent does the following:

1. Maintains the overall goal
2. Creates and updates the task ledger
3. Chooses which agent should work next
4. Tracks progress in the progress ledger
5. Replans when stuck
6. Synthesizes the final answer

Use Case: Autonomous Blog Drafting and Review

Given a topic, a Magentic manager plans and drives an iterative draft-and-review cycle: it directs a writer agent to produce the post, routes the draft to an editor agent for clarity and length feedback, loops back for revisions when needed, and finalizes the post once it meets the quality bar — all without a human specifying the step order.

import os import asyncio from typing import cast from agent_framework import AgentResponseUpdate from agent_framework.foundry import FoundryChatClient from azure.identity import DefaultAzureCredential from agent_framework.orchestrations import MagenticBuilder from dotenv import load_dotenv load_dotenv() async def main(): credential = DefaultAzureCredential() chat_client = FoundryChatClient( credential=credential, project_endpoint=os.getenv("AZURE_AI_PROJECT_ENDPOINT"), model=os.getenv("AZURE_AI_MODEL_DEPLOYMENT_NAME") ) writer_agent = chat_client.as_agent( name="Writer Agent", instructions="You write clear, engaging blog posts on the requested topic.", default_options={"store": False}, ) editor_agent = chat_client.as_agent( name="Editor Agent", instructions="You review drafts for clarity and length, and suggest concise improvements.", default_options={"store": False}, ) manager_agent = chat_client.as_agent( name="Manager Agent", instructions="You coordinate the writer and editor to produce a polished final blog post.", default_options={"store": False}, ) workflow = MagenticBuilder( participants=[writer_agent, editor_agent], manager_agent=manager_agent, max_stall_count=2, max_round_count=10, intermediate_output_from="all").build() stream = workflow.run( "Write a 300-word blog post explaining why sleep matters for productivity.", stream=True, ) last_executor = None async for event in stream: if event.type in ("intermediate", "output") and isinstance(event.data, AgentResponseUpdate): executor = event.data.author_name if executor != last_executor: print(f"\n{'-' * 60}\n{executor}:\n") last_executor = executor print(event.data.text, end="", flush=True) result = await stream.get_final_response() print(f"\n{'=' * 60}\nFinished ({len(result.get_outputs())} output messages).") if __name__ == "__main__": asyncio.run(main())

 

Difference Between Group Chat, Handoff, and Magentic Orchestration

 

Next Steps:

1. Try it yourself - Clone the GitHub Repo to get started!

2. Build upon the Magentic Orchestration use case - "Write a well-researched 800-word article on whether biometric login improves security. Verify claims, add real statistics, and include a counter-argument section." Add participants agents such as researcher_agent, fact_checker_agent, writer_agent, and editor_agent

Related Resources:

1. Reference Used in the Blog (Including images): Introduction - Training | Microsoft Learn
2. More on Magentic Orchestration: Use Magentic Orchestration - Training | Microsoft Learn

Co Author: JiteshThakur​ 

 

AI agents are useful because they can act. They call tools, query databases, send messages, and hand work to other agents. That same freedom creates a problem: access control can tell you which service an agent may reach, but it does not always tell you whether a particular action is sensible, safe, or permitted.  MCP is how most agents now act.

Two Control Points:

This post examines two control points that address different parts of the MCP lifecycle.

• Agent 365 CLI evaluates the MCP server before an agent uses it.
• Agent Governance Toolkit (AGT) governs sensitive tool calls while the agent runs.

One improves what the agent sees. The other governs what the agent does.

The Agent 365 CLI is a cross-platform command-line tool for Agent 365 applications on Azure. Its evaluation command examines MCP tool definitions and scores their quality. AGT evaluates actions against policy and records each decision.

Together, these tools support a practical model: evaluate the server first, then provide proper scaffolding for the developer to test this in a dry run.

Agent 365 CLI: Score an MCP server from the command line:

The Agent 365 CLI can evaluate an MCP server against research-based practices for production readiness. The result is more useful than a simple pass or fail.

The evaluation gives you:

• A score for each tool name, description, and parameter schema;
• A prioritized list of improvements;
• An overall maturity score for the server; and
• Local output that you can use early in development.

This report turns a vague question, "Is this MCP server ready?", into a concrete list of work.

The evaluate command

a365 develop-mcp evaluate --server-url <server-url> [--auth-token <auth-token>] [options]

 

The command reads the tool schemas from the server. It then produces guidance for names, descriptions, parameters, and schema structure.

A local coding-agent CLI scores the semantic checks. You can use GitHub Copilot CLI or Claude Code under your account and AI subscription. The command does not send tool-schema data to Microsoft.

Prerequisites:

Install the following software:

1.  Agent 365 CLI;
2.  Node.js 18 or later for GitHub Copilot CLI; and
3.  A supported coding-agent CLI for semantic scoring.

For example, install GitHub Copilot CLI with this command:

powershell npm install -g @github/copilot

 

This bring-your-own-LLM model keeps the scoring step in your local development environment. It is useful when model calls must remain inside an approved deployment.

How the evaluation works

The command runs a five-step pipeline and logs progress as it goes.

 

Fig 1: MCP Evaluation using Agent 365 Cli                                                                                  

 

1. Connect to the MCP server and collect its tool schemas.
2. Generate an evaluation checklist in the output directory.
3. Score the semantic checks with the selected coding agent.
4. Calculate the maturity level and action priorities.
5. Write the JSON and HTML reports.

The evaluation contains two types of checks:

• Deterministic checks use exact rules in the CLI. For example, a tool name cannot be empty.
• Semantic checks use a coding agent to score clarity and meaning. Each result includes a reason for the score.

Examples

Set the authentication token in an environment variable. Then evaluate an authenticated server and write the artifacts to a subfolder.

powershell $env:A365_MCP_AUTH_TOKEN = "<bearer-token>" a365 develop-mcp evaluate --server-url "https://my-mcp-server.contoso.com/mcp" --output-dir "./eval"

 

Use a specific scoring engine with the `--eval-engine` option:

powershell a365 develop-mcp evaluate --server-url "http://localhost:5000/mcp" --eval-engine claude-code

Scenario: Evaluate a malicious MCP server

For this demonstration, we hosted a deliberately malicious MCP server at `http://127.0.0.1:8124/`. It exposes tools that demonstrate tool poisoning, credential leakage, prompt injection, schema mismatch, sandbox escape, and other attacks.

The server is intentionally unsafe and is for demonstration only.

 

Fig 2: Setting up a test MCP server for evaluation                                                                                           

We ran the evaluation in two steps. First, we generated the checklist without automatic semantic scoring:

 

a365 develop-mcp evaluate --server-url "http://127.0.0.1:8124/" --eval-engine none

 

Fig 3: Agent365CLI MCP Evaluation

 

The command wrote the checklist and a semantic-evaluation prompt to the output directory. It also displayed the next steps.

Second, we gave the prompt and checklist to a coding agent. The agent completed each unscored semantic check with a Boolean score and a short reason. After we saved the completed checklist, we ran the command again to generate the report:

a365 develop-mcp evaluate --server-url "http://127.0.0.1:8124/" --output-dir "C:\temp\MaliciousMCP"

 

Fig 4: Creating the report with Agent365 CLI MCP Evaluate command 

Understanding the evaluation report

Open `<server-name>_eval_report.html` from the output directory. The report contains:

 

• The overall score from 0 to 100;
• The maturity level from 0 to 4;
• Scores for each tool and quality category; and
• A prioritized action list for the next maturity level.

 

Fig 5:  MCP Evaluation Report

 

In our demonstration, the server scored 86.0 and reached Level 3: Optimized for AI. That strong overall score did not mean that every tool was safe or clear. The report found 58 action items, including one critical item and 33 high-priority items.

That contrast matters. A server can have valid schemas and consistent names while still exposing misleading or dangerous tools.

 

Fig 6: MCP Evaluation Report - Tool-By-Tool Detail

What to look for

Read the per-tool results before the overall score. A single weak tool can create more risk than the server average suggests.

Focus on these report sections:

• Tool names: Can an agent select the correct tool from its name?
• Tool descriptions: Does each description explain the purpose and correct use?
• Parameter names: Do the names identify the data that the tool requires?
• Parameter descriptions: Do they explain the format, type, and constraints?
• Schema structure: Are the schemas valid and processable?
• Action items: Which changes have the highest effect on tool selection and use?

The command processes static tool schemas from `tools/list`. It does not process runtime payloads, end-user data, or personal data. The command keeps the `--auth-token` value in memory. It sends the value only in the HTTP `Authorization` header. It does not write the token to disk or give it to the coding agent.

 

AGT: Put governance in the execution path:

Microsoft's open-source Agent Governance Toolkit (AGT) evaluates an action before execution. It adds identity and policy context, records the decision, and can send risky work for approval. This can be used by developers during the build time for dynamic evaluation of the MCP server.

AGT lets developers put part of that intent into the execution path. Remote tools still need secure implementations, sandboxes need hard boundaries, and audit records need appropriate storage and access controls. You do not need to replace your agent framework to use it.

What sits in the decision path?

AGT wraps the tools that an agent already uses. You can start to govern a tool with two lines of Python:

python from agentmesh.governance import govern safe_tool = govern(my_tool, policy="policy.yaml")

 

On each call, `safe_tool` evaluates the configured policy. An allowed action reaches the original tool. A denied action raises `GovernanceDenied` and creates a decision record. This wrapper model reduces the cost of adoption. Teams can add governance to an existing agent stack without rebuilding it.

AGT supports Python, TypeScript, .NET, Rust, and Go. Its documented integrations include popular agent frameworks, MCP, and A2A. Teams can also adopt AGT in stages. A team can begin with policy checks and audit records. It can add identity, approvals, sandboxing, and operational controls as risk increases.

 

Each control answers a different question:

• Policy: Is this action allowed?
• Identity and trust: Which agent made the request?
• Runtime controls: What limits apply to execution?
• Audit evidence: Why did AGT allow or deny the action?

A low-risk assistant can need only a deny rule and basic logging. An agent that moves money or changes production systems needs stronger controls.

 

                                                                                     Fig 7:  AGT Architecture 

 

Scenario: Govern the same malicious MCP server

For this scenario demonstration, we used AGT Python packages as an MCP gateway. The gateway sat between an agent and the same malicious server from the earlier evaluation. This setup let us examine both control points against one target. The Agent 365 CLI examined the server's static tool definitions. The AGT gateway examined real requests and responses for the developer during its testing.

 

                                                                                  Fig 8:  AGT findings at runtime

In the policy interface, a developer can edit runtime limits and detection rules. The developer can also validate the policy against sample tool metadata, save a revision, and activate it with a recorded reason.

 

                                                                                                Fig 9:  AGT control coverage     

The control-coverage view shows which AGT capabilities are active in the gateway. It also links each capability to package checks and end-to-end evidence.

In our demonstration, we included the following controls:

• Tool metadata poisoning detection;
• Tool change and rug-pull detection;
• Dangerous argument blocking;
• Tool-response content scanning;
• Per-client tool-call budgets; and
• A redacted decision audit trail.

You can build your detection & input security by reading more about it here.

The gateway detected malicious content. For one blocked `tools/list` request, it recorded the findings. The important result was not only that AGT blocked the request. It also preserved the matched evidence, affected tool locations, policy modes, and request context.

 

Fig 10: Example detection via AGT

The dashboard then summarized block-mode findings, leading risk drivers, and tools that required review. This evidence can help a team prioritize policy changes and investigate repeated attacks.

 

Fig 11:  Sample AGT metrics

AGT does not require this UI, gateway, or architecture. Its structured decisions can feed an admin console, SIEM, incident workflow, or approval queue.

AGT also includes an Agent Compliance package with mappings for OWASP and other controls. These mappings give developers and governance teams a common record of applied controls. Teams do not need to reconstruct the agent's behavior after an incident. Check Compliance - Agent Governance Toolkit for more information.

Conclusion:

MCP safety needs controls before and during execution. The Agent 365 CLI improves the MCP interface before deployment. It exposes unclear tool definitions, scores server maturity, and turns quality gaps into prioritized work. While AGT is implemented at the build phase, it provides developers the ability to test policy, identity, execution context & preserve evidence for allowed or denied decisions. Neither tool replaces secure server code, strong sandbox boundaries, or protected audit storage. Instead, they make those controls easier to evaluate and explain. Start with one MCP server and one consequential tool call. Evaluate the server with the Agent 365 CLI. Then put an AGT policy around the action that carries the most risk.

While these controls help secure the build phase of an agent, once agents move into production, runtime controls become essential. Agent365 provides those controls at runtime.

 

 

 

Recent public disclosures have reinforced why building foundational security matters. Security researchers and leading AI labs have highlighted scenarios where autonomous AI systems were able to exploit common security weaknesses, move across trust boundaries, and perform actions at a speed and scale difficult for humans to match. These incidents demonstrated that many of the risks associated with advanced AI systems are not entirely new. Instead, they often stem from familiar security gaps such as excessive privileges, weak internet-facing controls, vulnerable software components, and insufficient monitoring.

To help organizations prepare for this new reality, Microsoft is introducing additional guidance focused on containment strategies for AI agents. These recommendations build on the same foundational security principles that underpin AI readiness, while providing additional guidance to help organizations contain agent actions, harden attack surfaces, reduce blast radius, govern identities and permissions, and improve visibility into agent activity across their environment. The goal is simple: help organizations safely adopt increasingly autonomous systems while maintaining control, oversight, and resilience.

Secure Now brings guidance and recommended actions together across six areas relevant to AI readiness:

• Containment strategies for AI agents ensuring they are acting within the bounds intended.
• Stay current on Microsoft software by deploying security updates promptly across the enterprise and infrastructure.
• Adopt updates for open-source software by finding and updating vulnerable libraries and dependencies.
• Scan and secure source code by identifying vulnerabilities and configuration weaknesses in custom applications.
• Minimize internet-facing exposure by inventorying and reducing unnecessary internet-facing assets, then protecting what remains.
• Implement baseline security measures such as MFA, least-privilege access, and disabling legacy authentication.

The new containment strategies guidance translates recent incident lessons into practical steps. It helps teams restrict agent and model egress, enforce tool and action boundaries, establish emergency shutdown paths, govern agent identities and permissions, improve agent-specific observability, and continuously monitor agent activity.

Build the foundation now

AI transformation will reward organizations that can move quickly and securely. The fastest path is not to treat security as a blocker or an afterthought. It is to establish a strong foundation early, reduce exposure proactively, and make readiness a continuous discipline.

Secure Now helps customers take that first step. It brings together the guidance, prioritization, and action needed to strengthen foundational security across the areas that matter most for AI readiness.

Get started today! Customers can review Secure Now under Exposure Management or at aka.ms/Securenow.