Microsoft Revolutionizes Agentic AI with New Agent Framework

An Innovative Framework for Agentic AI

The Agent Framework Dev project represents a dynamic community initiative aimed at providing practical training materials for developers interested in creating AI agents. This project leverages modern frameworks and tools to offer in-depth and accessible training. In October 2025, the Microsoft Agent Framework was launched, extending the capabilities of Semantic Kernel and AutoGen in a unified approach for developing production-grade agentic systems. This launch was marked by the organization of Agent Framework Dev Day, an event orchestrated by the Boston Azure AI group and supported by Microsoft.

The framework integrates with the Microsoft Foundry platform, offering observability features, security configuration, and enterprise-grade operational controls. By working with the Python content of the framework, developers can explore four interconnected technical areas, each building on the previous one and grounded in models applicable to real deployed systems.

Considering Security as an Empirical Measurement Problem

In the development of AI agents, security is often treated as a secondary aspect. However, Microsoft proposes to place it at the center of the development process. Even before starting to code, developers are encouraged to assess the security of models using a dual model comparison executor. This tool sends the same request to two instances of gpt-4.1-mini: one with Microsoft Foundry's security guardrails activated, and the other with these protections reduced.

To illustrate this comparison, a request for instructions on how to make a homemade explosive is used. The protected model categorically refuses to respond, while the unprotected model might not. This demonstration highlights the behavioral differences between the two deployments, making the issue of security tangible rather than theoretical.

Developers can explore three categories of inputs: profanity filtering via block lists, government identifiers such as social security numbers, and other personally identifiable information. Each category represents a corporate compliance concern, and the differences observed between the protected and unprotected models help identify where guardrails are effective and where improvements are needed.

Latency is also a factor to consider, as security guardrails add measurable overhead. A third model, with intermediate security settings, shows that security is a configurable spectrum that engineers can adjust according to the application context.

The code uses the AzureAIClient to create ephemeral agents, executing both models via asyncio.gather and displaying token counts along with timing data. The architecture is deliberately minimalist, with the goal of comparing models rather than focusing on infrastructure.

Connecting Agents to the World with the Model Context Protocol

The Model Context Protocol (MCP) is a universal adapter that allows AI agents to connect to data sources and tools via a standardized protocol. This is done without requiring modifications to the agent client when the underlying service changes, making it a practical foundation for building agents that interact with evolving enterprise systems.

The MCP architecture relies on three main components: a host application (the AI agent), an MCP client, and one or more MCP servers. These servers can be local or remote, and the client code remains unchanged, keeping the agent layer decoupled from infrastructure decisions.

Two transport mechanisms are used to cover the main deployment scenarios:

• STDIO Transport: This transport runs the MCP server as a subprocess, communicating via standard input and output. It is ideal for local tools and CLI integrations requiring low latency.

• HTTP/SSE Transport: This transport runs the server as a web service, communicating via HTTP with events sent from the server (SSE). It is suitable for cloud services and shared tools requiring simultaneous accessibility by multiple agents.

A concrete implementation in the support ticket domain makes these concepts tangible. The mcp_local_server exposes tools via STDIO, while the mcp_remote_server operates as a REST API managing the same ticket data. The mcp_bridge translates between HTTP/SSE and regular HTTP calls, and the mcp_agent_client consumes these tools, dynamically discovering the tools from each server.

The architecture allows wrapping an existing REST API with an MCP bridge without modifying the backend, thus reducing the integration cost for companies with extensive API surfaces.

Orchestrating Workflow Models: Sequential, Concurrent, and Human-in-the-Loop

Workflow orchestration is where individual agents begin to function as coordinated systems capable of handling problems too complex for a single model call to resolve cleanly on its own.

The three models operate on the same SupportTicket data model, carrying fields such as ticket ID, customer name, subject, description, and priority. Using the same domain across the three models is intentional: the goal is to observe identical data moving through fundamentally different processing architectures and to see what changes in output, latency, and the control surface available to the operator.

• Sequential Workflow: A high-priority ticket from a customer unable to connect after a password reset goes through an AI categorization step, which classifies and summarizes the issue in structured JSON, then enters a response generation step. The output is a complete response, ready for the customer, acknowledging the urgency, offering concrete steps to follow, and including the ticket number. The entire pipeline operates without human intervention, and the output of each step is visible before moving to the next, making the data transformation at each step explicit and inspectable.

• Concurrent Workflow: A customer reporting both a double charge and an application crashing in the same message exposes the limitations of a sequential single-agent pipeline. Billing and technical concerns require different expertise, and routing both through a single agent produces a less efficient outcome than routing each to a specialist capable of reasoning deeply in a narrower domain.

  The concurrent model expands the question to a billing expert agent and a technical expert agent simultaneously. The billing agent handles the double charge and recommends a refund path. The technical agent focuses on cache-clearing and reinstallation steps for the crashing application. Neither agent attempts to manage both domains. The aggregated result gives the customer a complete response that no single specialist could have produced alone, and the response time is limited by the slower of the two agents rather than their sum.

• Human-in-the-Loop Workflow: The most critical case involves a customer requesting a full refund for a premium annual subscription purchased a week prior. The AI generates a draft response correctly invoking the 14-day money-back guarantee policy and offering to process the cancellation immediately. Execution then halts, and control explicitly passes to a human reviewer before anything is sent.

  The supervisor receives the complete draft and three explicit choices: approve and send as is, modify before sending, or escalate to management. In the case of approval, the system records the action, updates the ticket status to resolved, and logs that the response was approved without modification, creating a complete audit trail of the decision.

What this model makes concrete is something that workflow diagrams tend to obscure: the human pause in the loop is not a mode of failure or an exception path. It is a designed, first-class stop in the workflow. The system expects this without questioning or delay. It is the model that makes AI-assisted processes auditable and defensible in regulated or high-stakes environments, and it deserves to be treated as a peer to fully automated alternatives rather than a last resort.

Extending each model significantly deepens understanding. Adding a sentiment analysis agent before categorization in the sequential pipeline, adding a security or accounts specialist to the concurrent fan-out, adding new supervisor actions like "Request more information" at the human-in-the-loop step, and composing sequential and concurrent models into a single hybrid workflow require understanding how executor classes, the shared client factory, and data models connect throughout the entire system.

Moving from RAG to Agentic RAG

Standard applications of retrieval-augmented generation (RAG) are easy to start but encounter types of questions that require a more sophisticated approach to be resolved effectively. Microsoft's framework offers an agentic approach to overcome these challenges, integrating agents capable of handling complex queries efficiently and securely. By combining retrieval and generation capabilities, agents can provide more accurate and contextualized responses, thus meeting the growing needs of modern enterprises.