Building Production-Ready .NET A2A Agents on Azure Container Apps

In this blog post Building Production-Ready .NET A2A Agents on Azure Container Apps we will show how to move from a promising AI demonstration to a service your business can secure, operate and scale.

The challenge is rarely getting one AI agent to work. It is getting several agents, business systems and security controls to work together without creating another expensive collection of disconnected applications.

Agent-to-Agent, or A2A, provides a standard way for AI agents to discover each other, exchange work and report progress. ASP.NET Core provides the reliable web service around the agent, while Azure Container Apps runs it without your team having to manage servers or a Kubernetes cluster.

Why A2A matters to technology leaders

Most organisations are building AI capability one use case at a time. Finance may test an invoice agent, operations may build a supplier agent, and IT may create a support agent.

Without a shared communication standard, every connection becomes a custom integration. Costs rise, changes become risky, and the business becomes dependent on whichever AI framework was selected first.

A2A gives agents a common business contract. An agent can describe what it does, accept a task, request more information, provide progress updates and return a result without revealing its internal model, tools or instructions.

Our earlier guide to building interoperable AI agents with A2A explains the wider multi-agent model. Here, we will focus on the practical .NET hosting and production controls needed around an A2A service.

The technology behind a .NET A2A agent

A2A provides the communication contract

An A2A agent publishes an Agent Card, which is similar to a digital business card. It tells approved callers what the agent can do, which communication options it supports and how it should be accessed.

Work can be handled as a quick message or as a longer-running task. Longer tasks can report their status, return files or structured results, request human input and support cancellation.

ASP.NET Core provides the service layer

ASP.NET Core is Microsoft’s framework for building web services in .NET. It handles incoming requests, authentication, configuration, health checks, logging and connections to the services your agent needs.

This matters because an agent should not be an isolated script. It should behave like any other managed business application, with clear access rules and operational monitoring.

Azure Container Apps provides managed hosting

Azure Container Apps runs packaged applications called containers while Microsoft manages the underlying infrastructure. It provides HTTPS access, health monitoring, controlled application revisions and automatic scaling.

For the business, this means the agent can add capacity when demand increases and reduce capacity when it is quiet. You gain much of the flexibility of containers without maintaining a complex container platform.

A practical production architecture

A straightforward design places the ASP.NET Core A2A service inside Azure Container Apps. Microsoft Entra ID verifies the calling agent, while managed identity allows the service to access Azure resources without storing usernames or passwords in code.

• Azure Container Apps hosts and scales the agent endpoint.
• Microsoft Entra ID confirms which users, applications or agents may call it.
• Managed identity gives the agent controlled access to services such as Azure OpenAI, storage or databases.
• Azure Key Vault protects any remaining API keys or sensitive configuration.
• Application Insights and OpenTelemetry record performance, failures and task activity in a searchable form.
• Microsoft Defender and Wiz can identify vulnerable images, risky permissions and exposed cloud resources.

Building the ASP.NET Core A2A service

Start with a narrow responsibility. An “invoice risk agent” is easier to secure, measure and improve than a general agent that can read every document and update every financial system.

Create the ASP.NET Core project and add the official A2A packages. Pin tested package versions in production because agent standards and software development kits are still changing quickly.

dotnet new web -n InvoiceRiskAgent
cd InvoiceRiskAgent
dotnet add package A2A
dotnet add package A2A.AspNetCore

The following simplified example shows the main service registration and endpoint pattern. The agent implementation would contain the business rules, model calls and approved system integrations.

using A2A;
using A2A.AspNetCore;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication()
 .AddJwtBearer();
builder.Services.AddAuthorization();
builder.Services.AddHealthChecks();

builder.Services.AddA2AAgent<InvoiceRiskAgent>(
 InvoiceRiskAgent.CreateCard(
 "https://invoice-agent.example.com/a2a"));

var app = builder.Build();

app.UseAuthentication();
app.UseAuthorization();

app.MapHealthChecks("/health");
app.MapA2A("/a2a").RequireAuthorization();
app.MapWellKnownAgentCard();

app.Run();

The Agent Card should be specific. It might advertise a skill named “review invoice risk”, accept invoice details and return a risk rating with reasons. Avoid descriptions such as “handles finance”, which make permission boundaries and testing difficult.

The handler can then create an A2A task, record that work has started and return the completed result.

public async Task ExecuteAsync(
 RequestContext context,
 AgentEventQueue events,
 CancellationToken cancellationToken)
{
 var task = new TaskUpdater(
 events,
 context.TaskId,
 context.ContextId);

 await task.SubmitAsync(
 cancellationToken: cancellationToken);
 await task.StartWorkAsync(
 cancellationToken: cancellationToken);

 var result = await ReviewInvoiceAsync(
 context.UserText,
 cancellationToken);

 await task.CompleteAsync(new Message
 {
 Role = Role.Agent,
 MessageId = Guid.NewGuid().ToString("N"),
 Parts = [Part.FromText(result)]
 }, cancellationToken: cancellationToken);
}

This task-based approach is useful when another agent needs progress information or when a process may take longer than a normal web request. For example, an invoice review may need to retrieve a purchase order, compare supplier details and wait for manager approval.

Deploying to Azure Container Apps

Package the service into a container image and deploy it through an automated delivery pipeline. Avoid building and releasing production agents manually from a developer’s laptop.

az containerapp up \
 --name invoice-risk-agent \
 --resource-group rg-ai-production \
 --location australiaeast \
 --source . \
 --ingress external \
 --target-port 8080

External access is not always necessary. If only internal applications will call the agent, use private networking or place an approved API gateway in front of it.

Container Apps revisions let you deploy a new version alongside the current one and gradually move traffic across. If accuracy, latency or error rates deteriorate, you can return traffic to the earlier revision instead of attempting a rushed repair.

Production controls that should not be optional

1. Authenticate every caller. Publishing an Agent Card does not mean every discovered agent should be trusted.
2. Authorise each action. An agent allowed to review an invoice should not automatically be allowed to approve or pay it.
3. Keep high-risk approvals human. Payments, account changes, staff actions and sensitive disclosures should require an accountable person.
4. Limit data access. Give the service access only to the systems and records needed for its stated job.
5. Record cost and activity. Track model usage, task duration, failures, tool calls and downstream API costs by agent.
6. Scan and patch containers. Regularly rebuild images and check them for known security weaknesses.

These controls also support Essential Eight alignment, the Australian Government’s cybersecurity framework that many organisations use to reduce common attacks. They can assist with application control, patching, multi-factor authentication and restricting administrative access, although deploying an agent does not make an organisation compliant by itself.

For a deeper look at agent reliability and governance, see building production AI agents with Microsoft Agent Framework and .NET.

What the business outcome can look like

Consider a 200-person professional services company where 25 employees each spend 30 minutes a week checking invoices against purchase orders and supplier records. Across 48 working weeks, that represents roughly 600 hours of staff time.

An A2A design could let an invoice agent request supplier checks from a separate compliance agent, produce a structured recommendation and send exceptions to a person. The goal is not fully autonomous payment processing; it is faster review with clearer evidence and fewer manual handovers.

The result can be lower administration costs, more consistent checks and a searchable record of why each recommendation was made.

Start with one measurable workflow

A2A is valuable when independent agents need to cooperate across teams, frameworks or organisations. It is unnecessary when a single application function or conventional API can solve the problem more simply.

Choose one workflow, establish a baseline for time, cost and errors, and run a controlled pilot. Define access boundaries and human approvals before connecting production data.

CloudPro Inc brings more than 20 years of enterprise IT experience to these decisions, combining practical .NET and Azure delivery with Microsoft, Wiz, Defender, OpenAI and Claude expertise. We help organisations build useful agent services without separating AI experimentation from security and operational reality.

If you are considering an A2A project but are unsure whether the architecture, security controls or likely savings make sense, we are happy to review the proposed workflow with you — no strings attached.