Getting started with A2A in .NET

As we continue to move away from using AI tools to power chatbots, new ways of working are becoming more important. Agent technologies have proven to be an interesting way to automate business processes. They treat AI models as a flexible orchestration layer that makes it possible to dynamically build payloads for existing APIs based on user queries and intent.

Using enterprise AI in.NET

Microsoft has been adding tools to its various development platforms to support building these new applications, from the agent development framework in its Semantic Kernel orchestrator to the growing number of Model Context Protocol (MCP) features across its applications. These let you build your own AI applications that work with services like Azure AI Foundry.

On their own, agents are a powerful tool, but they get more useful and more interesting when you bring them together, especially when you’re building increasingly specialized tools, mixing large language models (LLMs) and other machine learning techniques. Using agents to orchestrate agents, choosing from a catalog of services, provides a new take on the service-oriented architecture models of the early 2000s, using them and the MCP servers they build on as a new interface description language.

Task-focused agent AI with A2A

What’s needed to deliver a network of cooperating agents is, of course, a standard that allows any agent to communicate with any other agent, providing details of agent capabilities as well as sending and receiving data. That’s where the Google-developed Agent2Agent Protocol (A2A) comes into play. A2A is designed to work with any agent with any form of data, as well as handling long-running tasks.

Unlike chatbots and other user-centric AI applications, agents (and therefore the A2A protocol) are task-focused. In the context of A2A, the client agent that makes the initial request uses its knowledge of a set of agent capabilities to break a task into relevant parts and then deliver those to the remote agents best suited to respond to those sub-tasks. When dealing with long transactions, tasks or notifications of task progress are returned to the client agent, which assembles the various results into content for the user or the calling application.

A2A in.NET

Microsoft recently released an early preview version of a.NET A2A SDK that supports both sides of A2A interactions, allowing you to build both client and remote agents using familiar tools. A client agent built with the SDK can call any compatible agent, no matter where it’s hosted or how it was developed, with the same support for remote agents.

The first release of the SDK covers most key features of the protocol: handling agent capability discovery, direct messaging, task-based interactions, and working with streaming data. It supports quick interactions, long workflows, and real-time operations. On the remote agent side, you can use ASP.NET Core to add A2A support to existing agents.

The.NET A2A SDK is being developed in the open on GitHub and is distributed via NuGet. It’s licensed using the Apache 2.0 license, so it should be compatible with most enterprise open source policies. It’s important to remember that this is a preview, and both the SDK and the A2A protocol are likely to change. For one thing, the A2A protocol was only released at the beginning of April 2025.

Building your first A2A interface

Getting started with the preview is easy enough. All you need is a recent.NET release (Version 8.0 or later) and your choice of.NET development environment. You can then create a basic agent, installing the A2A and A2A ASP.NET Core packages from NuGet via the.NET CLI. Sample code should help you get started; there’s support for clients and servers, as well as Semantic Kernel.

There are a lot of similarities between adding MCP support to an agent and giving it A2A support. If you’re simply adding A2A to an existing agent, you’re providing a wrapper that takes A2A messages and delivers them in the agent’s expected format. Alternatively, you can use the A2A SDK to add new interfaces to existing or new agent code. This latter option is probably best for developing new agents so that you can offer A2A support for client agents as soon as your code is live.

Describing agents with Agent Cards

One key feature of the A2A protocol is the Agent Card. This is a standard way of describing the capabilities of an agent and how it expects to interact with the rest of the world. It is an essential component of the protocol, as it’s used for discovery—either directly via a known URL or by publishing it to a registry. Registries can be public or private, allowing you to have different versions of an A2A operation for your own internal interactions with an agent and for access from the wider internet.

Cards are published as JSON and can be either generated by an agent or written by a developer and stored on a web server. You need to ensure that cards don’t contain secrets and that you have applied appropriate access controls, for example, using OAuth or a similar protocol to lock down access to approved users and applications.

The Agent Card has a relatively simple format that mixes human- and machine-readable content. This allows applications to display which agents they are using and why, ensuring a basic level of explainability. The most important aspect of the Agent Card is the listed agent skill, which determines how the agent will be used in the A2A workflow. It will contain sample prompts, along with input and output types.

The agent skill is followed up with a description of the support interface type, describing how the client agent should call the remote agent. An agent can support multiple protocols, such as REST and gRPC. You’ll need to include the interface URL as well.

If you’re using the.NET A2A SDK, much of this can be done in code, ensuring that remote agent interfaces are updated when you update your code and that you can build appropriate tests to ensure that everything is in sync. As well as writing cards, the SDK includes an Agent Card object that holds data from a remote agent and provides a tool for quickly targeting endpoints.

Agent-to-agent communication

Another key feature is how the agents communicate. You can simply send a message from a client agent to a remote agent; the client uses.NET’s asynchronous programming tools to wrap the sent message while it waits for a response. Similarly, you can send more complex tasks, polling for a response showing whether it is running, has completed, or has failed. You can even use the SDK to quickly process streaming data.

ASP.NET Core support is another useful feature of the A2A.NET SDK, as it allows you to quickly expose an AI application running in ASP.NET as an agent. Much like ASP.NET Core’s MCP support, you can easily add a new route to your ASP.NET Core application, for example, using an /agent URL as its canonical endpoint. An extension method does most of the work for you, using data from your remote agent’s A2A implementation to respond to calls from client agents.

You’re able to test your agents with the A2A project’s Inspector. This is a Python application that can be installed on a server and used to display its Agent Card and validate its operation against the A2A specification. It also gives you a basic console where you can interact with the model to ensure it behaves as expected.

With the A2A protocol still evolving, you should expect the.NET A2A SDK to be a moving target and for changes to be rapid. However, what we have today is a good place to start exploring the protocol with.NET-based AI applications. There’s enough commonality with ASP.NET Core’s MCP tool that the two technologies can work together and wrap the same models.

Microsoft has been building a lot of.NET-based AI tools, and with features like the.NET A2A SDK, it’s getting them into your hands as quickly as possible, ready for experiments and prototypes.

If you’re looking at building task-based agent applications, this is a good place to start, especially with its tools for watching the behavior of long transactions. This allows you to keep users and services informed, while allowing your applications to capitalize on modern AI’s role as a tool for handling context over lengthy periods of time. It will be interesting to see what these tools can build and how quickly they can help us get away from dead-end chatbots.