[FEATURE] Native C#/.NET SDK and harness distributed through NuGet #5271

Human Overview

I would like to provide harness support for C#/.NET based solutions via nuget package consumption. This would enable these types of solutions to natively inject agent based operations directly into the .NET framework.

SDK Language

Both / Not language-specific

Problem Statement

I am targeting a C# native version of the SDK because I have a need for it in other .NET projects. I would like to bring Strands agentic capabilities into those applications through NuGet, with the SDK and harness running directly in the .NET process. The existing Python and TypeScript implementations give us a strong foundation, but .NET teams would benefit from a native API that fits their existing applications, tooling, and deployment practices.

Proposed Solution

Introduce a native C#/.NET SDK and assembled harness, distributed as NuGet packages, with documented behavioral parity against both the Python and TypeScript implementations.

The target would include:

• Modern .NET applications on Windows, Linux, and macOS.
• Existing .NET Framework 4.8 applications through compatible .NET Standard 2.0 package assets.
• Agent execution, model providers, streaming, tools, MCP, hooks, state, sessions, and harness features, with differences between the existing implementations documented explicitly.
• Idiomatic C# APIs, cancellation and resource ownership, focused abstractions, and tests covering success, failure, and recovery paths.
• GitHub Actions verification across operating systems, including execution on the actual .NET Framework 4.8 runtime and tests that consume the packed NuGet packages.

I want to do this properly, with a clear parity target, maintainable code, and evidence behind compatibility claims.

Use Case

This would let me add Strands agents to existing C# applications and new .NET services without introducing a separate Python or Node.js service just to host the agent. For example, a modern .NET service could use native tools, streaming, and session persistence, while an existing .NET Framework 4.8 application could use the compatible package assets. The goal is to make the same agent and harness capabilities available to .NET teams within the environments they already support.

Alternatives Solutions

Calling a Python or TypeScript service is an option, but adds another runtime and a service boundary to maintain. Existing community .NET implementations are also relevant; #2231 already raises that possibility. I would like to clarify the expected scope and contribution path here so this work can complement existing efforts and follow the project's standards.

Additional Context