What BUILD 2026 Means for .NET Agent Developers

BUILD conferences usually give .NET developers one or two things to chew on. BUILD 2026 gave agent developers an entire meal: the Microsoft Agent Framework showed up as a stable 1.0 platform with a production harness, Foundry Agent Service grew a managed runtime for hosted agents, Foundry IQ picked up serverless retrieval and a proper memory story, and a stack of previews — CodeAct, Toolboxes, Routines, Agent Skills — sketched out where this is all heading.

That is a lot of surface area, and most of the coverage so far has been press-release prose. This post is the engineer’s cut: for each announcement, what it actually is, why you should care, and what — if anything — you should do about it this quarter. If you are new to the framework itself, start with the Microsoft Agent Framework developer’s guide and come back; this article assumes you know what agents, tools, threads, and workflows are.

The short version

If you only read one section, read this one:

1. Agent Harness is now the production execution layer for Agent Framework agents — context compaction, tool approval, shell access, todo tracking, and skills, out of the box. This is the biggest single change to how you will structure .NET agent code.
2. Hosted Agents in Foundry Agent Service give you a managed, scale-to-zero runtime for containerized agents with per-session sandboxes. GA was expected in early July 2026, so it is landing right about now.
3. Agent Skills graduate from “interesting idea” to a first-class provider in the harness — modular, filesystem-loaded capabilities your agent discovers at runtime.
4. CodeAct (alpha) collapses multi-turn tool calling into a single generated program executed in a Hyperlight micro-VM — Microsoft’s numbers show roughly half the latency and a third of the tokens on representative workloads.
5. Foundry IQ + agent memory move retrieval and remembering from “roll your own RAG” to platform services: serverless knowledge bases, and session, user, and procedural memory scopes in public preview.

Everything else — Routines, Toolboxes, ASSERT, the Agent Control Specification, Voice Live, the .NET 11 agentic web previews — orbits those five. Let’s take them one at a time.

Agent Harness: the production loop you were writing by hand

Every team that has shipped an agent on .NET has written the same code: a loop that runs the model, watches token usage, truncates or summarizes context when it gets long, gates dangerous tool calls behind human approval, and keeps some scratch state on disk. The Agent Harness, production-ready as part of the 1.0 GA, is Microsoft admitting that this layer is common infrastructure and shipping it.

What you get when you wrap a chat client with AsHarnessAgent(...):

• Automatic context compaction. The harness monitors token usage across long tool chains and compacts history before you hit the context window, so a 40-step task does not die at step 37.
• Default system instructions for task breakdown and tool usage, merged in front of your own agent instructions — sensible agentic behavior without prompt archaeology.
• A set of built-in providers: FileMemoryProvider (session-scoped file persistence), FileAccessProvider, TodoProvider (work-item tracking), AgentModeProvider (plan vs. execute modes), AgentSkillsProvider, BackgroundAgentsProvider for parallel subtask delegation, a built-in web search tool, and — on .NET only — a sandboxed ShellExecutor.
• Middleware that matters in production: ToolApprovalAgent for approval rules with “don’t ask again” semantics, and OpenTelemetryAgent for automatic tracing that follows the semantic conventions, so your agent shows up in the same dashboards as the rest of your services.

The shape in C# is deliberately small:

AIAgent agent = chatClient.AsHarnessAgent(
    maxContextWindowTokens,
    maxOutputTokens,
    new HarnessAgentOptions { /* providers, approvals, ... */ });

await HarnessConsole.RunAgentAsync(agent, userPrompt, options);

Why it matters: the harness is opinionated in exactly the places where teams get agents wrong — context management, approvals, observability. It also changes the migration calculus: if you are still weighing frameworks, the Semantic Kernel vs. Microsoft Agent Framework comparison now has to account for the fact that only one of them ships a production harness.

What to do now: if you have a hand-rolled agent loop, plan to delete it. Start with the Agent Harness deep dive for .NET, wrap one existing agent, and compare behavior on your longest-running task. The ShellExecutor being .NET-only is a small but telling signal about where the serious server-side investment is going.

Hosted Agents: Foundry becomes the place your agents run

Building an agent was never the hard part; operating one is. Hosted Agents in Foundry Agent Service are a managed runtime for containerized agents — you write the agent with the Agent Framework (or LangGraph, or the GitHub Copilot SDK; the runtime is framework-agnostic), and Foundry runs it with:

• Scale-to-zero pricing — no cost while the agent is idle, which changes the economics of “an agent per customer” designs.
• Per-session, VM-isolated sandboxes with dedicated compute and a persistent filesystem that survives scale events — your agent can resume with its working files intact.
• Two protocols: an OpenAI-compatible, stateful Responses API, and a schema-free Invocations protocol for everything that does not fit the chat shape.
• Built-in OpenTelemetry flowing to Application Insights without extra wiring.

Exposing an Agent Framework agent as a hosted endpoint from ASP.NET Core is two lines:

builder.Services.AddFoundryResponses(agent);
app.MapFoundryResponses();

Alongside this, Routines (public preview) let you schedule agents on timers — overnight issue triage, daily reporting — which quietly covers a large fraction of real enterprise agent use cases that are batch jobs wearing an agent costume.

Why it matters: this is the missing deployment tier between “console app on my machine” and “full Kubernetes platform.” Sandboxed sessions plus durable filesystem is precisely what long-running autonomous agents need and what is painful to build yourself.

What to do now: if you have an agent in production on your own infrastructure, benchmark it against the hosted model — the walkthrough in Hosted Agents in Foundry Agent Service with .NET covers the Responses API setup end to end. If you would rather stay on infrastructure you control, container-based self-hosting remains a first-class path; see deploying a .NET agent to Azure Container Apps for that route. The right answer for most teams will be hosted for stateful, sandboxed, spiky workloads and self-hosted where you have hard network, residency, or cost constraints.

Agent Skills: capabilities as files, not deployments

The AgentSkillsProvider graduated with the harness, and Foundry’s Toolboxes added Skills as versioned, project-scoped resources discoverable over MCP. The idea is the same in both places: instead of baking every capability into your agent’s code and prompt, you package a capability — instructions, supporting scripts, resources — as a modular unit on the filesystem, and the agent discovers and loads it when the task calls for it.

Why it matters: skills invert the deployment model. Today, teaching your agent a new procedure means editing prompts, rebuilding, and redeploying. With skills, capability delivery decouples from agent delivery — you can version skills independently, share them across agents, and scope them per project. Progressive disclosure also keeps your base prompt small: the agent only pays the token cost of a skill when it actually uses it. If you have ever watched a system prompt grow to 4,000 lines of edge-case instructions, this is the exit.

What to do now: carve one well-understood procedure out of your system prompt — a report format, a runbook, a code-review checklist — and package it as a skill. The Agent Skills for .NET guide walks through the folder format, discovery, and how skills interact with the harness’s other providers. This is the cheapest experiment on this list with the highest architectural payoff.

CodeAct: fewer turns, dramatically fewer tokens

CodeAct is the most technically interesting announcement and the least production-ready one — it ships as an alpha in the agent-framework-hyperlight package. The premise: instead of the classic loop where the model requests one tool call, waits, reads the result, and requests the next, the model writes a single program that calls your tools via call_tool(), and that program executes inside an isolated Hyperlight micro-VM.

Microsoft’s representative workload numbers are worth quoting because they are the whole argument: the traditional approach took 27.81 seconds and 6,890 tokens; CodeAct took 13.23 seconds and 2,489 tokens — a 52.4% latency reduction and 63.9% fewer tokens. Every tool round-trip you eliminate is a full model inference you did not pay for, and for tool-heavy workloads that compounds fast.

Two honest caveats. First, it is alpha, and the published examples are Python-first — .NET developers should watch this rather than build on it. Second, “the model writes a program and we execute it” is exactly the kind of capability that needs strong sandboxing, which is why the Hyperlight micro-VM isolation is the load-bearing part of the design, not an implementation detail.

What to do now: nothing in production. But if your agents make five or more tool calls per task, put CodeAct on your evaluation list for the back half of 2026 — the token math is too good to ignore once it stabilizes.

Foundry IQ and memory scopes: the end of DIY RAG and DIY memory

Two related announcements here, and together they attack the two biggest sources of custom plumbing in agent codebases.

Foundry IQ — the knowledge and grounding layer — added a serverless SKU (public preview), took Knowledge Bases to GA with SLA-backed retrieval so you no longer hand-build indexing pipelines, and gained multi-source support spanning Work IQ, Fabric IQ, Azure SQL, File Search, and MCP sources. Web IQ (limited access) adds sub-200ms web grounding with zero data retention. The through-line is agentic retrieval: the platform handles query planning and source federation so your agent asks questions instead of orchestrating vector searches.

Agent memory in Foundry Agent Service (public preview) now has three explicit scopes:

• Session memory — context within a conversation thread. Table stakes.
• User memory — preferences and facts that persist across sessions.
• Procedural memory — the new one, and the one to watch: agents learn how to accomplish tasks across runs. Microsoft reports 7–14% absolute success-rate gains at near-baseline cost in early results. An agent that gets measurably better at your workflows without retraining or prompt edits is a genuinely new capability, not a convenience.

Why it matters: most “agent memory” in production today is a vector store, a summarizer, and hope. Explicit, platform-managed scopes with different lifetimes is the right abstraction, and procedural memory in particular has no easy DIY equivalent.

What to do now: read Foundry IQ and agent memory for .NET developers for the full breakdown, then audit what your current agents re-learn on every single run — those are your procedural memory candidates. If you maintain a custom RAG pipeline mainly out of inertia, price it against a GA Knowledge Base; the comparison may be uncomfortable.

The rest of the field, quickly

A few announcements that did not headline but will show up in your work:

• Handoff orchestration hit 1.0 GA in the Agent Framework: you declare agent topology as directed edges (CreateHandoffBuilderWith(triage).WithHandoff(triage, billing)...), and the framework injects the transfer tools. It joins the graph-based patterns covered in multi-agent orchestration with graph workflows.
• GitHub Copilot SDK integration (GA) lets you wrap a Copilot backend as a standard AIAgent in .NET (copilotClient.AsAIAgent()) — one programming model over another vendor-grade agent runtime.
• Governance got real: ASSERT, an open-source policy-driven evaluation framework, and the Agent Control Specification (ACS), an open YAML standard defining deterministic controls at five checkpoints (input, LLM, state, tool execution, output). If you work anywhere regulated, ACS is the document to read — portable, versionable, auditable control contracts are what your security review has been asking for.
• Foundry Toolkit for VS Code (GA): templates, local debugging with trace visualization, direct deploy to Foundry Agent Service.
• On the .NET side of the house: .NET 11 previews are explicitly agent-flavored — ASP.NET Core and Blazor are gaining building blocks for agents, tools, skills, and components; Aspire is now open-source and positioning itself as the “cloud and agent-ready” toolchain; and union types are finally coming to C#, which will make modeling tool results and agent states noticeably cleaner.

An opinionated closing: what to actually do this quarter

Strip away the announcement volume and a clear strategy falls out:

1. Consolidate on the Agent Framework now. With the harness production-ready, handoffs GA’d, and both Foundry and the Copilot SDK plugging into the same AIAgent abstraction, the framework is the stable center of gravity. If you are still on Semantic Kernel or a bespoke loop, the migration argument just got much stronger.
2. Delete your custom loop, adopt the harness. Context compaction, approvals, and OpenTelemetry are not your product. Stop maintaining them.
3. Pilot one hosted agent. Pick a stateful, bursty workload and run it on Foundry Agent Service against the Responses API. Measure cost at scale-to-zero honestly.
4. Extract one skill, wire one memory scope. Both are small experiments that change your architecture’s direction more than its code.
5. Watch CodeAct; read ACS. One is your future cost optimization, the other is your future compliance conversation.

The pattern across everything Microsoft shipped at BUILD 2026 is the same: the undifferentiated heavy lifting of agent development — loops, runtimes, retrieval, memory, governance — is moving into the platform. The teams that win the next twelve months are the ones that let it, and spend their engineering budget on the tools, skills, and domain logic that the platform cannot know.

Next: migrating from Semantic Kernel to get an existing codebase onto all of this.

---

Have a correction or a topic you want covered? Email mani.bc72@gmail.com.