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

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:

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

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.

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 distributed, microservices systems. While Aspire is still great for that, it is even better as an agent-friendly runtime orchestration layer.

It has several key features that make it a foundational component of an agent-friendly software stack:

A key piece of the story is Aspire’s easy-to-use and built-in telemetry and observability backend.

This screenshot of the Zeeq Aspire dashboard shows what a typical local runtime looks like:

It doesn’t look too different from Tilt or Docker Desktop, but peek the telemetry:

Rich built in telemetry lets agents get visibility into everyday types of issues like the underlying database queries being issued.

Most importantly, the telemetry sink also surfaces gen.ai attributes that give visibility into standard agent interactions: materialized prompts, tool calls, etc.

Aspire materializes gen.ai spans to make it easier to see final prompts, tool calls, and agent interactions. The agents can search these spans directly.

You will certainly get much, much richer telemetry via specialized tools like Langfuse (not mutually exclusive since it becomes just another OTEL sink), but Aspire’s built-in, searchable telemetry sink let’s agents autonomously iterate with visibility into the runtime state.

aspire otel spans zeeq-server --search "BEGIN CHANGES"
--non-interactive -nologo
--dashboard-url http://localhost:15010

Searches through the list of spans that the agent can then then read for a full trace of the execution flow (assuming your code has been well-instrumented!):

The CLI allows agents to search through the telemetry spans before doing a full read to trace through an instrumented execution flow

The aspire CLI becomes a primary interaction point with agents for runtime resources including:

Search logs for a given resource

aspire logs zeeq-server --search "principal"
--non-interactive --nologo

Allow agent to further filter via jq

aspire logs zeeq-server --search "principal"
--non-interactive --nologo --format json

Check application status with all environment variables

aspire describe zeeq-server --format json

Check application status and query for specific properties

aspire describe zeeq-server --apphost ./host --format json |
jq -c '.resources[] | { name, displayName, state, healthStatus, commands: (.commands // {} | keys) }'

Rebuild and restart a compiled resource like a .NET or Rust backend

aspire resource zeeq-server rebuild

Restart a Node frontend resource

aspire resource zeeq-web restart

Port isolation for worktrees

The inner network loop becomes a key feature if you’re using worktrees and you want to run the full application stack in isolation to allow for agents to work in parallel.

Run with randomized ports and isolated user secrets

aspire run --isolated

Wiring CSharpRepl into the running application

CSharpRepl (CSR) is a command line REPL that allows interactive C# scripting.

In the past, this has been generally useful for quickly trying out C# code without having to create a project or compile and run. However, the real unlock with CSR is that it can be wired into a running instance of the application.

A typical dependency graph for a web API handler endpoint.

If the agent can only test the web API handler entrypoint via curl, then it cannot easily diagnose issues with Service α since it must always pass through three layers of dependencies before it can test an input scenario with Service α. While some of this can be covered with unit and integration tests, in some cases — especially with AI-enabled apps — there’s no substitute for being able to test the runtime application directly like a human might with a debugger.

This is precisely what CSR allows. Will Fuqua (author of CSharpRepl) has a writeup that shows the gist of this:

Get the installation location of the CSharpRepl tool hooks

csharprepl connect init

This yields two environment variables (example) that can be wired up via Aspire

export DOTNET_STARTUP_HOOKS=".../tools/csharprepl/.../connector/CSharpRepl.InjectedHook.dll" export ASPNETCORE_HOSTINGSTARTUPASSEMBLIES="CSharpRepl.InjectedHook"

Then list the candidate processes for CSR to connect to

csharprepl connect list

And connect to the PID

csharprepl connect 6580

Once connected, the agent can then directly manipulate Service α and any other runtime dependencies without having to go through the API entrypoint. This allows agents to:

Think of it like a blood test versus directly examining an organ or tumor. The blood test is still useful, but being able to directly probe the organ or tumor will give a more complete picture of underlying “operational runtime behavior” and make it easier for diagnosing issues.

How wrap and replace can be used by agents to diagnose runtime issues, insert additional telemetry, and test new implementations rapidly.

Together, this toolset gives agents a huge unlock because the agents can reach deep into the runtime configuration of the application to test different scenarios. Three aspects that I find this boosts:

While it is true that a lot of the innovation in the AI space originates from the Python ecosystem, for most teams building business applications using AI, the C# and .NET stack is a highly underrated and perhaps surprising option, especially for folks that haven’t dabbled in C# or .NET since the .NET Framework era.

Modern .NET and C# are well-suited for teams that want to build real products and real software on a stable base in a programming language and stack that offers agents strong build-time guardrails as well as throughput and performance at scale where it matters (consider the API boundary serialization of JSON and gRPC/Protobuf, for example — both areas where C# and .NET excel).

In Part 2, we’ll build a practical template for a C# + .NET agent-enabled application that you can use as a starting point for your own projects (wiring EF core for build time checked database queries, minimal web API endpoints, test containers for integration testing, etc.). We’ll also go into real-world examples of how to let agents operate the stack effectively when building autonomously including a skill that guides agents on getting the most out of CSharpRepl.

If you are curious to see a real-world setup, check out the Zeeq.ai repo: https://github.com/zeeq-ai/zeeq-app

Still human written (mistakes and all!); see the file history in the repo.