Interview with a Core Developer of Microsoft's Agent Framework: A Complete Analysis of Architecture Design and Evolution

Introduction

The release of Microsoft's Agent Framework 1.0 has attracted widespread attention from the developer community. Based on an in-depth interview with Roger Barreto, a core member of Microsoft's Agent Framework team, this article reveals the evolution from Semantic Kernel to Agent Framework, the architectural design philosophy, and how the team balances enterprise-grade stability with cutting-edge innovation.

Evolution from Semantic Kernel to Agent Framework

The Pioneering Era: Starting from Scratch

Roger joined Microsoft in 2021, initially working on workflow automation. From late 2022 to early 2023, he was invited to join a secret internal project—Semantic Kernel. At that time, generative AI was just getting started, and there were virtually no AI development tools in the .NET ecosystem.

Semantic Kernel is a lightweight SDK open-sourced by Microsoft in early 2023, designed to integrate large language model (LLM) capabilities into traditional applications. Its core concept treats AI capabilities as orchestrable "Skills" and "Plugins," combining Semantic Functions and Native Functions to allow developers to invoke AI capabilities within familiar programming paradigms. Unlike LangChain, which primarily targets the Python ecosystem, Semantic Kernel supported both .NET and Python from the beginning—a significant advantage for enterprise customers heavily invested in C#.

"At the time, there was only LangChain, and we wanted to provide a more convenient enterprise-grade solution for Python and .NET developers," Roger recalled. The team's core goal was to build a production-grade framework with version control, no breaking changes, and long-term maintainability—which later became Agent Framework's strongest moat.

Early exploration was filled with interesting experiments. Before Function Calling existed, the team used a "Planning" approach, providing examples to force the model to follow specific structures. The model could sometimes reply in XML or JSON format, and sometimes it would completely fail. While unreliable, this approach was the precursor to Function Calling.

Function Calling is a key capability introduced by OpenAI in June 2023, allowing developers to define function signatures in API requests so the model can determine when to call these functions and generate structured parameters. Before this, developers could only guide models to output text in specific formats through carefully designed Prompt Engineering, then extract information using regular expressions or parsers. This approach was extremely unstable, with models frequently producing malformed output. The introduction of Function Calling fundamentally changed the development paradigm for AI applications, enabling AI agents to reliably interact with external systems to execute database queries, API calls, file operations, and other tasks.

Multi-Team Convergence: The Birth of a Unified Solution

The Agent Framework was born from the convergence of experiences across multiple teams—the Semantic Kernel team, the Microsoft Extensions AI team, and lessons from AutoGen. The teams jointly explored how to define a unified solution based on their respective experiences, rather than maintaining multiple scattered projects.

AutoGen is a multi-agent conversation framework released by Microsoft Research in 2023, which pioneered the paradigm of having multiple AI agents collaborate through conversation to complete complex tasks. AutoGen's core concepts include customizable agent roles, flexible conversation patterns (such as group chat, sequential conversation), and human-in-the-loop collaboration. While AutoGen was widely popular in research and prototyping, its design was more experimental in nature, lacking enterprise-grade version management and backward compatibility guarantees. Agent Framework absorbed AutoGen's lessons learned in multi-agent orchestration while redesigning the API surface and stability guarantees to production-grade standards.

Microsoft Extensions AI played a critical underlying role. It solved a core problem: different AI providers (Anthropic, Google Gemini, etc.) have different libraries, and developers don't want to implement a client for each one. Extensions AI provides a unified abstraction layer (such as IChatClient), allowing developers to focus on a single interface.

Microsoft Extensions AI (abbreviated as M.E.AI) is a set of NuGet packages introduced by Microsoft in 2024, part of the .NET core libraries. It defines standard interfaces like IChatClient and IEmbeddingGenerator, similar to how ILogger abstracts logging frameworks in .NET. This means any AI provider (OpenAI, Anthropic, Google, local models, etc.) only needs to implement these interfaces, and developers' application code can switch backends without modification. This design borrows from the mature dependency injection and interface abstraction patterns in the .NET ecosystem, reducing vendor lock-in risk and enabling enterprises to flexibly choose AI services based on cost, performance, and compliance requirements.

"Nobody can refuse .NET, but it's easy to refuse an unfamiliar Semantic Kernel," Roger explained the elegance of this layering strategy.

Middleware Architecture: The Core Design Philosophy of Agent Framework

Flexible Pipeline Composition Pattern

Roger was primarily responsible for designing the middleware architecture in Agent Framework. This architecture draws from ASP.NET's middleware pattern, allowing developers to flexibly intercept and modify messages before and after agent invocations.

ASP.NET Core's middleware pipeline is a classic request-processing architecture where each HTTP request passes through a series of middleware components sequentially. Each component can execute logic before the request reaches the terminal handler or before the response returns to the client. This "Onion Model" allows developers to add Cross-cutting Concerns in a loosely coupled manner, such as authentication, logging, exception handling, CORS, etc. Agent Framework brings this mature pattern into the AI agent domain, enabling enterprise-grade requirements like security auditing, content filtering, and performance monitoring to be inserted as independent middleware components without modifying the agent's core logic.

Specifically, developers can:

• Start from an agent instance and convert it into a builder
• Add multiple middleware components through the builder to form a pipeline sequence
• Adjust messages before they enter the agent, after they return from the LLM, and before they reach the user

Use cases include PII detection, guardrails, logging, telemetry, and more.

PII (Personally Identifiable Information) detection is a critical compliance requirement when enterprises deploy AI systems. Under data protection regulations like GDPR and CCPA, enterprises must ensure that sensitive information (such as names, ID numbers, medical records, etc.) is not improperly transmitted to third-party AI services or appears in logs. Guardrails are broader safety mechanisms, including content safety filtering (preventing harmful content generation), topic restrictions (preventing models from deviating from business scope), output format validation, etc. Implementing these features as middleware means they can be centrally managed, independently updated, and reused across different agents.

This design is not limited to the agent level—middleware can also be composed at the chat client level.

Five Middleware Extension Types Explained

The framework provides five different extension types to meet various development scenario requirements:

1. Agent Middleware: Receives the original agent and returns a modified new agent (highest level)
2. Runtime Middleware: Modifies or inspects messages when invoking the agent
3. Dependency Injection Middleware: Provides DI services to the agent
4. Function Calling Middleware: Specifically intercepts function calls
5. AI Context Provider: Provides convenient features like conversation information and agent information

The AI Context Provider is one of Roger's favorite features—it supports dynamic tool invocation, allowing agents to determine whether a particular message needs a specific tool and add it in real-time, thereby saving significant token overhead.

In traditional AI agent implementations, all available tool definitions are sent to the model as part of the system message with every API call. When there are many tools, these definitions can consume thousands of tokens, not only increasing API call costs (billed per token) but also potentially crowding out limited context window space. Dynamic tool invocation achieves on-demand loading through the AI Context Provider—tool definitions are only injected into the context when the model actually needs them. This "lazy loading" strategy is particularly important in enterprise scenarios with dozens or even hundreds of tools, significantly reducing operational costs and improving response speed.

The Cost and Reward of Enterprise-Grade Stability

The "Break the Glass" Design Philosophy

The team was extremely careful in designing abstraction layers. A good abstraction should provide convenience without constraining developers. When developers need to access something beneath the abstraction layer, the framework allows "Break the Glass"—direct access to the underlying implementation.

"Typically what happens is that when you break the norm, an abstraction layer soon appears to cover it," Roger said. Once there are enough cases and vendors accepting a certain pattern, it gets promoted to an official abstraction.

Strict Quality Gates for Version 1.0

Approaching version 1.0, the team bore enormous responsibility. Every edge case needed verification, and every feature needed stability assurance. Once an API was finalized, forward compatibility had to be guaranteed—this is crucial for large enterprises.

Forward Compatibility in enterprise software means that code written using the current version's API will continue to work correctly after upgrading to future versions, without breaking due to API signature changes, behavioral modifications, or feature removals. This is typically managed through Semantic Versioning: major version changes allow breaking changes, minor versions only add features, and patch versions only fix bugs. For large enterprises, a single breaking change could mean hundreds of microservices need synchronized updates, weeks of regression testing, and potential production incident risks. This is why the 1.0 release was such a deliberate milestone.

Roger maintains over 80 Agent Framework examples. While the maintenance work before the release candidate was tedious, "doing it now is better than patching breaking changes everywhere afterward—otherwise you'd completely lose the trust of large enterprises."

Global Team Collaboration Model

The Agent Framework team is distributed across the Netherlands, Ireland, the United States, Korea, and other locations, achieving around-the-clock coverage. Team members each have their own areas of expertise (SMEs) and need to communicate daily to ensure feature parity between the .NET and Python versions while following the idiomatic conventions of each language.

The project is fully open source, allowing community members to contribute code, propose ideas, and participate in discussions. The core team reviews all submissions to ensure they meet production-grade standards.

AI Tools in Daily Development Practice

Multi-Agent Parallel Workflows

Roger shared his daily workflow: he typically runs three or four AI agents simultaneously, handling different repositories and tasks. He believes the current bottleneck is more in code review than code generation.

His recommended best practice is: assign specific responsibilities to each agent (test development, quality assurance, pipeline checks, etc.), let them collaborate with each other, forming a group of agents each handling their own duties, rather than relying on a single agent to do everything.

Copilot Booster: Solving Multi-Repository Workflow Pain Points

Roger also open-sourced a lightweight tool called "Copilot Booster" that solves the context confusion problem when working across multiple repositories and terminals. It can:

• Manage multiple Copilot sessions, associating them with specific GitHub Issues and PRs
• Quickly switch between different repositories and branches
• Configure dedicated browsers, IDEs, and terminals for each session
• Save and restore session states

Looking Ahead: What's Next for Agent Framework

Agent Framework 1.0 is just the beginning. Skills as an abstraction layer are coming soon, along with many new features in the pipeline. Roger is optimistic about the future: "In a few months or a year, token generation speed might reach thousands per second, and by then agents will be so fast that everything will be ready the instant you click a button."

For developers looking to get started, Roger emphasizes that the framework is designed to be very simple—three to six lines of code can run an agent. The team holds weekly Office Hours and welcomes developers to join, ask questions, and exchange ideas.

Key Takeaways

• Agent Framework 1.0 was born from the convergence of experiences from three teams: Semantic Kernel, Microsoft Extensions AI, and AutoGen, aiming to provide a unified enterprise-grade agent development solution
• The middleware architecture is the framework's core design, drawing from ASP.NET patterns to provide five extension types supporting scenarios like PII detection, guardrails, and dynamic tool invocation
• The team adopts a "Break the Glass" design philosophy, providing abstraction convenience while not constraining developers from accessing underlying implementations
• The framework strictly adheres to enterprise-grade standards, guaranteeing forward compatibility after the 1.0 release and avoiding breaking changes to maintain large enterprise trust
• A globally distributed team ensures feature parity across both .NET and Python, with the project being fully open source and offering weekly Office Hours to support the community