Foundry Hosted Agents in C#: What the One-Package, Two-Command Deploy Actually Hides

There is a predictable artifact in .NET teams experimenting with AI right now: an agent that works beautifully in dotnet run and has no sanctioned path to production. It demos well. It answers questions. And it lives on a laptop, because nobody agreed on where agents are supposed to run.

Microsoft’s answer is Foundry Hosted Agents in C#. The .NET Blog put it bluntly in the source post: “Turns out deploying it to production takes 1 NuGet package, 3 lines of C#, and 2 commands.” That is Microsoft’s published count, verbatim. The headline writes itself. The headline is also not the story.

The story is that Microsoft is turning agents into an ordinary deployment target, the way App Service made web apps an ordinary deployment target over a decade ago. Boring is the point. Boring is what enterprises buy, because boring means governed, callable, and running on a managed runtime instead of containers your team patches at 2 a.m. Teams that read this correctly escape POC purgatory first. Everyone else keeps treating agents as research.

How to deploy an AI agent to Azure: the published path

The path from Microsoft’s .NET Blog post, compressed:

1. Build locally with Microsoft Agent Framework. A normal .NET project using the Microsoft.Agents.AI package family: a chat client, instructions, optionally tools. It runs under dotnet run like any console or web app.

2. Add the hosting package and the three lines. One NuGet package from the Agent Framework family adds the hosted-agent surface. The three lines wrap your existing agent in a host and expose it as a deployable app. No rewrite of the agent itself. That part of the pitch is real.

3. Deploy with the Azure Developer CLI. Two commands in the standard azd pattern: azd init to set up the environment, then azd up to provision and deploy. Foundry stands up the hosted agent and hands you an endpoint you can call and manage from the Foundry portal.

That is genuinely the whole inner loop. It is also not the whole effort.

The takeaway from the demo section is narrow and real: once the prerequisites exist, the inner loop is exactly as short as Microsoft’s own published count - one package, three lines, two commands.

What Foundry Hosted Agents in C# actually abstract away

Three lines of code only look small because of what moved underneath them. You need to know what moved, because when the magic breaks - and in production it will - you debug the layer below the abstraction, not the abstraction.

The table below is a read of the division of labor on the Foundry Hosted Agents C# path, based on the public Azure AI Foundry Agent Service documentation. Several of these capabilities are preview-stage and version-sensitive, so verify each row against the current docs before you depend on it.

Now the half the pitch skips: what is still your job. RBAC assignments for callers and for the agent itself. Managed-identity permissions to every downstream system your tools touch. Diagnostic settings, log retention, and alerting - the docs describe monitoring integration, but turning it on and building dashboards is on you. Foundry hosts the agent; it does not absolve you of running it.

Treat the three lines as the boundary of Microsoft’s responsibility, and write down everything on your side of that boundary before go-live.

The strategic read: agents became a deployment target, not a product category

Foundry Hosted Agents is App Service for agents. That is the correct mental model, and it is a deliberate one.

Until now, “agent” meant a bespoke stack: pick a framework, pick a host, hand-roll identity, hand-roll observability, defend all of it to a review board. Every agent was a science project with its own infrastructure story. That is a big part of why so many never leave the pilot stage.

The trajectory is consistent. Microsoft publicly announced the convergence of Semantic Kernel and AutoGen into Microsoft Agent Framework, sharply narrowing the “which Microsoft agent SDK do I bet on?” question. Foundry is becoming the hosting and governance plane those agents deploy into - which also means agent spend becomes platform spend, subject to the same discipline as AI cost governance on Azure generally.

Code converges on one framework. Operations converge on one platform. Works-on-my-machine and governed-and-callable become the same artifact.

The position this article defends for architects: standardize on Agent Framework now for new .NET agent work. Not because Semantic Kernel or LangChain are dead - they are not, and consolidation reduces fragmentation rather than killing alternatives - but because every framework you add today is a migration you fund later.

The takeaway: stop evaluating agents as an AI initiative. Evaluate them as an app workload with an unusual runtime, because that is what Microsoft just made them.

Where the three-lines pitch breaks down

The capability is good. It is not complete. Five production questions the blog post does not answer, with an honest read of the public docs at the time of writing:

Versioning and rollback. This is the weakest spot. Agent definitions update through the API and SDK, but the public docs do not describe first-class version pinning, managed rollback, or built-in approval workflows for definition changes. Treat rollback as your responsibility unless the current docs state otherwise. Keep definitions in source control, deploy through CI/CD, and treat the portal as read-only for anything stakeholder-facing.

Prompt and tool change management. Same gap, different face. A prompt change is a production change with no compiler to catch regressions. Bring your own evaluation gates; the platform does not impose them.

Networking. Private endpoints and managed network isolation exist at the Foundry resource level per the docs, but tool-by-tool parity inside private networks has historically had gaps. If your security posture requires full network isolation across every tool an agent calls, verify each tool against current documentation before promising anything. Resource-level support does not mean feature-level support.

Cost. There is no flat “hosted agent” price to cite. Spend distributes across model tokens, tool usage, storage, and any search or grounding services the agent touches. The public pricing pages do not give you a clean per-agent number, and this article will not invent one. Budget it the way you would any Azure LLM workload: instrument first, cap second.

Multi-agent orchestration. Connected-agent patterns exist in the platform, but orchestration topology, failure handling between agents, and shared-state design remain your architecture problem, not a managed feature. This area is evolving fast; check current capabilities before designing around them.

One more caveat covering this entire section: preview and GA status varies per feature, not per service. A GA banner on the service does not mean every sub-feature underneath it is GA. Check the dated Microsoft Learn status of each capability you depend on the day you commit.

The line to write on the whiteboard: ship a pilot on Foundry hosting now, but write down your rollback story before anything stakeholder-facing depends on it.

Foundry hosting vs rolling your own: pick one deliberately

For a .NET shop’s first production agent, Foundry hosting is the right default. Self-hosting on Container Apps or AKS is the exception you justify in writing, not the starting point.

Foundry hosting wins when you want the fastest path to a governed endpoint, when you have no platform engineering team to run container infrastructure, and when you are a Microsoft-stack shop that wants Entra identity and documented monitoring integration native rather than assembled. If that list reads like your team, the default is already decided.

Container Apps wins when you need scale-to-zero economics under spiky load, custom containers or sidecars, or Dapr and KEDA patterns you already run. AKS wins when you have hard network-isolation requirements Foundry cannot yet meet for your tool set, specialized hardware needs, or an existing Kubernetes estate with a team that operates it well.

In both self-hosted cases you take back the entire management burden in Foundry’s column of the table above - identity, endpoint, state, telemetry. That burden is the real price, not the compute bill.

The takeaway: default to Foundry hosting, and make self-hosting a documented decision with named requirements driving it.

Try it yourself: the 30-minute repro checklist

The 30 minutes covers the deploy loop only, and it is illustrative - calibrate against your own environment. The prerequisites are the real time sink the first time through, and how long they take depends entirely on who controls your subscription. Separate the two honestly:

Run it this week. The moment you can deploy an AI agent to Azure with a NuGet package and two commands, the agent stops being a research project and becomes an app workload, and your organization’s excuse for keeping it in POC purgatory expires with it. The checklist above is the expiry notice. Cash it.