Building AI agents in C# and .NET: the 2026 stack

We build AI agents in C# and .NET that run in production - reading, deciding, and acting inside your systems, with tests and a full audit trail. We build on .NET and Orleans for the reliability an agent needs when it's taking real actions at real volume, not just in a demo.

Building AI agents in C# and .NET in 2026 runs on a stack that finally consolidated, and knowing the layers saves teams from betting on a deprecated one. At the base, Microsoft.Extensions.AI provides the provider abstraction, the IChatClient interface that every model provider (Azure OpenAI, OpenAI, Ollama, Anthropic, and others) implements, so you write against one interface and swap providers freely. On top of it, Microsoft Agent Framework is the agent and orchestration layer, and it reached 1.0 general availability on April 3, 2026, unifying the previous two options, Semantic Kernel and AutoGen, into a single production-ready SDK built by the same teams. Semantic Kernel is now in maintenance mode and AutoGen is maintenance-only, so new agent work should start on Agent Framework. The upshot: .NET is no longer a second-class citizen for agents, it has a supported, first-class stack, and this explains what it is and how the pieces fit.

This is the work behind our custom AI agents for clients. We build production AI agents in .NET, on Orleans and the Microsoft agent stack, so this is a practitioner's map of the 2026 C#/.NET agent landscape and where the real decisions are.

AI agents in C#

The current .NET AI stack is a clean progression, and each layer has a distinct job:

• Microsoft.Extensions.AI (the root). The foundational abstraction layer. It defines IChatClient and related interfaces that unify how you talk to any model provider, plus middleware for things like telemetry, caching, and tool invocation. Write your code against this, and the provider underneath (Azure OpenAI, OpenAI, Ollama, a local model) becomes a swappable detail. This is the layer everything else builds on.
• Microsoft Agent Framework (agents and orchestration). The layer that turns model calls into agents: agent abstractions, tool/function calling, memory, and multi-agent orchestration (sequential, concurrent, handoff, and group patterns). It reached 1.0 GA in April 2026 with stable APIs and long-term support, and it is where all of Microsoft's new agentic investment goes, MCP integration, A2A support, checkpointing, human-in-the-loop, and observability.
• The provider layer. Azure OpenAI, OpenAI, Anthropic, or local runtimes (Ollama, Foundry Local, ONNX), reached through the abstraction so the choice is not hard-wired into your logic.

The mental model: Microsoft.Extensions.AI is how .NET talks to models, Agent Framework is how .NET builds agents on top of that, and the provider is a plug at the bottom. Get the layers right and the stack is coherent; conflate them and you end up coupling agent logic to a specific provider you later want to change.

.NET agent framework

The single most important thing to get right in 2026 is the Semantic Kernel situation, because a lot of older material is now out of date. Semantic Kernel was the main .NET framework for LLM orchestration for years, but on April 3, 2026, Microsoft shipped Agent Framework 1.0 as the production-ready unification of Semantic Kernel and AutoGen, described as combining Semantic Kernel's enterprise foundations with AutoGen's orchestration innovations into one supported SDK. It is a successor, not a wrapper, built by the same teams.

What that means practically: Semantic Kernel is now in maintenance, it receives critical bug fixes for at least a year after Agent Framework GA, but no new features, and AutoGen is maintenance-only, not for new projects. So the guidance is clear. Start new agent projects on Agent Framework. Existing stable Semantic Kernel agents can stay for now and plan a post-GA migration, especially if they need the new orchestration patterns, MCP, or A2A that only Agent Framework gets. Building a new .NET agent on Semantic Kernel in 2026 means building on a frozen framework, which is the mistake this section exists to prevent. If a tutorial tells you Semantic Kernel is the way to build new agents, check its date.

Agentic AI on .NET

For a while, serious agent development felt like a Python-only world, most frameworks, examples, and tooling grew up there. That changed. With Agent Framework at GA, .NET has a first-class, Microsoft-backed agent SDK with the same core capabilities (multi-agent orchestration, MCP, A2A, checkpointing, observability) available in both .NET and Python from one framework. For teams already in the Microsoft ecosystem, this removes the old pressure to leave C# for agent work.

The .NET stack also has a genuine strength for production agents: the runtime. Agents that need to run reliably at scale, handling many concurrent sessions, surviving failures, maintaining state, map naturally onto Microsoft Orleans, the distributed actor framework, which is why we build our agent infrastructure on it, including our open-source dotPilot orchestrator and Orleans-native rate-limiting and state-machine libraries. So the .NET agent story in 2026 is not just parity with Python, it is parity plus a strong distributed runtime for the reliability and scale that production agents actually need, the concerns we cover in AI agent observability and why AI agents are expensive .

How to start a .NET agent project in 2026

Practical guidance for building a new agent in C#:

• Start on Agent Framework, not Semantic Kernel. New projects go on the GA framework that gets all the new features, MCP, A2A, orchestration, not the maintenance one.
• Write against Microsoft.Extensions.AI abstractions. Depend on IChatClient rather than a specific provider SDK, so you can swap models (cloud to local, one provider to another) without rewriting agent logic.
• Design for the runtime early. If the agent needs to scale or run reliably, plan for a distributed runtime (Orleans) from the start, rather than retrofitting concurrency and state later.
• Build in observability and guardrails from day one. Tracing, cost tracking, bounded loops, and human approval for consequential actions, the guardrails that make an agent safe to run, are architecture, not additions.
• Use MCP for tools. Connect the agent to tools through MCP so you build on the standard rather than hand-wiring integrations, covered in MCP explained .

Do this and you get a .NET agent on the supported stack, portable across providers, ready to scale, and built on the current standards rather than a deprecated framework.

The takeaway

The 2026 .NET AI agent stack is Microsoft.Extensions.AI at the root (the IChatClient provider abstraction) and Microsoft Agent Framework as the agent and orchestration layer, at 1.0 GA since April 3, 2026, unifying the now-maintenance Semantic Kernel and AutoGen into one supported SDK. New agent projects should start on Agent Framework, write against the Extensions.AI abstractions for provider portability, and plan for a distributed runtime like Orleans for scale. The headline for .NET teams: agent development is now first-class and Microsoft-backed, with MCP and A2A support and a strong distributed runtime, so C# is a real, and in some ways advantaged, choice for building production agents, not a compromise you make to stay in the ecosystem.

If you want production AI agents built on the current .NET stack, Agent Framework, Extensions.AI, and Orleans for scale, our .NET AI agent development team delivers end-to-end solutions. Contact us to discuss your agent architecture or project scope.

FAQ

Can you build production AI agents in C# / .NET? Yes - it's our core. We build AI agents in C# and .NET that run in production, with tests, guardrails, and a full audit trail. .NET is now a first-class ecosystem for agents, with Microsoft's own agent tooling and strong concurrency support.

Which .NET agent framework do you use? We work with Microsoft Agent Framework and Semantic Kernel, and connect to OpenAI, Claude, Gemini, or local models as the task needs. We pick per project rather than forcing one stack, and we're honest about the trade-offs.

.NET vs Python for AI agents - which and why? Python wins for research and quick prototypes. .NET wins when the agent has to run reliably at scale inside a real system - strong typing, performance, and concurrency without the usual glue. If you already run .NET, keeping the agent in .NET removes a whole integration layer.

How does .NET and Orleans help agent reliability? Orleans is built for heavy concurrent load without double-acting or losing state - the same properties an agent needs when it takes real actions on real data. It's why the agents we ship keep working under volume instead of only in testing.