For the past two years, building agentic applications in .NET meant choosing between Semantic Kernel and AutoGen and accepting the gaps in whichever you picked. Semantic Kernel had great RAG and memory primitives but mediocre multi-agent orchestration. AutoGen had strong orchestration patterns but the .NET support felt like a port of the Python SDK rather than something designed for C# developers.

Microsoft Agent Framework 1.0 — which went GA in April and got a major feature expansion at Build 2026 — is the end of that fragmentation. It’s a unified SDK that merges both, and the architectural decisions made in it tell you something about how Microsoft is thinking about the future of agentic development.

The most interesting decision is CodeAct.

What CodeAct Actually Does

Traditional agentic tool calling works like this: the model sees a tool list, decides which tool to call, the framework invokes it, returns the result to the model, repeat. Each tool call is a separate LLM turn. A task that requires 10 tool calls produces 10 LLM turns.

CodeAct flips this. Instead of choosing individual tools, the model writes a short Python program that orchestrates the tools:

# CodeAct-generated program for "summarize the last 10 PRs and email the report"
prs = github.list_prs(repo="myorg/myapp", limit=10, state="merged")
summary = "\n".join([f"#{pr.number}: {pr.title} by {pr.author}" for pr in prs])
report = f"Sprint PR Summary\n\n{summary}"
email.send(to="team@myorg.com", subject="Weekly PR Digest", body=report)

This program executes in a sandboxed Hyperlight micro-VM — Microsoft’s WebAssembly-based isolation runtime. The entire multi-step task completes in one LLM generation turn, because the model is writing executable logic rather than making sequential decisions.

The measured results from Build 2026: 63.9% fewer tokens consumed, 52.4% faster execution time on representative multi-step workloads.

These numbers make intuitive sense once you understand the architecture. When you’re not repeatedly serializing tool results back into prompt context and waiting for the next model decision, the overhead drops dramatically.

The Hyperlight Sandbox Matters

The security story here is worth unpaying attention to. CodeAct generates arbitrary Python — which is powerful and terrifying in equal measure. Running that in a production backend without isolation would be completely unacceptable for any serious enterprise deployment.

Hyperlight is the answer. It’s a WebAssembly micro-VM that provides per-session isolation: each CodeAct execution gets its own sandboxed environment with no access to the host filesystem, network, or other sessions. The overhead is milliseconds, not seconds (unlike full container spin-up).

For .NET teams working in regulated industries — financial services, healthcare, anything with compliance requirements — this is the architectural detail that makes CodeAct enterprise-deployable rather than just an interesting demo. The sandbox + OpenTelemetry tracing built into MAF means you get both isolation and auditability.

The .NET API

The MAF .NET SDK (AsHarnessAgent()) and Python SDK (create_harness_agent()) are at full parity. Here’s what setting up a CodeAct-enabled agent looks like in C#:

using Microsoft.AgentFramework;
using Microsoft.AgentFramework.CodeAct;

var agent = AgentBuilder.Create()
    .WithModel("claude-fable-5")
    .WithCodeActExecutor(options =>
    {
        options.AllowedModules = ["github", "email", "jira"];
        options.MaxExecutionTime = TimeSpan.FromSeconds(30);
    })
    .WithMemory(new FileMemoryProvider("./agent-memory"))
    .WithTracing(builder => builder.AddOpenTelemetry())
    .AsHarnessAgent();

var result = await agent.RunAsync(
    "Summarize the last 10 merged PRs and create a Jira ticket for any that don't have a linked issue"
);

The AllowedModules list is your security surface area — you explicitly declare which tools the generated Python can access. This is the right API design for enterprise: allowlist rather than denylist.

Foundry Hosted Agents

The other significant Build announcement was Foundry Hosted Agents: a way to deploy MAF agents to production that includes scale-to-zero, per-session VM isolation, persistent filesystem state, and automatic Application Insights integration.

The deployment model is compelling for a specific reason: it handles the state problem that makes agentic systems hard in serverless environments. A stateless function that runs for 30 seconds then exits can’t maintain the kind of contextual state that multi-turn agentic work requires. Foundry Hosted Agents gives you a persistent session filesystem that survives across the individual execution windows.

For teams already on Azure, this removes the biggest operational objection to deploying agentic workloads: you don’t have to build your own session state management.

What This Means for .NET Teams

Before MAF, a typical .NET team building agentic features had to make several unpleasant choices:

  • Use Semantic Kernel for its .NET-native feel but work around its weak multi-agent support
  • Use AutoGen for orchestration quality but accept the second-class .NET experience
  • Build custom orchestration and give up framework support entirely

MAF 1.0 eliminates those trade-offs for most use cases. The convergence point is real and production-tested — the Semantic Kernel community has been migrating to MAF primitives since the GA release.

The practical migration path for existing Semantic Kernel projects: MAF 1.0 exposes SK’s IKernelPlugin interface, so your existing plugins work without changes. The AsHarnessAgent() wrapper adds the new capabilities (CodeAct, Foundry hosting, OpenTelemetry) to agents that would have been KernelAgent instances in the SK world.

The Trade-Off to Watch

CodeAct is not the right pattern for every tool call sequence. When you need tight control over the order of operations, or when individual tool calls need human-in-the-loop approval between them, the traditional sequential tool call pattern is still appropriate.

The sweet spot for CodeAct is bulk, well-defined tasks where the full set of operations can be expressed as a program: “process these 50 tickets,” “migrate these records,” “generate and send this report.” For interactive, exploratory tasks where the next step depends on human judgment, you probably still want the traditional pattern.

MAF gives you both. The architecture decision is about knowing which to reach for.

The A2A and MCP Integration

MAF 1.0 ships with built-in A2A (Agent-to-Agent) protocol support and MCP (Model Context Protocol) client support. The Build demos showed LangGraph agents, .NET MAF agents, and GitHub Copilot SDK agents collaborating on the same workflow via A2A.

This interoperability matters more than it might seem. In practice, enterprise agentic systems will be heterogeneous — some components will be best served by LangGraph’s Python ecosystem, others by .NET, others by specialized proprietary agents. A2A is the protocol that makes them composable without vendor lock-in to a single orchestration framework.

The ecosystem is moving faster than the frameworks can document. If you’re building .NET agentic systems today, MAF 1.0 is the right foundation — not because it’s perfect, but because it’s the convergence point where Microsoft is concentrating its investment.

Export for reading

Comments