Microsoft Agent Framework 1.0: Architecture Guide

Agentic AI spent most of 2025 in the demo phase. Impressive notebooks, compelling conference keynotes, and very few systems that a CISO would sign off on for production. With Microsoft Agent Framework 1.0 reaching General Availability on 3 April 2026, that conversation has changed. The framework is open source, supported, and built for .NET and Python — and it consolidates the scattered lineage of Semantic Kernel and AutoGen into a single codebase that an enterprise can actually standardise on.

This is an architecture guide for the people who have to make that decision: CTOs, CISOs, and enterprise architects who need to understand how the pieces fit, where the risks live, and what it takes to run agents in production rather than in a sandbox.

TL;DR / Key takeaways

Microsoft Agent Framework 1.0 (GA 3 Apr 2026) is the production-ready, open-source successor to Semantic Kernel and AutoGen, for .NET and Python, with A2A and MCP built in.
Azure AI Foundry is the control plane: model hosting, identity, tracing, evaluation, content safety, and cost governance for enterprise AI agents.
The defining 2026 shift is pilots-to-production — reliability, observability, security, evaluation, and cost control, not raw model capability.
Treat MCP as how an agent gets its capabilities and A2A as how agents collaborate; design both deliberately.
For European enterprises, map agent autonomy to EU AI Act, NIS2, and DORA obligations from day one — governance is an architecture concern, not a paperwork afterthought.

Why 1.0 matters for the enterprise

The number that frames the moment: over 160,000 organizations have already deployed 400,000+ custom agents on Copilot Studio. Adoption is not the question anymore. Durability is. The honest blocker for most enterprises was never "can we build an agent" — it was "can we trust this agent in front of a customer, a regulator, or a production database."

Microsoft Agent Framework 1.0 addresses that on three fronts. First, it is one supported framework instead of competing experimental libraries, which matters enormously when you are committing a platform team and a five-year roadmap. Second, it standardises agent interoperability through A2A and MCP rather than leaving every team to invent its own glue. Third, it is designed to be observable and governable through Azure AI Foundry, which is where the production story actually lives.

The architecture, layer by layer

It helps to separate the framework from the platform. The framework is the SDK you write code with. Azure AI Foundry is the platform you deploy onto, govern, and observe through. Conflating the two is the most common architectural mistake we see in early adopters.

Loading diagram...

Layer	Responsibility	Provided by
Orchestration	Agent definitions, workflows, planning, tool calls	Microsoft Agent Framework (.NET / Python)
Capabilities	Connecting agents to tools, data, and context	MCP servers
Collaboration	Agent discovery and delegation across boundaries	A2A protocol
Runtime & models	Model hosting, scaling, identity	Azure AI Foundry
Governance	Tracing, evaluation, content safety, cost controls	Azure AI Foundry

Orchestration: the framework itself

This is where you define agents, their instructions, the tools they may call, and how a workflow routes between them. The framework handles the unglamorous-but-essential mechanics: function calling, structured outputs, conversation state, and multi-step planning. Because it targets both .NET and Python natively, you are not forced into a polyglot architecture to satisfy a data-science team and a platform team at once — a genuine advantage in mixed enterprise estates.

Capabilities: Model Context Protocol

MCP is how an agent reaches the outside world — a database, a ticketing system, an internal API, a document store. A well-designed MCP server is a security boundary as much as an integration: it decides exactly what an agent can read and do. Get this wrong and you have handed a probabilistic system unscoped access to production. We cover this in depth in our guide to enterprise MCP server design, but the headline rule is: scope every tool to least privilege and treat the MCP server as part of your attack surface.

Collaboration: the A2A protocol

A2A is the protocol that lets one agent discover and delegate to another — across processes, teams, and even organisations. A planner agent delegates research to a specialist; a procurement agent negotiates with a supplier's agent. The interesting architectural decisions are about trust, identity, and contract: how does Agent A know Agent B is who it claims, and what is the bounded interface between them? We unpack the recurring designs in our piece on A2A protocol patterns.

Pilots to production: the part nobody demos

This is the heart of the 2026 story, and where most of the engineering effort actually goes. A demo agent calls a model and prints a result. A production agent has to be reliable, observable, secure, evaluable, and affordable. Here is the checklist we work through with clients:

Observability and tracing. Every agent call, tool invocation, and delegation must produce a distributed trace. When an agent gives a wrong answer in production you need to see the full reasoning and tool chain, not guess. Foundry's tracing plus OpenTelemetry is the baseline — see our deep dive on AI agent observability and tracing.
Evaluation. Agents regress silently when a model version or prompt changes. You need automated evaluation suites — groundedness, task success, safety — running in CI, not vibes-based testing before each release.
Security and identity. Every tool call should carry a scoped identity. Use managed identities, never long-lived secrets, and apply least privilege at the MCP layer. An agent with broad credentials is a confused-deputy waiting to happen.
Cost governance. Token spend is a production cost line, and agentic loops can amplify it dramatically. Set per-agent budgets, cap reasoning loops, cache aggressively, and route to cheaper models where quality allows.
Reliability engineering. Retries with backoff, timeouts, idempotency keys, and human-in-the-loop gates for high-impact actions. Treat the agent like any other distributed system component, because it is one.

In a recent engagement we took a customer's promising support-triage prototype — which worked beautifully in a notebook — and the production hardening was roughly 80% of the total effort. The model was never the bottleneck. Tracing, evaluation gates, identity scoping, and a hard cap on autonomous tool calls were.

Governance for European enterprises

For our clients, the framework conversation is inseparable from the regulatory one. An autonomous agent that takes consequential decisions is not a neutral technical artefact — it sits squarely inside the EU AI Act, and depending on the sector, NIS2 and DORA as well.

EU AI Act. If your agent influences decisions about people — credit, hiring, access to services — you are likely in high-risk territory, which brings obligations around risk management measures, technical documentation, human oversight, and conformity assessment evidence. Design the agent so those decisions are logged and explainable from the start.
NIS2. Agents that can act on critical systems expand your attack surface and fall under your risk management and incident reporting obligations. Management bodies carry accountability here.
DORA. For financial entities, an agent calling third-party MCP servers is part of your ICT third-party risk and supply chain — it needs to be inventoried and contractually governed.

The practical advice: build the audit trail and the human-oversight gates as architecture, not as a compliance bolt-on. Retrofitting governance onto an autonomous system is far harder than designing it in.

A pragmatic adoption path

You do not need a moonshot. The sequence we recommend:

Pick one bounded, internal use case with a clear success metric and low blast radius — internal knowledge retrieval, ticket triage, document drafting.
Build it on the framework, locally first, with proper tracing wired in from commit one.
Scope every tool through MCP with least privilege, and add evaluation suites before you let anyone else touch it.
Promote to Azure AI Foundry for production, with cost budgets and content safety enabled.
Only then introduce A2A to let your proven agent collaborate with others. Multi-agent complexity is a reward for getting single-agent reliability right, not a starting point.

The verdict

Microsoft Agent Framework 1.0 is the first time the agent story on Azure feels like an engineering platform rather than a research preview. The framework gives you a supported, open-source foundation; Azure AI Foundry gives you the governance and observability to run it safely; A2A and MCP give you interoperability that does not lock every team into bespoke plumbing. The remaining work — reliability, evaluation, security, cost, compliance — is real engineering, and it is exactly the work that turns an impressive pilot into a system a regulated European enterprise can depend on.

If you are weighing how to bring agents into production responsibly, our team has delivered exactly this kind of hardening and governance work. Have a look at our AI and data platform engineering services — we are happy to compare notes.

FAQ

What is Microsoft Agent Framework 1.0?

Microsoft Agent Framework 1.0 is a production-ready, open-source framework for building AI agents in .NET and Python. It reached General Availability on 3 April 2026 and consolidates the lessons of Semantic Kernel and AutoGen into one supported codebase. It ships with the Agent-to-Agent (A2A) protocol and Model Context Protocol (MCP) integration, and pairs with Azure AI Foundry for deployment, governance, and observability.

How does Microsoft Agent Framework relate to Azure AI Foundry?

The framework is the SDK you write agents with; Azure AI Foundry is the platform you deploy, govern, and observe them on. Foundry provides model hosting, identity integration, tracing, evaluation, and cost controls. You can run framework agents locally during development and promote the same code to Foundry for production without rewriting the orchestration logic.

What is the difference between A2A and MCP?

MCP (Model Context Protocol) standardises how an agent connects to tools, data sources, and context — it is the integration layer between an agent and the systems it acts on. A2A (Agent-to-Agent) standardises how agents discover and delegate to each other across process and organisational boundaries. In practice MCP gives an agent its capabilities and A2A lets multiple specialised agents collaborate.

Is Microsoft Agent Framework production-ready for regulated European enterprises?

The 1.0 GA release is explicitly positioned for production, and Azure AI Foundry provides the controls regulated organisations need: audit logging, evaluation, content safety, and EU data residency options. You still own the compliance work — mapping agent decisions to EU AI Act obligations, documenting risk management measures, and keeping conformity assessment evidence. The framework makes that achievable rather than automatic.

Should we migrate existing Semantic Kernel or AutoGen agents?

Microsoft Agent Framework is the consolidated successor to both, so new work should start here. For existing systems, migrate when you need the unified A2A and MCP support, the supported GA codebase, or tighter Foundry integration. Stable, low-change agents can stay where they are; we typically migrate opportunistically rather than in a big-bang rewrite.

What does it actually take to move agent pilots to production?

The 2026 shift is from demos to dependable systems. That means observability and distributed tracing across agent calls, evaluation pipelines that catch regressions, security and least-privilege identity for every tool call, and cost governance so token spend is predictable. Reliability engineering — retries, timeouts, idempotency, human-in-the-loop gates — is what separates a pilot from a production agent.