Microsoft Foundry Hosted Agents: Benchmarking Deployment Overhead for .NET Agents

Introduction

Building an AI agent locally is usually the easy part.

A small .NET application can connect to a model, provide instructions, call tools, and return a response with relatively little code. The more difficult question often comes afterward:

How do you move that agent from a developer machine into a managed production environment?

Traditionally, deployment can involve containerization, hosting, authentication, session management, observability, scaling, and version management.

Microsoft Foundry Hosted Agents are designed to provide a managed hosting layer for custom agent applications. Hosted Agents support custom agent code and frameworks, including C# applications built with Microsoft Agent Framework. Microsoft manages infrastructure around the deployed agent, including compute, session handling, identity, and deployment lifecycle.

This makes deployment overhead an interesting engineering topic.

Rather than simply saying that deployment is "easy," we can measure the work involved in moving a .NET agent from local execution to a hosted environment.

What Is a Foundry Hosted Agent?

A Hosted Agent allows custom agent code to run inside Microsoft Foundry Agent Service.

The basic architecture looks like this:

.NET Agent
    |
    v
Container Image
    |
    v
Azure Container Registry
    |
    v
Microsoft Foundry Agent Service
    |
    +--> Compute
    +--> Agent Identity
    +--> Session State
    +--> Endpoint
    +--> Observability

The platform packages the agent and deploys it into managed infrastructure. Microsoft documents that Hosted Agents can use custom code or supported agent frameworks and expose a dedicated endpoint after deployment.

For C# developers, this means an existing agent does not necessarily need to be redesigned as a completely separate web application.

Starting With a Minimal .NET Agent

A simple Microsoft Agent Framework application can start as a console application.

For example:

using Azure.AI.Projects;
using Azure.Identity;
using Microsoft.Agents.AI;

var endpoint =
    Environment.GetEnvironmentVariable(
        "FOUNDRY_PROJECT_ENDPOINT")
    ?? throw new InvalidOperationException(
        "FOUNDRY_PROJECT_ENDPOINT is not configured.");

var deployment =
    Environment.GetEnvironmentVariable(
        "AZURE_AI_MODEL_DEPLOYMENT_NAME")
    ?? "gpt-5-mini";

AIAgent agent =
    new AIProjectClient(
        new Uri(endpoint),
        new DefaultAzureCredential())
    .AsAIAgent(
        model: deployment,
        instructions:
            "You are a helpful assistant.",
        name: "HelloAgent");

var response =
    await agent.RunAsync(
        "Explain dependency injection in .NET.");

Console.WriteLine(response);

The exact model deployment name depends on the Foundry project.

At this point, the application is simply a .NET process running the agent locally.

The deployment problem starts when another application or user needs to communicate with it.

The Traditional Deployment Path

Without a managed hosting service, the developer may need to build several pieces around the agent:

Agent Code
   |
   +--> HTTP Server
   |
   +--> Container
   |
   +--> Authentication
   |
   +--> Session Storage
   |
   +--> Scaling
   |
   +--> Telemetry
   |
   +--> Deployment Pipeline

Each component introduces additional configuration and maintenance.

The purpose of Hosted Agents is to provide managed infrastructure around the agent rather than requiring every team to build these components independently.

Making a .NET Agent Hosted-Ready

Microsoft's current .NET integration uses the Microsoft.Agents.AI.Foundry.Hosting package.

The documented setup uses:

dotnet add package Microsoft.Agents.AI.Foundry.Hosting --prerelease

The hosting package is currently published as a prerelease package even though Foundry Hosted Agents themselves are generally available, so teams should review package versions and release notes before using it in production.

The hosted version can use the Foundry agent host:

using Azure.AI.AgentServer.Core;
using Azure.AI.Projects;
using Azure.Identity;
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry.Hosting;

var projectEndpoint =
    new Uri(
        Environment.GetEnvironmentVariable(
            "FOUNDRY_PROJECT_ENDPOINT")
        ?? throw new InvalidOperationException(
            "FOUNDRY_PROJECT_ENDPOINT is not configured."));

var deployment =
    Environment.GetEnvironmentVariable(
        "AZURE_AI_MODEL_DEPLOYMENT_NAME")
    ?? "gpt-5-mini";

AIAgent agent =
    new AIProjectClient(
        projectEndpoint,
        new DefaultAzureCredential())
    .AsAIAgent(
        model: deployment,
        instructions:
            "You are a helpful assistant.",
        name: "HelloAgent");

var builder = AgentHost.CreateBuilder(args);

builder.Services.AddFoundryResponses(agent);

builder.RegisterProtocol(
    "responses",
    endpoints =>
        endpoints.MapFoundryResponses());

var app = builder.Build();

app.Run();

The three hosting-related additions are the agent host builder, Responses registration, and protocol registration. Microsoft describes this as the minimal path for exposing an existing Agent Framework agent through the Foundry Responses protocol.

Why the Responses Protocol Matters

Hosted Agents support two protocol approaches:

Responses
Invocations

The Responses protocol is the recommended starting point for most conversational agents. It provides an OpenAI-compatible /responses endpoint and allows the hosting platform to manage conversation history, streaming, and session lifecycle.

The Invocations protocol is more appropriate when the application needs greater control over the raw request and response or requires custom payloads.

For a normal conversational .NET agent, Responses is usually the simpler starting point.

Running the Agent Locally

Before deploying to Azure, test the hosted version locally.

The Azure Developer CLI provides an agent extension:

azd ext install azure.ai.agents

The project can then be initialized for agent hosting:

azd ai agent init

Start the local agent:

azd ai agent run

The local hosting environment listens on port 8088 by default.

You can invoke it with:

azd ai agent invoke --local "Hello!"

Or with HTTP:

curl -X POST http://localhost:8088/responses \
  -H "Content-Type: application/json" \
  -d '{"input":"Explain async programming in C#."}'

The local environment is intended for development and testing. It should not be treated as a production authentication boundary.

Measuring Local Startup

Before deployment, record the local startup characteristics.

Useful measurements include:

Metric	Measurement
Application startup time	Record
First successful request	Record
Agent response time	Record
Build time	Record
Published output size	Record
Container build time	Record

Do not assume that local startup time represents cloud startup time.

The environments are different.

The purpose of the local measurement is to establish a baseline.

Measuring Provisioning Time

The first deployment step is resource provisioning.

The documented workflow uses:

azd provision

Depending on the project configuration, provisioning can create resources such as:

Microsoft Foundry resources
Foundry project
Model deployment
Application Insights
Azure Container Registry

Microsoft documents this as part of the standard Hosted Agent deployment flow.

Record the time before and after provisioning:

T0 = azd provision starts
T1 = provisioning completes

Provisioning Time = T1 - T0

The actual duration depends on the Azure region, resource availability, subscription configuration, and resources being created.

Measuring Deployment Time

After provisioning, deploy the agent:

azd deploy

The deployment process packages the agent, pushes the container image to Azure Container Registry, and deploys it to Foundry Agent Service.

Measure:

T2 = azd deploy starts
T3 = hosted agent becomes available

Deployment Time = T3 - T2

This provides a much more meaningful measurement than saying deployment requires "two commands."

Two commands describe the developer experience.

Timing describes the actual operational overhead.

Breaking Deployment Overhead Into Stages

A better benchmark separates the process.

Source Preparation
       |
       v
Build
       |
       v
Container Packaging
       |
       v
Image Push
       |
       v
Agent Registration
       |
       v
Infrastructure Startup
       |
       v
Ready

Measure each stage where the tooling exposes sufficient information.

This helps identify the actual source of deployment delay.

For example:

Build              -> Measure
Container push     -> Measure
Agent activation   -> Measure
First request      -> Measure

Without this breakdown, a long deployment time is difficult to diagnose.

Comparing Deployment Approaches

A useful article should not compare Hosted Agents with a fictional deployment process.

Instead, define a real baseline.

For example:

Area	Self-Managed Agent	Foundry Hosted Agent
Container setup	Team-managed	Platform-assisted
HTTP hosting	Team-managed	Managed
Session state	Team-managed	Platform-managed
Identity	Team-managed	Dedicated agent identity
Scaling	Team-managed	Managed
Telemetry	Team-configured	Integrated
Version management	Team-managed	Foundry-managed
Deployment workflow	Custom	azd / Foundry tooling

Microsoft documents dedicated Microsoft Entra identity, managed session state, scaling, and observability as part of Hosted Agents.

The table should not be interpreted as meaning that every self-hosted implementation requires exactly the same components. Architecture varies.

Testing Session Behavior

Hosted Agents can preserve session state.

Microsoft documents persistent $HOME storage for sessions, with compute deprovisioned after a period of inactivity and restored when the session resumes.

A simple test can write a file:

var path =
    Path.Combine(
        Environment.GetFolderPath(
            Environment.SpecialFolder.UserProfile),
        "session-state.txt");

await File.WriteAllTextAsync(
    path,
    "Hosted agent test");

Then test whether the state remains available after the session becomes idle and resumes.

The exact lifecycle should be tested in the deployed environment rather than inferred solely from local behavior.

Testing Identity

Hosted Agents receive a dedicated Microsoft Entra identity.

This matters when the agent needs to access Azure resources or downstream services.

The architecture becomes:

Hosted Agent
     |
     v
Agent Identity
     |
     v
Azure Resource

Instead of embedding long-lived credentials into application configuration.

A production test should verify that the identity has only the permissions required by the agent.

For example:

Agent
  |
  +--> Storage: Read
  |
  +--> Database: Read
  |
  +--> Production Admin: Denied

The exact role assignments depend on the application's requirements.

Testing Observability

Hosted Agents integrate with Application Insights and OpenTelemetry-based tracing.

Microsoft's .NET hosting documentation describes the Application Insights connection string being supplied to the agent container and telemetry being emitted by the hosting infrastructure.

A useful test is to send a known request:

Test Request
     |
     v
Hosted Agent
     |
     v
Model Call
     |
     v
Response

Then verify that the corresponding telemetry is visible.

This should be tested before production rollout.

Testing Agent Versions

Each deployment creates an agent version that can be managed through Foundry.

This is useful when a new version introduces a regression.

A deployment test can therefore include:

Version 1
   |
   v
Validation
   |
   v
Version 2
   |
   v
Validation

Record which version is currently active.

This makes rollback and deployment auditing easier.

Measuring First-Request Latency

Deployment time and request latency are different metrics.

After deployment completes, send a request and measure:

Deployment Complete
        |
        v
First Request
        |
        v
Response

Then send additional requests.

Compare:

First request
Warm request
Repeated request

The first request can involve infrastructure initialization that does not appear in subsequent requests.

Do not use only the first request to represent normal application latency.

Testing Scale-to-Zero Behavior

Hosted Agents can provision compute for sessions and scale down when idle. Microsoft documents session compute deprovisioning after 15 minutes of inactivity while preserving session state.

This creates another useful test:

Active Session
     |
     v
Idle Period
     |
     v
Compute Deprovisioned
     |
     v
New Request
     |
     v
Compute Restored

Measure the response characteristics after an idle period and compare them with a warm request.

The goal is to understand the application's cold and warm behavior rather than assuming they are identical.

Common Mistakes

Measuring Only the Number of Commands

"Two commands" describes the deployment workflow but does not measure deployment overhead.

Measure actual elapsed time.

Comparing Different Agent Applications

If the self-hosted and Hosted Agent implementations use different code, model deployments, tools, or configurations, the comparison becomes difficult to interpret.

Ignoring Provisioning

Provisioning is part of the deployment lifecycle when resources do not already exist.

Measure it separately.

Testing Only Warm Requests

A managed service can behave differently when compute is initialized after inactivity.

Test both warm and cold scenarios.

Giving the Agent Excessive Azure Permissions

A dedicated identity does not automatically mean the agent should have broad access.

Use least privilege.

Treating Local Hosting as Production

The local port is for development and testing. It should not be exposed publicly as a production endpoint.

Troubleshooting

If the hosted agent does not start, check:

Foundry project configuration.
Model deployment name.
Azure authentication.
Azure subscription permissions.
Container build output.
Azure Container Registry access.
Agent version status.
Environment variables.
Role assignments.
Application Insights configuration.

The platform injects important environment variables into the hosted container, including the Foundry project endpoint, model deployment name, and Application Insights connection string.

If the local agent works but deployment fails, compare the local and hosted environment variables first.

Production Considerations

Hosted Agents reduce the amount of infrastructure code the application team needs to operate, but they do not remove the need for production engineering.

Teams still need to consider:

Authentication
Authorization
Model access
Tool permissions
Cost
Data handling
Logging
Failure handling
Application testing
Deployment governance

The managed platform handles infrastructure concerns, but the agent's business logic and security requirements remain the application's responsibility.

Best Practices

Establish a Local Baseline

Test the agent locally before introducing cloud deployment variables.

Measure Each Deployment Stage

Record provisioning, build, image push, deployment, and first-request timing where possible.

Use the Responses Protocol for Conversational Agents

It provides an OpenAI-compatible endpoint and managed conversation lifecycle.

Test Cold and Warm Behavior

Do not use only one request to characterize hosted performance.

Apply Least Privilege

Use the dedicated agent identity with only the permissions the agent needs.

Validate Telemetry

Send known test requests and confirm that traces are available.

Test Rollbacks

Verify that a previous agent version can be restored when a new deployment introduces a problem.

Track Infrastructure Costs

Provisioned Azure resources are billable. Review the resources created by the deployment and remove test environments when they are no longer required.

Advantages

Reduces the amount of infrastructure code required around a custom agent.
Supports C# and Microsoft Agent Framework applications.
Provides managed hosting and scaling.
Provides a dedicated Microsoft Entra identity.
Supports persistent session state.
Provides an OpenAI-compatible Responses endpoint.
Integrates observability and agent lifecycle management.

Disadvantages

The application becomes dependent on Microsoft Foundry and Azure services.
Cloud resources introduce ongoing costs.
The hosting integration may require prerelease .NET packages depending on the current SDK and integration version.
Teams still need to manage application-level security and agent behavior.
Deployment performance can vary by region, resource availability, and environment configuration.
Moving an existing self-hosted architecture to a managed platform can still require application changes.

Conclusion

Deploying an AI agent is more than getting the model to return a response.

A production-ready agent needs hosting, identity, session management, observability, deployment lifecycle management, and a reliable endpoint. Microsoft Foundry Hosted Agents provide managed infrastructure around these concerns while allowing developers to keep their custom agent code and framework.

For .NET developers, the current Microsoft Agent Framework integration provides a relatively small hosting layer around an existing AIAgent. The documented workflow uses the Foundry hosting package, the Responses protocol, Azure Developer CLI tooling, and azd provision followed by azd deploy.

The most useful way to evaluate this approach is to measure it.

Record local startup, provisioning time, deployment time, first-request behavior, warm-request behavior, session restoration, and observability. Then compare those measurements with the infrastructure your organization would otherwise need to operate.

The important result is not that deployment can be done with a small number of commands. The real value is understanding how much operational work those managed capabilities remove and what responsibilities remain with the application team.

For teams already building .NET-based agents, that makes Hosted Agents worth evaluating as a deployment option rather than treating deployment as a completely separate engineering project.