For those of you with technical debt (all of us, amirite?), here's my guidance on what to watch out for at Build 2026, especially if you're thinking about application modernization.
For most of the developer audience, there's going to be lots of new IDE tooling and a louder GitHub Copilot drumbeat. For modernization buyers, the people responsible for VB6, PowerBuilder, WebForms, Access, and Clarion workloads that AI assistants can read but can't actually replace, Build 2026 matters for a different reason. It is the moment Microsoft's agent platform is mature enough to be evaluated on its own terms, not as a Copilot side feature.
Here are the five things worth tracking. Not all of them solve the modernization problem. The last one in particular doesn't and that's where the real opportunity sits.
The pieces have been landing quietly for six months. A2A tool support so Foundry agents can call any Agent-to-Agent endpoint with proper auth. A managed long-term memory store that survives across sessions. A cloud-hosted MCP server at mcp.ai.azure.com. Hosted-agent tracing. The April Foundry SDK release exposed the full hosted-agent lifecycle directly from code: sessions, skills, toolboxes, evaluation inputs.
What to watch at Build: whether Microsoft positions Foundry Agent Service as the default substrate for enterprise agents, the way Azure Functions became the default for serverless. If they do, every ISV in the modernization space, including us, will be asked some version of "how does your agent platform relate to Foundry?" The answer needs to be ready.
/fleetSession BRK207: "GitHub Copilot in Visual Studio: Agents That Debug, Profile, and Test" promises a deep look at both /fleet and autopilot mode, which lets GitHub Copilot CLI work autonomously.
This is the line Microsoft has been walking carefully: Copilot is still a developer assistant, but increasingly it can fly solo on narrow tasks. For modernization, the meaningful question is what counts as "narrow." Autopilot can plausibly take a failing test and fix it. Autopilot cannot take a 500K LOC VB6 application and produce a working .NET equivalent. The gap between those two statements is the entire reason fixed-price agentic modernization exists as a category.
Expect the demos to be impressive on greenfield code. Watch for what's conspicuously absent: legacy language coverage, full-application transformation, deterministic output quality across millions of lines.
Lab 532: "From data to context: Agent-ready knowledge with Foundry IQ" points at the unglamorous problem that decides whether enterprise agents work: connecting them to the right context.
This is the same problem in modernization, just with the difficulty turned up. An agent that can't read your legacy application can't modernize it. An agent that reads it incorrectly produces what we've been calling the hallucination tax: modernized code that compiles, looks plausible, and quietly breaks in production. Foundry IQ is Microsoft's bet that high-signal context is the wedge between agents that demo well and agents that ship.
If you are evaluating any agent platform for modernization, the grounding story is the single most important technical question. Build 2026 will give you Microsoft's answer for general enterprise use. The modernization-specific version of that answer, what an agent actually needs to know about a VB6 codebase to translate it correctly, is a much harder problem, and not one the Foundry IQ session will address.
The agentic story has moved past "one big agent does everything." The interesting work now is in coordination and how multiple specialized agents hand off, share state, and recover from each other's failures. A2A under the Linux Foundation, now natively supported in Google ADK, Microsoft Semantic Kernel, LlamaIndex, and CrewAI, is the protocol layer for that.
Build sessions will showcase orchestration patterns. The pattern that matters for modernization is not abstract: it is the discovery agent that reads the legacy code, the architect agent that designs the target, the translation agent that produces the new code, and the quality agent that verifies it. Anyone building serious agentic modernization is already running some version of this. Build 2026 is the moment that vocabulary becomes mainstream which is good news for buyers, because it makes single-agent code assistant easier to recognize as the wrong tool for the job.
The most honest theme running through the Build 2026 startup guidance is also the most boring one: how do you run AI in production without going bankrupt. Observability. Token tracking. Model routing. Cost dashboards.
This is the part of the story that maps directly onto why fixed-price modernization is having a moment. Token-based pricing is fine when an agent helps a developer write a function. It is a financial planning nightmare when an agent is responsible for translating 1.2 million lines of code. Buyers responsible for modernization budgets are not interested in a variable-cost model where the bill is determined by how many times the agent retries.
Watch for Microsoft's positioning here. They will talk about cost optimization tools. They will not (because they can't) offer a fixed-price commitment on the output of a Copilot-style assistant. That ceiling is exactly where outcome-priced agentic modernization platforms live.
Build 2026 will make agentic AI feel inevitable. That's the right read. What it won't do is solve the 70% wall, the structural reason general-purpose AI coding assistants stall on legacy modernization somewhere between "we got it to compile" and "we got it to production." Closing that gap requires agents purpose-built for the messy reality of decades-old codebases: language coverage that includes the platforms enterprises actually still run, deterministic quality checks, and a delivery model that prices the outcome instead of the tokens.
Three things to do before June 2:
We'll be watching live and publishing a post-Build read on June 4; specifically the parts of the agent story that change what's possible in modernization.