The Unexpected AI Stack: C# + .NET (Part 1)

CharlieDigital2 pts1 comments

@chrlschn - The Unexpected AI Stack: C# + .NET (Part 1)

Charles Chen (@chrlschn)

The Unexpected AI Stack: C# + .NET (Part 1)

Aug 10, 2026

Summary

C# and .NET as a stack are probably flying under the radar for many teams building new apps in the agentic era

For teams already using legacy C# and .NET, it may not be clear how to best leverage the modern .NET stack tooling to speed up agentic development

Aspire tooling provides agents a programmable, isolated runtime orchestration layer that improves agent autonomy and facilitates agentic patterns like worktrees and parallel development.

CSharpRepl lets agents interact with an instance of the running application and manipulate the runtime state of the application including wrapping and replacing existing functions.

Combined, this set of tooling gives agents more autonomy to iterate and build stable, correct, production-ready code that is proven in runtime configurations efficiently.

Part 1 (👈 you are here) will introduce two under-the-radar components of the .NET stack that make it surprisingly amenable to building software with agents: Aspire and CSharpRepl.

Part 2 will dive into a hands-on implementation from the ground up to scaffold an open-source template for teams to build on top of.

Part 3 will implement the next layer of the application including a simple streaming interface to the Copilot SDK agent.

Part 4 will extend the application with Testcontainers to demonstrate how to simplify test execution for agents with stateless containers as well as telemetry for runtime visibility.

Part 5 will configure the application with logging, telemetry, and observability before diving into building the actual application using your coding agent.

The full repo : https://github.com/zeeq-ai/zeeq-tmpl

Why C#?

In an age when agents can write code in any programming language, it’s fair to ask: why have agents write code in C#?

Last year, I was a technical lead on the effort at Motion ($500m valuation, series C, post YCombinator startup, ~40 engineers) to move the entire backend off of TypeScript + Node and shift to a combination of C# and F# for all future backends.

The reasons are numerous and I’ve written about this extensively before, but it’s worth summarizing this again in mid 2026 framed in the context of building in an agent-first reality:

Build- and run-time type checks provide a foundational layer of safety and correctness to check agent outputs

Clean, easy to understand build-time error traces; compare this to typical TypeScript type error stacks…

Roslyn static analyzers that allow for custom static analysis for agent guardrails

Roslyn source generators for terse runtime code to remove boilerplate and reduce context for agents on the read path

Extensively and richly documented with broad first-party libraries means that LLMs have very good coverage in their training data. While Python and JavaScript may have more representation, the lack of a standard library and BCL means that there are many variants of how to accomplish the same task.

EF Core (mature, powerful .NET ORM) provides build-time checks for database schemas and decreases the likelihood of runtime errors from schema changes.

Mature, stable, consistent, easy to use tooling and tool chain. Just dotnet. Again, easy for agents to work with, minimizing the need for skills or explanatory text for the agents.

Aside from that, if developers are no longer writing code, why not choose a platform that has:

Built-in primitives for in-process asynchronous coordination (System.Threading.Channels, Orleans actor model)

Higher performance and throughput where it matters (boundary serialization for both JSON and gRPC/Protobuf, etc.)

Better story around ecosystem security and dependency management (NPM vs Nuget)

A whole professional organization continuously patching and fixing the platform and libraries

Given the benefits of adding both build and runtime type safety as well as a mature, well-documented, and broad first party platform, C# is a surprisingly strong choice for building real software with AI.

The objective of this two-part series is to shed some light on how C# and the .NET ecosystem is an ideal foundation for building production software with agents.

Encapsulating the runtime with Aspire

If you’re using Docker Compose or Tilt for dev runtime orchestration, you may have occasionally wished that it was just a bit more programmable. That’s exactly the gap that Aspire fills: a programmable orchestration layer that makes it easy to build an isolated runtime stack that agents can control while building software.

The best analogy is to consider the difference between Terraform and Pulumi or CDK. Terraform is a declarative tool for building infrastructure, while Pulumi and CDK are programmable tools that allows teams to build infrastructure with code. Aspire is the same thing for orchestrating your runtime stack.

Early iterations of Aspire were focused more on building...

agents runtime part building stack build

Related Articles