Vision lead-off: the system around AI is the differentiator

Jay Parikh’s post, AI alone won’t change your business. The system running it will., set the tone for the entire event. The core message? AI models alone aren’t enough. You need the whole system around them:

• Build in GitHub
• Contextualize with Microsoft IQ
• Run in Microsoft Foundry
• Govern with Agent 365 and Microsoft Security
• Improve continuously with evals, traces, and optimization loops
• Surface where people work, including Teams and Microsoft 365

If you only read one post to understand the strategy direction coming out of Build, start here. To explore by area, bookmark these official hubs:

• Your home for Microsoft Build
• Microsoft Build 2026 news hub
• Microsoft Build 2026 next steps

More top developer content from Build news

The Build 2026 news page is a goldmine for cross-product announcements. Here are some highlights worth bookmarking:

• Furthering Windows as the trusted platform for development
• Building a hill-climbing machine: Launching seven new MAI Models
• Microsoft Foundry updates help deploy and run AI agents effectively
• Azure HorizonDB: Enterprise-ready Postgres, engineered for the AI era
• Build 2026: Securing code, agents and models across the development lifecycle
• Work IQ: Production-ready intelligence for every agent
• Announcing Microsoft Web IQ: a new grounding system for the agentic web, powering web-scale retrieval for agents.
• Rayfin delivers enterprise-grade app backends: managed backends from Microsoft Fabric for building production application tiers.
• Build collaborative agents where work happens

GitHub Copilot app: agent-native desktop experience

The GitHub Copilot app is a new desktop experience designed for directing multiple agents in parallel. From a single “My Work” view, you can see active sessions, issues, pull requests, and background automations across connected repositories. The app is now available in technical preview for Copilot Pro, Pro+, Business, and Enterprise users.

Key capabilities in the Copilot app:

• Parallel agent sessions run in isolated git worktrees, so agents don’t step on each other. The app handles worktree setup and cleanup automatically.
• Canvases are bidirectional work surfaces where agents update plans, diffs, browser sessions, and deployment state in real time, and developers can edit, reorder, or redirect on the same surface.
• Cloud and local sandboxes give agents a bounded environment to run code, inspect results, and iterate without touching production. Organizations define their own policies.
• Agent Merge carries pull requests through review, CI, and merge by monitoring checks, tracking reviewers, and addressing failures. You choose how far Copilot goes.
• Copilot code review now supports medium-tier review with higher-reasoning models, a /security-review skill, and native Azure DevOps support.
• Copilot SDK is now GA in Node.js/TypeScript, Python, Go, .NET, Rust, and Java, exposing the same agentic runtime that powers the app.
• Copilot CLI has a redesigned TUI, voice input (on-device, audio never leaves your machine), and /every for scheduled recurring tasks.

MAI-Code-1-Flash in GitHub Copilot

MAI-Code-1-Flash is now available for GitHub Copilot. This is Microsoft’s latest small-tier coding model, and it’s the first in a new wave of purpose-built coding models from Microsoft designed and tuned specifically for GitHub Copilot. MAI-Code-1-Flash delivers best-in-class quality for its size, outperforming other small models in early testing, making it well-suited for lightweight coding workflows.

MAI-Code-1-Flash is rolling out to Copilot Free, Student, Pro, Pro+, and Max plans, starting with a limited set of users and expanding gradually. You can select it from the model picker in Visual Studio Code. To learn more, see the MAI-Code-1-Flash model page.

Windows developer announcements and releases

The Windows team brought the goods this year! Their major Build roundup, Build 2026: Furthering Windows as the trusted platform for development, is all about reducing setup friction while improving security and local AI performance.

Key releases and roadmap callouts:

• Coreutils for Windows is now generally available, bringing Linux-like command-line utilities that run natively on Windows.
• Windows Development Skills is now generally available, providing structured skills for agentic native app development using WinUI 3 and WinApp CLI.
• WinUI and WinApp CLI guidance is being operationalized through those Windows Development Skills so agents can build native Windows apps end-to-end more efficiently.
• Windows Developer Configurations is now generally available, powered by WinGet for one-command setup of a developer-ready Windows 11 environment.
• WSL containers were announced as coming to public preview, with built-in CLI and API support for Linux container workflows on Windows.
• Intelligent Terminal was announced in experimental preview to add context-aware agent support directly in terminal workflows.

Building desktop apps, local AI tools, or enterprise-managed developer environments? This post should be near the top of your reading list.

OpenClaw + Scout: always-on agents, from open source to enterprise

One of the biggest crowd moments at Build was OpenClaw running natively on Windows. OpenClaw is an open-source, self-hosted AI agent framework created by Peter Steinberger that can execute multi-step workflows, control apps, browse the web, and manage files autonomously. Scott Hanselman and Steinberger demoed it live on the keynote stage.

On Windows, OpenClaw runs securely inside Microsoft Execution Containers (MXC), a new policy-driven containment layer that enforces what agents can access at runtime. The new Windows companion app makes setup straightforward: install, connect your claws, and you’re running. Microsoft also showed cloud-based ephemeral sandboxes for OpenClaw with managed identity, full isolation from your local machine, and rebuild times around six minutes.

On the enterprise side, Microsoft launched Scout, an always-on personal agent built on OpenClaw’s architecture and integrated with Microsoft 365. Scout brings persistent identity, proactive task management across email, calendar, and reports, and enterprise policy conformance through Agent 365.

Developers who already use agents for coding workflows will feel right at home here. OpenClaw treats agents as long-running, multi-session processes rather than single-prompt responses, and the MXC sandboxing model is the same one adopted by GitHub Copilot CLI for process isolation. If you’ve been looking for a way to run always-on local agents safely, this is the stack to explore.

Azure developer announcements and releases

Azure had a huge week. For the full firehose, check the Azure Blog developers archive (June 1-5, 2026).

Here are the top Azure posts you’ll want to read:

• Announcing Microsoft Discovery general availability and Microsoft Discovery app preview: announces Microsoft Discovery GA and app preview for building and governing agentic AI workflows.
• Microsoft Build 2026: Building agentic apps with Microsoft Fabric and Microsoft Databases: details the data + AI platform direction for scalable agentic application development.
• New Azure Cobalt 200 VMs deliver 50% performance improvement, fully optimized for modern agentic AI workloads: introduces early access preview of Arm-based Cobalt 200 VMs for Linux-based AI workloads.
• Foundry IQ: Build smarter agents faster with unified knowledge and serverless retrieval: covers unified knowledge and retrieval for higher-quality agent responses.
• A Developer’s Guide to Managing Models, Cost and Quality in Microsoft Foundry: focuses on model lifecycle management, governance, and optimization in production.
• Grounding at scale: Engineering the retrieval system for the agentic web: deeper engineering context for web-scale grounding and retrieval quality.
• Build and run agents at scale with Microsoft Foundry at Build 2026: practical Foundry guidance for moving from prototype to production.
• Agentic retrieval and memory toolkits now available for Azure Cosmos DB: concrete memory and retrieval tooling for agentic application patterns.

Teams building cloud-native agents should treat this Azure set as required companion reading to the broader Build recap.

Microsoft Agent Framework announcements and releases

If you’re building agents, this post is required reading: Microsoft Agent Framework at BUILD 2026: Agent Harness, Hosted Agents, CodeAct, and more.

Key releases from the Agent Framework team:

• Agent Harness made production patterns first-class, including context compaction, instruction merging, todo tracking, and extensible providers.
• Foundry Hosted Agents introduced a direct path from local development to managed production hosting with scaling, session persistence, and built-in observability.
• CodeAct support (via Hyperlight) was introduced to reduce orchestration overhead by collapsing many tool calls into fewer model turns.
• GitHub Copilot SDK integration reached 1.0 support in Agent Framework for .NET and Python.
• Multi-agent Handoff orchestration reached 1.0 with explicit topology and guardrails.

Two open-source releases from the Command Line blog round out the agent governance picture:

• Agent Control Specification (ACS) is a portable, vendor-neutral spec for runtime agent governance. It defines eight lifecycle interception points (input, pre/post model call, pre/post tool call, output, startup, shutdown) with a declarative YAML manifest that works across Python, Node, .NET, and Rust. Write your policies once, enforce them in any framework.
• ASSERT (Adaptive Spec-driven Scoring for Evaluation and Regression Testing) turns natural-language behavior specs into executable evaluation pipelines. Describe what your agent should and shouldn’t do, and ASSERT generates stratified test cases, runs them against the agent, and scores each trace with rationale and policy citations.

For deeper dives, see Build agents you can trust: A new open trust stack for AI agents on any framework for cross-framework trust and governance, and From observability to ROI for AI agents on any framework for framework-agnostic measurement guidance.

Between the Agent Framework, ACS, and ASSERT, there’s now a clear stack for building, governing, and evaluating agents in production.

Visual Studio announcements at Build 2026

The Visual Studio team published a strong roadmap update: What’s Coming Next in Visual Studio: Our Microsoft Build 2026 Announcements.

Some of the top highlights:

• Deeper GitHub Copilot agent participation in debugging, profiling, and testing workflows.
• Pre-build checks for existing errors and warnings to reduce avoidable failed builds.
• AI-assisted merge conflict resolution to reduce manual conflict handling effort.
• Expanded modernization support, including Web Forms to Blazor paths and adding Aspire to existing apps.
• Microsoft-authored skills that can be applied automatically based on project/task context.
• BYOK/BYOM direction so teams can use local or cloud models that match performance, cost, and compliance needs.
• Continued platform unification on the GitHub Copilot SDK to accelerate feature delivery.

The focus on reliability, maintainability, and faster inner-loop feedback makes this roadmap especially relevant to large enterprise codebases.

.NET at Build 2026

The .NET team published a full session guide and it’s packed: .NET at Microsoft Build 2026: Must watch sessions. .NET 11 is built for the AI era, and these featured sessions show exactly how:

• Union types in C#: one of the most requested language features is finally landing! Union types model closed sets of data shapes for wire protocols and domain modeling.
• .NET 11 in depth: Runtime, libraries, and SDK for the AI era: performance, diagnostics, and developer productivity investments for intelligent, cloud-connected, and agent-driven apps.
• AI Building Blocks for .NET: a practical, opinionated guide to adding AI capabilities to C# apps, from model integration to agent patterns with production-ready code.
• Building for the agentic web with .NET 11: ASP.NET Core and Blazor gain new building blocks for agents, tools, skills, and components, closely integrated with Aspire.
• Taking your AI to the edge with .NET MAUI: local models and on-device AI capabilities across mobile and desktop with .NET MAUI.
• Simplifying .NET installs with dotnetup: a new cross-platform tool to manage .NET SDK and Runtime installations, making developer onboarding smoother than ever.

For the full lineup, check out the .NET at Build 2026 playlist on the .NET YouTube channel.

Start with these next steps

The Build 2026 next steps hub organizes learning and code resources by topic:

• Agents and Apps
• Cloud Platform and Data
• Developer Tools and Frameworks
• Working with Models
• Responsible AI
• Windows

It also links to skilling resources like the Build Skills Challenge, Skills Hub, Marketplace resources, MVP resources, and Build event info. Pro tip: start here if you want a structured way to follow up on everything from Build!

Watch now: Build Day 2 livestream

A full day of what’s new in GitHub Copilot and Visual Studio Code, straight from the people building it. New features, live demos, and a few surprises.

The Terminal Live: Day 1 and Day 2

The GitHub Copilot team coded live from Microsoft Build across both days. Segments covered cloud agents, code review, GitHub Copilot CLI, MCP, Visual Studio 2026, Windows Terminal, Aspire, the GitHub Copilot SDK, and Visual Studio Code agents.

Top on-demand sessions

Couldn’t watch everything live? Here are some of the top sessions you can catch on demand right now.

Why your AI code doesn’t ship: Closing the gap to production (BRK200)

Session page

Multi-agent patterns in VS Code you won’t learn from docs (BRK201)

Session page

Inside Azure innovations with Mark Russinovich (BRK226)

Session page

Agent supervision is the new senior engineering skill (BRK244)

Session page

Browse all sessions

The full Microsoft Build 2026 session playlist is available on YouTube:

Beyond code: other keynote highlights

While this post is about top developer news and releases, I can’t help but mention some power-user goodies and nerdy toys from the keynote:

• Majorana 2: Microsoft’s next-generation quantum chip based on topological qubits. Not something you’ll ship code against today, but a signal of where the compute horizon is moving.
• Project Solara: A new chip-to-cloud platform for agent-first devices, with concept reference designs for a wearable badge and a desk companion. Agents built with Microsoft 365, Copilot Studio, and the Agent Framework will be able to surface on these new form factors.
• Surface RTX Spark Dev Box: A developer-focused device with NVIDIA RTX Spark silicon, delivering 1 petaflop of AI compute and 128 GB unified memory for running models locally. Available later this year.
• Frontier Tuning: Demoed on the keynote stage as a new approach to fine-tuning frontier models within Microsoft Foundry.
• Seven new MAI models: Mustafa Suleyman unveiled seven new models across the MAI family, expanding the range of model sizes and capabilities available in the platform.

So cool! Looks like I need to start saving up for that Surface RTX Spark Dev Box…

Keep building

Build delivered a clear message for developers: this is about end-to-end systems now, not isolated AI features. The most successful teams will combine model capability with strong engineering workflows, platform fundamentals, governance, and continuous improvement.

We’re incredibly excited about everything that was announced, and we can’t wait to see what you build with it! For code samples, repos, and practical follow-up paths, start with:

• Build home
• Build 2026 news hub
• Build 2026 next steps
• Jay Parikh’s Build vision post

The post Microsoft Build 2026 recap: vision, launches, and top sessions appeared first on Microsoft for Developers.

What does that look like in practice? You give your coding agent the prompt: “create a CLI script to deploy Azure AI Foundry.” It reaches for az ml, the Azure ML extension – the right answer a year ago. It hits a Python dependency crash, spends 15 tool calls debugging import paths, and produces a script targeting a deprecated API surface. Another developer enters the same prompt with Learn MCP Server connected. The agent checks trusted up-to-date documentation first, finds az cognitiveservices (the current Foundry resource model), and delivers a working deployment script with model provisioning on the first try. Same model. The difference was whether the agent had access to current product documentation while it worked.

Agents are good at writing code, but they don’t know which API shipped last month. Language models training data has a cutoff, while technology evolves continuously. As a result, agents produce code that looks correct but may target deprecated APIs – leading to dependency failures, missing capabilities, or scripts that break when the old surface is retired. You can work around this with prompt engineering: add constraints, pin versions, test the output, iterate. That works. It also means you’re doing the verification the agent should be doing for you.

The real world test

We gave a coding agent a simple task: generate a bash script to deploy a Foundry instance. The agent chose the az ml extension, which uses az ml workspace create --kind hub to create Foundry resources. This was the documented approach until recently. When the extension failed to load (a Python dependency conflict with rpds-py), the agent started debugging: reinstalling pip packages, testing Python import paths, checking system vs. CLI Python versions, inspecting .so files. Fifteen tool calls later, the extension loaded, and the script ran – but it targeted the old hub-and-project model through the ML workspace API.

Then we used the same prompt, same model, but with Microsoft Learn MCP Server connected. The agent queried Microsoft Learn for current Foundry deployment guidance, found the quickstart documentation, and used az cognitiveservices – the current API surface for Foundry resources. No extension to install. No dependency issues. The script created an AIServices resource, a project, and deployed a model with version pinning, SKU configuration, and capacity settings. It had interactive prompts, idempotency checks, and connection info output. The agent didn’t need to be told which API to use. It read the docs. The result: working code on the first try, no manual correction, and fewer steps from prompt to production.

What is Learn MCP Server

Learn MCP Server gives agents direct access to Microsoft Learn documentation, code samples, and guidance through the Model Context Protocol (MCP). Instead of relying on training data that’s months or years old, agents can search and retrieve current, official content as part of their reasoning.

It works with any MCP-compatible client: GitHub Copilot CLI, Visual Studio Code, Visual Studio, and others like Claude Code. The server is remote (https://learn.microsoft.com/api/mcp, which MCP clients understand) – nothing to install or host. No authentication required. You can even use Learn MCP Server in agent you build in Foundry or Copilot Studio.

When a Microsoft technology is in scope – deploying an Azure service, migrating a .NET application, configuring a Bicep template – the agent can query Learn for current guidance and reason over it alongside your codebase. That means fewer outdated patterns, fewer manual verification loops, and docs showing up where the decisions happen instead of in a separate browser tab.

Set it up

GitHub Copilot CLI:

/plugin install microsoftdocs/mcp 
/restart

VS Code: Open the extensions pane, search for “@agentPlugins microsoft-docs” and select Install.

Try it

Connect the tools you already use to Learn MCP Server and try it on your next task that touches a Microsoft product or service. The quickest way to see the difference is to ask your agent something that changed recently – a new API, a renamed service, a deprecated flag – and see whether it gets it right on the first try.

Connect with us in the Learn MCP Server repository for additional configurations and more information.

The post Improve your agentic developer tools by grounding in Microsoft Learn appeared first on Microsoft for Developers.

In the previous article, we introduced the AX stack: model, harness, and agent extensions. We talked about what’s fixed and what you can influence. This time, let’s trace through what actually happens, step by step, when an agent encounters your technology. Because until you see the mechanics, you can’t fix what’s breaking.

What happens when a developer says “build me something”

A developer opens their coding agent, types a prompt: “Build me a REST API with authentication using Contoso Identity.” Here’s what happens next.

Step 1: The harness assembles context

Before anything hits the model, the harness (Copilot, Claude Code, Cursor) assembles the context window. The VS Code team recently published a deep dive into how their harness works, covering context assembly, tool exposure, and the agent loop. The harness pulls together:

• the system prompt (harness-specific, you can’t see or change it)
• environment details: the developer’s OS, the full path to the working directory
• workspace files the harness thinks are relevant
• tool descriptions from installed extensions (MCP servers, skills, custom agents)
• conversation history
• any instruction files (.github/copilot-instructions.md, AGENTS.md, etc.)
• the developer’s prompt

This is just an example, because every harness is different. Nonetheless, if you consider the context window size of any of the popular LLMs used for coding, you can start to see how such a setup quickly fills up the available tokens. The harness decides what makes the cut. If the developer has 20 extensions installed, the harness might summarize tool descriptions, drop some entirely, or rank them by estimated relevance. Your extension’s description is competing for space before the model even sees it. If it exceeds the harness’s length limit (each harness sets its own), it gets ignored entirely, no matter how relevant it is. And details you’d never think about, like the OS, or the directory path, influence the model’s decisions. It’ll generate platform-specific code, assume different toolchains, even pick different default configurations based on what it sees here.

Step 2: The model reads the room

The model receives this assembled context and does something humans don’t: it reads everything at once. The system prompt, the tool descriptions, the workspace context, the developer’s prompt. It builds a mental model of what’s available and what the developer asked for.

Here’s where training data matters. If the model has seen your technology during pre-training, it already has opinions. It knows (or thinks it knows) your API patterns, your SDK conventions, your common error messages. If it hasn’t seen your technology, it has nothing, and it’ll either ask for help or guess based on similar technologies. Either way, the model’s job at this point is to decide what to do first: does it have enough information to start coding, or does it need to call a tool?

It turns out, that this decision is a combination of the behavior encoded in the model and the instructions the harness adds on top. Some agents are more inclined to call tools straight away, while others rely on their own knowledge and only use tools when the user asks them to. Some agents tend to search for the latest information on the internet first, while others prioritize efficiency and start working on the task if they feel they know enough. So even if you ship a great extension, one agent might call it proactively while another never touches it unless the developer explicitly asks.

Step 3: Tool selection (or not)

If the model decides it needs more information, it looks at the available tools and skills. This is where your MCP server’s tool descriptions and skill definitions matter. The model reads each description and decides: does this help with what the developer asked? Notice, that this decision is based on semantic matching, not keyword search. The model is interpreting intent. If the developer said “authentication” and your tool is described as “configure identity provider settings,” the model has to bridge that gap.

And even when your description matches the intent perfectly, the model might still skip it. If the task looks simple enough, or if the model feels confident it already knows the answer, it won’t bother calling your tool. It’ll just go with what it has. This is especially painful when the model has some training data for your technology but it’s outdated: high confidence, stale information.

If the model doesn’t select any tool or skill, it proceeds with whatever it already knows: it’ll use pre-training data. It’ll use whatever version of your SDK the model learned from, however many months ago that training cut-off was. If your API changed since then, the generated code is wrong and neither the developer nor the agent knows it.

Step 4: Tool invocation

Say, the model selected your tool. Now it needs to call it correctly. It constructs the parameters based on the tool’s schema and the developer’s intent. But the model might map the developer’s intent to the wrong parameters, or invent values that don’t match the schema.

If multiple tools match the intent, the model might call either one or both. And it’s not just about competition for relevance. Say there are two MCP tools from different servers that can provide more information. One is invokable directly, the other uses subrouting: a parent tool that returns information about subtools that actually hold the answer. This is a common technique in larger MCP servers to lower the number of tools exposed to the LLM and optimize token usage. If in the first turn one tool returns the actual information while the other returns routing instructions for the subtool, the model might decide it knows enough and never invoke the subtool, failing the routing entirely. This is why testing tools in isolation isn’t enough, and you need to test them in the combinations developers actually use.

Your MCP server receives the call, processes it, and returns content. What you return matters a lot. Return too much content and the model ignores parts of it or gets confused. Return too little, and the model fills gaps with assumptions. Format the content in a confusing way, and the model misparses it. Provide wrong information and you can derail the agent from the original task entirely. We’ve seen extensions cause agents to upgrade a project to a different framework version than what the developer asked for, or switch to a different programming language mid-task. And all of it goes back into the context window, consuming tokens. If you return 3,000 tokens of documentation when 200 would do, you just pushed other relevant context out of the window. That’s drag.

Step 5: The model processes the response

The model takes your tool’s response and integrates it with everything else in context. It now has the developer’s intent, workspace context, and your tool’s output, and it decides whether to generate code, call another tool, or ask the developer a question. If your tool returned clear, specific content (a code sample, a schema, step-by-step instructions), the model can proceed. If your tool returned a wall of reference documentation, the model has to extract what’s relevant, and its extraction might miss the critical detail.

How would you know? You wouldn’t. The tool got called, it returned content, everything looks fine from the outside. But the model latched onto the wrong paragraph and generated code that uses an internal-only endpoint. That’s the worst kind of quality failure: invisible until someone runs the code.

Step 6: Code generation

Next, the model generates code. This is where everything upstream either pays off or falls apart. If discovery worked, the model found your extension. If selection worked, it called the right tool for the task. If the tool response was good, the model has accurate, current information, and the generated code uses the right SDK version, the right patterns, the right authentication flow.

If any step failed, the model falls back to its training data. It might use an older API version, pick a competing SDK, or invent an endpoint that doesn’t exist. The developer sees working-looking code that fails at runtime, and blames the agent.

Many agents integrate with language servers (LSPs) and respond to problems reported in real time, adjusting code as it’s generated rather than waiting until the end. In VS Code, the agent also monitors the Problems panel where any active extension can surface diagnostics: type errors, lint violations, deprecation warnings. If your technology contributes to that feedback (through a VS Code extension, a language server, or a linter), you’re influencing the agent’s output during generation, not just after. That’s another surface you control.

Step 7: Iteration

The agent doesn’t stop at first generation. If the harness supports it (and most do), the agent builds the code, runs tests, observes errors, and tries again. Your technology surface matters here too. If your CLI produces clear error messages, the agent can quickly and efficiently self-correct. If your build tooling or test runner returns helpful output with specific codes and suggestions, the agent fixes the problem. If your errors are cryptic (“Error: operation failed”), the agent is flying blind and might iterate in the wrong direction for 10 turns before giving up.

This is a part of AX that people overlook. Your error messages aren’t just for human developers anymore. They’re for agents, and agents have no intuition to fall back on. They take your error message literally.

The information cascade

Notice the dependency chain:

1. Context assembly → determines what the model can see
2. Model interpretation → determines what the model thinks is available
3. Tool selection → determines whether the model uses your extension
4. Tool invocation → determines what information the model gets
5. Response processing → determines how the model uses that information
6. Code generation → determines what the developer actually receives
7. Iteration → determines whether the agent can self-correct

A failure at step 1 cascades through everything. If the harness drops your tool description, steps 3-7 never happen. Your tool might as well not exist. If step 3 fails (the model sees your tool but doesn’t connect it to the task), it’s the same result. If step 4 succeeds but the response is confusing, step 6 produces broken code.

This is why measuring only “was my tool called?” tells you almost nothing. Your tool can be called correctly and still produce drag if the response quality is poor. Your tool can never be called despite being installed, which means your discovery is broken. And between those two extremes? A dozen ways each step can silently degrade the next.

Summary

Most AX failures are invisible. They happen upstream, silently, and you never see them. You can’t diagnose them by looking at outputs alone: you need to know which step failed, because each one has a different fix. In the next article, we’ll cover how to measure whether your AX work is creating lift or drag at each step.

The post How AI coding agents actually use your technology appeared first on Microsoft for Developers.

The stack between a developer’s prompt and the generated code has layers. Some of those layers are fixed: you can’t change them no matter what you do. But there’s one layer where you have all the leverage. And if you don’t know which is which, you’ll waste time optimizing the wrong thing without seeing any results.

This is the first article in a series about Agent Experience (AX): the practice of making AI coding agents work correctly with your technology. The series covers what you can and can’t control in the agent stack, how to measure whether your extensions are helping or hurting, and how to iterate toward better outcomes.

The stack

When a developer asks an AI coding agent to build something with your technology, here’s what actually happens: the developer sends an instruction to the agent. The agent sends it to the LLM along with information about the workspace and available tools (MCP, skills, etc.). The LLM processes the instruction and responds with instructions to the agent about which tools to call. This repeats until the LLM considers its job done or needs more information from you.

Developer prompt
  → Agent (harness)
    → Model
      → Agent extensions (skills, MCP servers, instructions, custom agents)
        → Your technology surface (CLI, SDK, API)
          → Generated code

Three layers matter for this conversation: the model, the harness, and the agent extensions. Each has a different owner, different constraints, and a different relationship to you.

The model

The model is a fixed constraint: you didn’t train it, you can’t retrain it, and you can’t control what’s in its weights.

If the model learned your API from outdated docs, it’ll generate code using deprecated patterns. If it never saw your technology during training, it’ll hallucinate something plausible and wrong. And if there’s a competing technology that has more training data, the model will default to it even when yours is the right fit.

You can’t fix this directly. What you can do is provide information at inference time that overrides or supplements what the model knows. That’s what agent extensions are for. But you need to understand: the model is the foundation, and its biases are the default behavior. Everything you build on top is fighting or reinforcing those defaults.

The harness

The harness is the agent itself: Copilot, Claude Code CLI, Cursor, Windsurf, whatever the developer is using. It controls the system prompt, the tool-calling protocol, and how the context gets assembled. It decides what gets included in the context window, what gets dropped, and what the agent does next.

You don’t control the harness either. You might build an extension that works perfectly in Copilot and breaks in Claude Code CLI because the two harnesses handle tool descriptions differently. The harness decides how the agent consumes your extensions, and that decision is opaque to you. As a result, the same MCP server, with the same tool descriptions, can produce completely different results across harnesses. The harnesses interpret and invoke them differently. Your extension isn’t running in a vacuum. It’s running inside someone else’s orchestration layer.

So when developers are telling that some model is better than another, they’re telling only half of the story. The same model will work differently in different harnesses, and you should consider them both when evaluating performance.

Agent extensions

Agent extensions are the surface you control. They’re everything you can put in front of the agent to shape its behavior: skills, MCP servers, instruction files, and custom agents. If you own a technology, you ship these to help agents use it correctly. If you’re a developer, you configure them in your workspace to get better results.

Agent extensions teach the model about your technology, correct its misconceptions, and steer it away from competing approaches. They’re how you get the model to do what you want instead of what it defaults to. They’re also how you inject up-to-date information that the model might not have learned during training. But agent extensions don’t exist in isolation: they compete.

The zero-sum context window

Every agent has a finite context window. Your MCP server’s tool descriptions, your instruction files, your skill definitions. They all consume tokens. And so do everyone else’s.

When a developer has 15 extensions installed and asks the agent to do something, the harness has to decide which tools to invoke, which context to include, and what to drop. Your tool description might get summarized, truncated, or ignored entirely because something else claimed the space first.

We’ve seen this in evaluations repeatedly. An extension with high discovery, correct invocations, and good outcomes in isolation degrades when other extensions are present. More extensions don’t mean better outcomes. Sometimes they mean worse outcomes.

Why would that happen? Because extensions fight for the same context window. Your tool description says “use this for database operations.” Another extension’s tool description says “use this for database operations.” The model has to pick, and its choice depends on factors you don’t control: the order things appear in context, how the harness ranks tools, what the model’s training says about each option. That’s the composition problem, and nobody has a good answer for it yet.

The three failure modes

After hundreds of agent sessions across different products and configurations, we keep seeing three ways extensions fail.

Discovery failure

Your extension exists, but the agent never sees it. The developer has too many extensions installed, and yours gets dropped before it reaches the context window. Or the harness doesn’t load it at all because of how extensions are registered or prioritized. The tool is invisible: the model can’t use what it can’t see. It’s a packaging and distribution problem. Your extension needs to be installed, registered, and small enough to survive context limits.

Selection failure

Your extension is in context, but the agent doesn’t connect it to the developer’s intent. The developer says “set up authentication”, while your tool is called configure-identity-provider, and the model never makes the connection, or your description is optimized for specific keywords that the developer doesn’t know or use.

Of the three, this one shows up the most – and it’s the most fixable. It comes down to vocabulary that you use to describe your tool vs. how developers (and models) think about the problem. Fix the description and you’ll fix the selection.

Quality failure

The agent discovers, selects, and invokes your extension, but the content the extension provides hurts more than it helps. The MCP server returns a wall of text that the model either ignores or misinterprets. The skill provides instructions that conflict with what the model already knows. The content returned is accurate but so verbose that it pushes other useful context out of the window.

This one’s subtler than the other two. The extension is working – it’s being called, it’s returning content, but the outcome is worse than if the extension didn’t exist at all. That’s drag. And you won’t know it’s happening unless you measure.

This also shows, that when testing in AX, you can’t just verify that the agent is calling your extension. You have to verify that the content it returns is improving outcomes. Otherwise, you might be optimizing for the wrong thing.

What you’re actually optimizing

When you’re working on AX, changing agent extensions gives you instant results, everything else is fixed. You can improve your public docs and hope future model training picks them up, but that’s a long-term bet with no guaranteed payoff. You can’t change how the harness orchestrates. What you can change though right now is your agent extensions, and there are four things to get right:

1. Does the agent discover your extensions? If it doesn’t see them, nothing else matters. This is especially important when testing your extension in combination with other popular extensions relevant to your audience.
2. Does the agent select your extensions for the task? If it sees them but never connects them to the developer’s intent, they’re dead weight.
3. When it uses them, do outcomes improve? If outcomes don’t improve or get worse, your extension is drag, not lift.
4. Do your extensions compose well with others? If your extension works in isolation but breaks when other extensions are present, you have a composition problem.

Every AX improvement you make maps to one of these four things: discovery, selection, quality, composition.

Lift and drag

Every AX conversation frames the question of lift vs. drag. Are your extensions creating lift by improving outcomes, or are they creating drag by making things worse?

Lift

You add your extension, and outcomes improve. The agent discovers your tool, uses it correctly, and the generated code actually works – right SDK, right patterns, up to date. That’s what you’re building extensions for.

Drag

Drag is the opposite of lift. Your extension is present, but outcomes are the same or worse. Maybe the agent never discovers it: zero lift, but at least no harm. Maybe it’s discovered but the content confuses the model. Maybe it works fine alone but conflicts with other extensions. The worst part? You usually don’t know it’s happening.

The only way to tell the difference is to measure. Run the same scenario with and without your extension. Compare the outcomes: is it better with the extension? You’ve got a lift. Is it same or worse: drag. Is the outcome better but token costs tripled? Expensive lift. Whether it’s worth it or not depends on the improvement.

This is what AX measurement comes down to: controlled comparisons. A baseline without extensions versus a profile with your extensions. Everything else (the model, the harness, the developer’s prompt) stays the same.

Summary

You can’t change the model or the harness. Agent extensions are your one lever, and the only way to know if they’re helping is to measure. Run the same scenario with and without your extensions, keep everything else the same, and compare the outcomes. That’s the difference between shipping lift and shipping drag. In the following articles, we’ll talk more about what good outcomes look like, how to measure them, and how to iterate on your extensions to get more lift and less drag.

The post The AX stack: what’s fixed, where you can win appeared first on Microsoft for Developers.

I started vibe coding by writing prompts (often dictated into my phone), refining them with an agent in M365 Copilot, and creating handoff files to use with GitHub Copilot CLI. The results were predictably non-deterministic.

Prompt-driven development is a typical starting pattern: a developer opens a chat session, writes a prompt, reviews the output, adjusts, re-prompts. Maybe they get something useful. Maybe they spend an afternoon debugging emergent behavior that nobody specified and nobody tested. Then the process evolves to Spec-Driven Development: the developer creates specifications defining the “why and the “what.” They institute constraints and validation criteria, and the agent delivers more consistent code requiring less debugging.

But how do we scale this to teams of many humans and agents working in parallel? How do we persist development over large projects and codebases that exhaust most of the agent context window during initial grounding? How do we get better over time?

Several of my colleagues and I have started talking about a model we’re calling Agentic-Agile development as one methodology to address these problems.

Agentic-Agile Methodology: Wait! Hear me out!

I’m fortunate in my role at Microsoft as a Partner Tech Strategist (PTS) to work in a global team managing joint product and co-innovation with our leading Data & AI and partners. We come with a combination of engineering and product management backgrounds and spend most of our time focused on getting teams working better together across organizations. Adding agents to the development team, while ensuring continuous improvement, is proving a natural extension of our role.

The original Agile Manifesto taught us to value individuals and interactions, working software, customer collaboration, and responding to change. It was so successful that for some it became dysfunctional dogma (see The Death of Agile: Why Big Tech Is Ditching Scrum and What They Use Instead | by Ibrahim Irfan | Medium).

But Agile and Scrum were designed for maintaining team velocity while maintaining alignment in working toward rapidly shifting business goals. Today’s problems are similar but with agents, the time scale and the makeup of the team have changed. Our processes need to be flexible to evolve and maintain that alignment with agents as part of the team. That doesn’t mean we need to abandon processes.

This article is the introduction to a longer series detailing my and some colleagues’ practices that we hope will be helpful to others on the same path. I’ll often reference some of my personal projects, like Minthe which started as an attempt to build a chief of staff agent in Microsoft Foundry. Minthe has become my larger experiment in Agentic-Agile development and also has helped to bootstrap several other projects.

This isn’t a finished process, and we would really like your feedback and participation to continue to improve the framework.

• Read the full version of Toward an Agentic-Agile Manifesto
• Explore the Agentic-Agile Template | GitHub

Prompt-driven development works for small, self-contained tasks: Generate a function. Refactor a module. Write a test. These are bounded problems with clear outputs that modern AI coding agents handle well. Spec-Driven Development expands the scope of the tasks that can be delivered but it doesn’t scale over time without careful grooming and maintenance.

The breakdown happens when scope grows. A multi-module system. An integration layer with external dependencies. A feature that spans files, schemas, and behavioral contracts. At that scale, prompt-driven development produces a set of familiar failures:

• No backlog: There is no structured list of what needs to be built, in what order, with what dependencies. Work gets discovered during implementation, not planned before it.
• No concept of done: Each prompt session ends when the developer feels satisfied, not when a contract is fulfilled. “Good enough” replaces “contract satisfied.”
• No phased delivery: Everything is attempted at once. There is no staged rollout, no incremental validation, no ability to pause and redirect.
• No governance: Safety constraints, validation rules, and quality gates are bolted on after the fact, if they are added at all.

# Copilot Instructions

> This file provides GitHub Copilot with project-specific context. 

## Project Description

<!-- Replace this with a 2-3 sentence description of your project. -->
<!-- Example: "A REST API for task management built with Node.js and Express. Uses PostgreSQL for storage and JWT for authentication." -->

[Describe your project here]

## Coding Style

<!-- Define the conventions Copilot should follow when generating code. -->

- **Language:** [e.g., TypeScript, Python, Go]
- **Formatting:** [e.g., Prettier with default config, Black for Python]
- **Naming:** [e.g., camelCase for variables, PascalCase for classes]
- **Imports:** [e.g., absolute imports only, group by stdlib/third-party/local]
- **Error handling:** [e.g., always use typed errors, never swallow exceptions]

## Testing Approach

<!-- Describe how tests should be written and organized. -->

- **Framework:** [e.g., Jest, pytest, Go testing]
- **Location:** [e.g., `__tests__/` directories alongside source, `tests/` at root]
- **Naming:** [e.g., `test_<function_name>`, `describe/it` blocks]
- **Coverage expectations:** [e.g., all public functions must have tests]

## Documentation Maintenance

<!--
  Define which documents exist, and when each should be updated.
  This prevents documentation from drifting out of sync with code.
-->

| Document | Update When |
|----------|-------------|
| `README.md` | Project scope, setup, or usage changes |
| `CLAUDE.md` | Process, conventions, or structure changes |
| `STYLE.md` | Style conventions change |
| `CONTRIBUTING.md` | Contribution process changes |
| API docs | Endpoints added, modified, or removed |
| [Your doc] | [Your trigger] |

## Development Process

<!--
  Describe how work flows from idea to merged code. Agents use this to
  understand your workflow expectations: how to structure PRs, when to
  run tests, what review looks like.

  The process below is an Agentic-Agile template. Adapt it to your team.
-->

### Workflow

```
Plan → Issue → Implement → Review → Merge → Docs
```

| Phase | Description |
|-------|-------------|
| **Plan** | Define what to build. Identify scope, dependencies, and file ownership. |
| **Issue** | Create a GitHub Issue with structured scope, acceptance criteria, and negative constraints. |
| **Implement** | Build the feature in a feature branch. Follow coding conventions. Write tests. |
| **Review** | Submit a PR. Every PR receives review that checks correctness, test coverage, and convention compliance. |
| **Merge** | Merge to the integration branch after review approval. |
| **Docs** | Update documentation affected by the change. Close the issue. |

Most teams treat AI agents as tools to be configured: pick a model, write a prompt, tune the parameters, receive product. Agentic-Agile treats agents as contributors to the team. Every action an agent takes is a development action, with the same downstream consequences as a human commit.

Agents create files, introduce dependencies, write tests. They can also enrich human prompts and specs and create issues in backlog. As you become more comfortable, give the agents the autonomy to research, make architectural decisions, and document these in ADR docs and updates to issues. However, if agents are doing development work, you need to agree with them on development process.

The same engineering discipline that prevents human teams from shipping broken software applies to human-agent teams: structured planning, clear acceptance criteria, incremental delivery, and review gates. A team that would never ship a human-authored module without code review should not ship agent-authored modules without equivalent scrutiny.

---
name: Agentic Story
about: A structured story for human-agent development
title: ''
labels: ''
assignees: ''
---

## Summary

<!-- What does this story deliver? One sentence describing the outcome. -->

## Context / Motivation

<!-- Why is this work needed? What problem does it solve or what capability does it enable? -->

## Scope

### Files to Create or Modify

<!-- Explicit list of files this story will touch. This prevents overlap with parallel stories. -->

- `path/to/file1.ext` — description of changes
- `path/to/file2.ext` — description of changes

### Interfaces to Implement

<!-- APIs, contracts, or integration points this story must satisfy. -->

- 

### Invariants to Preserve
ds
<!-- Existing behavior, contracts, or constraints that must NOT be broken. -->

- 

## Acceptance Criteria

<!-- Specific, testable conditions that must be true when this story is complete. -->

- [ ] Criterion 1
- [ ] Criterion 2
- [ ] Criterion 3

## Negative Constraints

<!-- What this story explicitly does NOT do. Prevents scope creep and clarifies boundaries. -->

- Does NOT modify ...
- Does NOT implement ...
- Does NOT change the behavior of ...

## Dependencies

<!-- Other issues or stories that must be completed before this one can start. -->

- Depends on #
- Blocked by #

## File Ownership

<!-- Explicit list of files this story owns exclusively during its wave. No other story in the same wave should touch these files. -->

| File | Owner (this story) | Notes |
|------|-------------------|-------|
| `path/to/file.ext` |  | |

The underlying idea is not new. It is the foundational insight of Agile, applied to a new collaboration model. What Agile recognized for human teams, Agentic-Agile Development recognizes for human-agent partnerships: iteration, contracts, and reflection prevent the same class of failures.

With Minthe I authored specifications docs from prompts before any implementation code was written. After the first few iterations, we realized that design docs were being updated by agents and drifting from the original specs, but changing original spec docs led to more potential for drift. This introduced confusion for agents reading conflicting info, particularly in swarms.

The partnership evolved through recognizable stages: first, we designed and handed off. Then we alternated layers. Eventually, we ran multiple agents in parallel with review gates between waves.

After interrupting a few refactoring loops, we moved to using the GitHub repo issues to document new specs and features. Every capability became an issue with acceptance criteria. GitHub Copilot CLI (mostly with Claude models) easily adapted to reading and executing from issues as locked specifications during delivery. Mandating that all issue work be done in separate branches reduced collisions in parallelization. The closed issues and PR comments became historical reference points for subsequent iterations to refer to what had been done and what the intent was there, while capturing expanded requirements and specs in new issues. Parent-child, blocker relationships between issues further enhanced traceability.

What matters is how it changes the relationship between the human and the agent. This is a partnership, not a hierarchy. The human’s role is architecture and specification: a Scrum Coach who facilitates the collaboration rather than directing every action. The agent contributes implementation within constraints. Review is shared responsibility.

Shortly after this, we introduced a retrospective process where I asked an agent to review session files, git commit logs, PRs and other data to find where we could improve.

The methodology has since been applied to several, unrelated projects in different domain from the original chief of staff agent. The patterns (spec-first backlog, phased planning, agent context files) transferred without explicit reference to the original project. The methodology appears to be genuinely portable rather than project-specific. That portability is the real test: a methodology that only works on the project where it was invented is not a methodology.

A common objection: “We will add guardrails later, once we know what we are building.” In agentic development, this is backwards. Agents make decisions at execution speed. Without upfront constraints, they will make reasonable-looking choices that violate architectural invariants, introduce security gaps, or create dependencies that are expensive to unwind.

We learned this the hard way. Our CI pipeline was not Story 1. Quality issues accumulated across waves before any automated gate existed. By the time we added the pipeline, we had already built on assumptions that had never been validated. This required reopening and redeveloping the features. Along with CI gates, adding adversarial code reviews during each delivery wave and unit tests as part of acceptance criteria in each issue made a huge difference in work-product delivered.

Governance in Agentic-Agile Development is not a phase. It is a property of the backlog itself. Safety constraints are acceptance criteria on stories. Review gates sit between execution waves, not at the end of the project. Validation infrastructure, including CI/CD, linting, and automated tests, is the first story implemented, not the last.

The measurement is straightforward: if you are catching architectural violations during final review rather than during story execution, your governance is too late. Move it earlier.

We’re planning a deeper dive on this for the next installment in the series.

1. Copy the microsoft/agentic-agile-template repo on GitHub.
2. Clone your repo locally, switch to /plan mode, and ask GitHub Copilot to:
   1. read the contents of the repo for grounding and
   2. ask you clarifying questions to customize the template for your project.
3. If you don’t already have a backlog, create high-level issues for the major capabilities your product needs to deliver. Remember to create an issue describing what CI/CD tooling and gates are appropriate for your project (or ask Copilot for a suggestion)
4. Go back into /plan mode and ask the agent to work with to review the backlog and decide on which items to tackle first.
5. Pick that issue and ask Copilot to improve the description to conform to the ‘agentic-agile-template’.
6. When you feel comfortable with the issue description, ask Copilot to implement it and see what happens.
7. Keep working the process: every ambiguous capability becomes an issue. Every issue gets acceptance criteria. Every acceptance criterion becomes a contract that guides agent execution.

Comment here and let us know how it went.

• The Agentic-Agile Manifesto: Full manifesto with all thirteen principles
• Agentic-Agile Template | GitHub: Issue templates, agent context files, and starter backlog structure
• The original Agile Manifesto
• Andrej Karpathy: Software is changing (Again) | Y Combinator YouTube

The post Agentic-Agile: Why Agent Development Needs Agile (Not Just Prompts) appeared first on Microsoft for Developers.

They didn’t.

Instead, they found a single logical partition absorbing more than 80% of traffic. After fixing the data model—without scaling the database—RU utilization dropped to 20–35%, throttling vanished, and latency normalized.

That was the real-world case study Anurag Dutt shared in his Azure Cosmos DB Conf 2026 session, From Rising RU Costs to Stable Performance. One automated integration account was generating most writes. A partition key that looked reasonable (userId) became a system-wide bottleneck. As Anurag put it plainly: increasing RU doesn’t solve design problems—it only delays them.

That lesson echoed across Cosmos Conf. From OpenAI, Vercel, and Walmart, to engineers running Aure Cosmos DB inside Microsoft products, the pattern was consistent: Azure Cosmos DB doesn’t create bad design—it reveals it quickly. Whether the topic was data modeling, query shape, AI agent memory, change feed, or migration tooling, the same story appeared again and again: scale failures are almost always design failures.

Workloads are scaling faster than roadmaps

In the Cosmos Conf keynote, Jonathan Lee from OpenAI described running “thousands of tables” on Azure Cosmos DB for products that can go from zero usage to hundreds of millions of daily users almost overnight.

Guillermo Rauch, founder and CEO of Vercel, described Vercel’s deployments collection tripling in a few months due to agent-driven app creation.

The common thread: today’s workloads don’t scale on quarterly roadmaps. They scale on whatever just shipped.

Kirill Gavrylyuk, VP of Azure Cosmos DB, framed the challenge succinctly: AI changes what databases must do. They need to store unstructured, evolving data without rigid schemas; support semantic search alongside transactional queries; and expose higher-level “skills” that coding agents can directly invoke. Those demands sit on top of a year of Azure Cosmos DB improvements surfaced throughout the conference: hierarchical partition keys, partition-level auto-failover, fleet-wide throughput management, 99.999% availability across all consistency levels, and continued hardware evolution underneath the service.

These themes showed up everywhere. We dig into them below.

Throughput is partitioned – your access patterns have to match

Throughput in Azure Cosmos DB is evenly distributed across physical partitions. That sounds simple. The implications are not.

Andrew Liu’s whiteboard session laid out the mechanics – consistent hashing, RU pooling, and how Azure Cosmos DB scales horizontally – but also explained why bad partition keys are so destructive. If you provision 40,000 RU/s and get four partitions, each has 10,000 RU/s. If most traffic hits one partition, your effective throughput is 10,000 RU/s, no matter how much you provision.

That’s why partition keys like userId fail in practice when one “user” is actually a high-volume integration account. The fix isn’t pretty, it’s intentional. Add a time or workload dimension so load spreads across partitions. The throughput you were already paying for becomes usable.

partitionKey = userId + timeBucket // e.g. "user123_2026-04"

Tural Suleymani’s Designing High-Scale Event-Driven Microservices with Azure Cosmos DB showed the same idea taken to its logical conclusion. His operational read model synthesizes partition keys around access patterns – tenant, status, and time – so dashboard queries are single-partition by construction. The key insight: partition keys don’t describe what data is, they describe how data is accessed.

Sid Anand from Walmart reinforced this from the production side, and Hasan Savran framed it from the modeling angle. The painful-to-change decisions – partition key, embed versus reference, indexing – are scaling decisions, not schema decisions.

Newer platform features make this work easier. Hierarchical partition keys remove the need to collapse composite keys into strings. Partition-level auto-failover avoids whole-account outages when a single partition fails. Combined with five nines of availability across all consistency levels, these features let teams design for access patterns without simultaneously underwriting availability risks.

For OpenAI, getting this wrong isn’t an option. Their requirement is scaling from zero to millions of QPS and from bytes to petabytes. Their solution – a multi-tenant abstraction layer in front of Azure Cosmos DB and aggressive multi-region replication – mirrors the same partition-and-replication mental model discussed throughout the conference.

Query cost isn’t abstract, it’s a multiplier

James Codella’s Querying and Indexing in Azure Cosmos DB: The Complete Guide made cost tangible. A cross-partition query fans out across every partition. A partition-filtered query hits one. A point read is a direct lookup.

The difference isn’t marginal. Typical cross-partition queries can cost hundreds of RUs. Partition-filtered queries land in the low single digits. Point reads cost about one RU. The fix is often a simple query rewrite: include the partition key or redesign the access path.

-- Fans out across every partition

SELECT * FROM orders WHERE status = 'pending'

-- Single-partition operation

SELECT * FROM orders WHERE tenantId = @tenantId AND status = 'pending'

Indexing policy matters, too. Default indexing keeps reads cheap but inflates write cost. Patrick Oguaju of UK retailer Next shared a real workload that cut Azure Cosmos DB costs by more than 60% through better partitioning, indexing, and query shape. His takeaway was blunt: the issue wasn’t scale; it was design.

Guillermo Rauch of Vercel framed this as an “economical thinking model.” Developers see RU costs per query while writing code, turning cost into a design signal rather than a surprise at billing time. That immediacy is what makes the difference between a 100 RU query and a 1 RU point read a deliberate choice.

The keynote also went deeper than most database talks by connecting RU economics to hardware. Kirill brought Steve Berg, Corporate VP at AMD, on stage to discuss the EPYC processors underlying the Azure Cosmos DB fleet. The focus wasn’t peak frequency but performance per watt per dollar – critical as CPU usage shifts toward inference, orchestration, and agentic workloads. For Azure Cosmos DB users, the implication is simple: better query design extracts more value per RU, and the cost of each RU continues to improve underneath with no application change required.

Another maturity signal across sessions: stop trying to serve every query from one container. Tural’s reference architecture uses multiple containers, one optimized for writes, others projected via change feed for different read paths. Each query is partition-aligned; cross-partition queries disappear from hot paths.

AI agents made state a first-class problem

What felt genuinely new in 2026 was how clearly AI workloads reframed database design.

Guillermo Rauch described “agent ergonomics”: platforms originally built for humans now serve agents acting at massive scale. When agents can deploy software, the number of applications explodes. The patterns that survive are those with predictable per-operation cost and scale-to-zero behavior.

The core challenge is that LLMs are stateless. Chander Dhall’s Performance-Boosting Memory Patterns showed how memory strategy directly affects cost, recall quality, and user experience, sometimes by a 20× token-cost difference.

He walked through three patterns: sliding window memory, hierarchical memory tiers, and entity graphs. The common requirement is predictable, partition-aligned access to operational and vector data. Azure Cosmos DB fits naturally here because vector embeddings and operational context live together under the same partition key.

This is also the year semantic search fully converged into the core database engine. Full-text search, vector search, hybrid retrieval, and semantic re-ranking now run in the same query engine as transactional reads. Chat history containers partitioned by session can support recent-message reads, keyword search, and semantic retrieval without crossing partitions or systems.

Farah Abdou’s The Agent Memory Fabric made the value concrete. Her team replaced a multi-system AI stack (cache, relational DB, vector DB, coordination layer) with a single Azure Cosmos DB-backed fabric, cutting costs by 73% and latency by 65%. Lino Tadros and Yohan Lasorsa filled in the implementation details around chat history, semantic caching, and hybrid RAG.

Mick Feller from Office Depot described a similar pattern in production: employee profiles and analytics stored together as agent memory, partitioned per user. Usage nearly doubled year over year, while the database scaling beneath it was uneventful. The takeaway was consistent: the database isn’t just persistence for AI – it’s the memory model.

Events over state

The most mature architectures across the conference had moved from storing mutable state to capturing immutable events and deriving state from them.

Divakar Kumar’s fraud detection system used event sourcing end to end. Transactions are events. ML inference reacts in real time. Queryable views are projections, not shared mutable state.

Eric Boyd illustrated the cost of ignoring coordination with a simple demo: two users buying the same seat simultaneously. Without deliberate concurrency control, last-write-wins silently overwrote reality. His session focused on the coordination primitives – optimistic concurrency, idempotency, distributed locks – that make event-driven systems correct instead of lucky.

Justine Cocchi’s deep dive on Change Feed showed how Azure Cosmos DB provides a built-in, ordered, partitioned event stream for every container. With continuation tokens per partition, processors scale horizontally and restart cleanly. Her demo highlighted “all versions and deletes” mode, making every change—including deletes—a first-class event.

response = container.query_items_change_feed(mode="AllVersionsAndDeletes")
continuation = container.client_connection.last_response_headers["etag"]

while True:
    response = container.query_items_change_feed(
        mode="AllVersionsAndDeletes",
        continuation=continuation,
    )
    for doc in response:
        op = doc["metadata"]["operationType"]  # create | replace | delete
        ...
    continuation = container.client_connection.last_response_headers["etag"]

Tural Suleymani extended this into a full DDD microservices architecture, using Change Feed as the domain event spine. His key pattern: a transactional outbox written in the same partition as the aggregate, which eliminates dual-write hazards without two-phase commits.

From retail inventory to AI retrieval pipelines, the same shift appeared: stop querying shared mutable state; capture events and derive what you need.

Most teams are migrating, not starting fresh

Not everyone gets to design greenfield models. Two sessions addressed migration from opposite directions.

Sandeep Nair’s From MongoDB to Azure DocumentDB focused on API-compatible migration. Applications keep speaking MongoDB’s wire protocol while moving to Azure DocumentDB, an open-source, MongoDB-compatible engine governed by the Linux Foundation. His six-step playbook covered assessment, preparation, schema refinement, offline or online migration, validation, and cutover – with practical guidance on sharding, indexing, and change-stream–based CDC.

That path is right when the schema is solid and the engine is the bottleneck.

The opposite case—when the schema itself is the problem—was tackled by Sergiy Smyrnov in RDBMS to Cosmos DB with the Cosmos DB Agent Kit. An AI agent analyzed a classic relational app, proposed a denormalized document model, selected partition keys based on access patterns, rewrote the data access layer, and migrated data. The point wasn’t automation for its own sake; it was that the hardest design decisions are exactly the ones that benefit from structured, reviewable workflows.

Different paths, same lesson: you cannot skip access-pattern design.

The discipline behind the patterns

The strongest throughline of Azure Cosmos DB Conf 2026 wasn’t any single feature or pattern. It was a discipline shared by teams working in completely different domains: treat RU metrics as engineering signals, design partition keys around real access patterns, model events as first-class, and consider the database part of the application architecture, not an afterthought.

Jonathan Lee from OpenAI summarized it simply: ship, learn, iterate. Guillermo Rauch added the business framing: modern engineers participate directly in scaling decisions.

If you want the mental model behind all of this—replica sets, hashing, RU pooling—Andrew Liu’s whiteboard session Behind the Scenes: How Azure Cosmos DB Runs Under the Hood is the closest thing to ground truth.

What made the conference compelling wasn’t individual fixes. It was watching teams arrive independently at the same discipline. And that discipline has to come before production, not after.

Keep Going

All Azure Cosmos DB Conf 2026 sessions are free and on demand:

• Watch the full playlist: aka.ms/CosmosConf26Playlist
• Browse by speaker and session: developer.azurecosmosdb.com/conf
• Complete the Azure Cosmos DB Skills Challenge (through May 8) and apply for a free DP‑420 certification voucher
• Try it locally with the Azure Cosmos DB emulator in Docker

The post Azure Cosmos DB Conf 2026 Recap: Lessons from Production appeared first on Microsoft for Developers.

LangChain.js for Beginners is 8 chapters and 70+ runnable TypeScript examples. Clone the repo, add your API key to a .env file, and start building.

Why LangChain.js?

If you already know Node.js, npm, TypeScript, and async/await, you don’t need to switch to Python to build AI apps. LangChain.js gives you components for chat models, tools, agents, retrieval, and more so you’re not wiring everything from scratch.

LangChain.js is like having a fully stocked hardware store at your disposal. Instead of fabricating every tool from raw metal, you grab what’s on the shelf and get to work.

An Agent-First Approach

Most LangChain tutorials start with document loaders and embeddings. This course gets to tools and agents early because that’s closer to how production AI systems actually work. Agents decide what to do, when to use tools, and whether they even need to search your data.

Here’s the path through the course:

Chapters 1-3 cover the foundations: your first LLM call, chat models, streaming, prompt templates, and structured outputs with Zod schemas. Standard stuff, but you need it before things get interesting.

Chapter 4 – Function Calling & Tools. This is where the AI stops chatting and starts doing things. You teach it to call your functions, and it figures out when to use them.

Chapter 5 – Agents. An LLM answers questions. An agent reasons through problems, picks tools, and executes multi-step plans. Chapter 5 walks through the ReAct pattern and how to build agents with LangChain.js.

Chapter 6 – MCP. The Model Context Protocol is becoming the standard for connecting AI to external services. You’ll build MCP servers and wire agents to them using both HTTP and stdio transports.

Chapters 7 & 8 bring in documents, embeddings, and semantic search, then combine everything into Agentic RAG. The agent decides when to search your knowledge base versus just answering from what it already knows. That’s a big step up from the “search everything every time” approach most RAG tutorials teach.

Each chapter includes:

• Conceptual explanations with real-world analogies
• Code examples you can run immediately
• Hands-on challenges to test your understanding
• Key takeaways to reinforce learning

Why Teach Agents Before RAG?

This comes up a lot. Think about it like a student taking an “open book” exam. Traditional RAG is like the student who flips through the textbook for every question, even “What is 2+2?” Agentic RAG is the smart student who answers simple questions from memory and only opens the book when they actually need to look something up.

By the time you reach Agentic RAG in Chapter 8, you already understand tools, agents, and MCP. Document retrieval becomes one more capability your agent can reach for. And because the agent already knows how to reason about tool selection, it can figure out when retrieval is actually necessary versus when it can answer directly. The result is faster responses, lower costs (fewer unnecessary embedding lookups), and a better experience overall. That beats bolting search onto a chatbot and hoping for the best.

Who This Course Is For

JavaScript/TypeScript developers who know npm install and async/await. No prior AI or machine learning experience needed. Each chapter starts with a real-world analogy to ground the concept before any code shows up. You’ll see comparisons to hardware stores, restaurant staff, USB-C adapters (for MCP), and more. From there, you get working code examples you can run immediately, hands-on challenges to test your understanding, and key takeaways at the end of each section. The goal is to learn by building, not by reading walls of theory.

You can also work through the course locally or use GitHub Codespaces for a cloud-based setup if you’d rather skip the local install entirely.

Works With Your AI Provider

The course is provider-agnostic. Examples run with GitHub Models (free, great for learning), Microsoft Foundry (production-ready), or OpenAI directly. The setup is the same in every case: update four environment variables in your .env file (AI_API_KEY, AI_ENDPOINT, AI_MODEL, AI_EMBEDDING_MODEL) and every example works without touching a single line of code.

Capstone and Bonus Samples

The course includes a capstone project you can check out. It’s an MCP-powered RAG server that exposes document search and document ingestion as MCP tools over HTTP. Multiple agents can connect to it and share a centralized knowledge base. It’s the kind of architecture you’d actually use in cases where you don’t want each agent to maintain its own copy of the data.

Beyond the 70+ course examples and capstone project, the README links to several bonus samples you can explore: a burger-ordering agent with a serverless API and MCP server, a serverless AI chat with RAG running on Azure, and a multi-agent travel planner that orchestrates specialized agents across Azure Container Apps.

Get Started

Visit github.com/microsoft/langchainjs-for-beginners to get started! Clone it, configure your API key, and run the examples. Chapters build on each other but are self-contained enough to jump around if something specific catches your eye.

New to generative AI concepts? Check out the companion course Generative AI with JavaScript first to get the fundamentals down.

Additional Courses

Additional LangChain courses are also available for Python and Java:

• LangChain for Beginners (Python)
• LangChain4j for Beginners (Java)

The post LangChain.js for Beginners: A Free Course to Build Agentic AI Apps with JavaScript appeared first on Microsoft for Developers.

However, MCP standardizes the execution surface without defining how that surface should be governed. Tool definitions are fed directly to the model, tool servers can be hosted by anyone, and there is no built-in point where policy is evaluated before a call is executed.

To address that gap, we’ve been building a runtime governance layer for MCP tool execution. This post summarizes the rationale and introduces the Agent Governance Toolkit (AGT), an open-source project aimed at adding policy enforcement around tool calls.

How MCP tool execution works – and where trust breaks down

When an MCP client connects to a tool server, it receives a list of tool definitions (names, descriptions, and parameter schemas). The model uses those descriptions to choose a tool and construct arguments. The client serializes the request, sends it to the server, and the server executes it.

What’s missing is a built-in checkpoint that can answer a simple question before execution: is this agent allowed to invoke this tool, with these arguments, at this time?

That implicit trust can be fine in a small demo, but it becomes risky once MCP tool servers are connected to systems with real access controls, compliance requirements, and sensitive data. In practice, the gap is between “the model decided to call the tool” and “the call was validated as permitted, properly scoped, and auditable.”

The MCP attack surface is real and growing

This isn’t just theoretical. The OWASP MCP Top 10 outlines common risk categories for the ecosystem, and the surface area is expanding as implementations mature. For example, the NVD entries for CVE-2025-49596 and CVE-2025-66416 describe high-severity issues in MCP-related tooling/SDKs (including a reported unauthenticated RCE in MCP Inspector and a DNS rebinding issue in the Python SDK, respectively). These are implementation bugs that require SDK patches, but they also reinforce a broader point: security work is needed at every layer, including governance.

The OWASP Agentic Top 10 describes broader agentic risk categories, and MCP can surface many of them in practice:

We ran a red-team benchmark across these risks: 60 prompts (45 adversarial and 15 valid) mapped to the OWASP Agentic Top 10. Using prompt-only safety instructions (i.e., relying on the model to follow rules) resulted in a 26.67% policy violation rate in our internal red-team evaluation (see methodology below). In other words, more than one in four adversarial scenarios succeeded. As a result, instruction-following alone shouldn’t be treated as a security boundary.

Full methodology and reproduction instructions: BENCHMARKS.md

What’s missing: a governance layer between discovery and execution

The core issue is structural: MCP handles discovery, invocation, and response handling, but it doesn’t define a control plane that can decide whether a specific tool call should be allowed before it runs.

There’s a familiar precedent here. Mature systems don’t rely on applications to “do the right thing” around sensitive resources – they enforce boundaries through centralized, deterministic checks.

For MCP tool execution, that suggests an explicit enforcement layer between the agent’s intent and the tool server’s execution. The goal is deterministic policy evaluation for every call—allow, deny, or require approval – rather than relying on guardrails the model can interpret inconsistently.

Introducing the Agent Governance Toolkit

The Agent Governance Toolkit (AGT) is an open-source runtime governance layer that sits between an MCP client and the tool servers it connects to. It evaluates each tool call against policy before execution. AGT is currently in Public Preview, and some features and APIs may change before general availability.

Figure: AGT governance pipeline — tool calls pass through definition scanning, policy evaluation, and response inspection.

AGT governs agent actions, not model outputs. It doesn’t filter what the model says — for that, see Azure AI Content Safety. AGT controls what the model is allowed to do. Here’s what it brings to MCP:

Tool definition scanning. Before an agent ever sees a tool description, AGT scans it for hidden instructions, typosquatting, and adversarial patterns. Poisoned definitions are flagged or blocked before they enter the model’s context.

Per-call policy enforcement. Declarative rules (YAML, OPA/Rego, or Cedar) are evaluated deterministically before every tool invocation. In our internal microbenchmarks (see methodology in the repo), policy evaluation added sub-millisecond overhead per call for typical rule sets. In most deployments, that overhead is small relative to an LLM round trip.

Response inspection. Tool server responses are validated against content policies before they’re returned to the agent. Poisoned outputs — adversarial instructions, data exfiltration payloads – are caught at the boundary.

Identity and trust. Agents receive cryptographic identities (Ed25519 + quantum-safe ML-DSA-65) with trust scores on a 0–1000 scale, built on SPIFFE-compatible identity. Trust decays on violations and can recover with compliant behavior. Agents are identified for every tool call.

Execution gating. A four-tier privilege ring model enforces least-privilege. Kill switches provide immediate termination for non-compliant agents.

Observability. Append-only, hash-chained audit logs record every tool call attempt, policy decision, and execution outcome. Replay debugging supports incident investigation.

AGT maps to the OWASP MCP Top 10 — 7 of 10 risks fully covered, 3 partial with roadmap items. It also maps to all 10 OWASP Agentic risk categories, supported by an automated test suite and continuous integration in the repo. AGT includes adapters and integrations for 20+ frameworks (for example: LangChain, AutoGen, CrewAI, Semantic Kernel, OpenAI Agents SDK, and Google ADK) and ships SDKs for Python, TypeScript, .NET, Rust, and Go.

An important note on scope: AGT governs individual tool calls deterministically. It does not yet correlate sequences of individually-allowed calls that may form a malicious workflow — that’s on the roadmap. The governance model also isn’t MCP-specific: it applies equally to REST APIs, function calls, inter-agent messages, or custom protocols. For a full accounting of what AGT does and doesn’t do, see Known Limitations & Design Boundaries.

What’s next

Three OWASP MCP risks remain partially covered — and they’re driving our near-term roadmap:

• MCP01 — Token Mismanagement: Expanding MCP-specific secret scanning patterns beyond the current CredentialRedactor coverage.
• MCP06 — Intent Flow Subversion: Deeper prompt-injection detection for adversarial instructions that alter agent reasoning mid-workflow.
• MCP09 — Shadow MCP Servers: Trust scoring and discovery controls for unregistered tool servers that enter the agent’s environment.

We’re exploring workflow-level policies that would evaluate tool call sequences (not just individual invocations) and intent declaration where agents would declare what they plan to do before doing it, so the policy engine can validate the plan up front. These capabilities are on our roadmap and are not yet available.

Get started:

• GitHub repo — MIT licensed, Public Preview
• Quick Start guide — zero to governed agents in 10 minutes
• Architecture and threat model
• Open an issue — feedback and questions welcome

The Agent Governance Toolkit is in Public Preview. Features and APIs may change before general availability. The information in this post is current as of April 2026.

The post Securing MCP: A Control Plane for Agent Tool Execution appeared first on Microsoft for Developers.

That is why we created the PostgreSQL Like a Pro video series. It provides practical guidance and real-world demos that help you take advantage of PostgreSQL on Azure, supercharged by AMD technologies, while using the Microsoft tools and services you already rely on from local development through production.

Here’s what you’ll learn from the pros

• Building AI agents that actually work: You’ll see how to use the Model Context Protocol (MCP) to let your agents explore your database and run vector searches using natural language, all without leaving Microsoft Foundry.

• Migrating without the manual grind: Check out our new AI-assisted migration tooling in VS Code. It uses an “agentic self-correction” approach to automatically catch and fix schema or code issues when you’re moving from Oracle to Azure Database for PostgreSQL.

• Optimizing PostgreSQL performance on Azure: We’ll show you how Azure Database for PostgreSQL meets your performance and resiliency needs with fine-grained control and flexible deployment options.

• Scaling to meet the most demanding workloads: Watch how our new PostgreSQL offering, Azure HorizonDB, leverages decoupled compute and storage to enable amazing performance and scaling benefits for mission-critical apps.

What to expect

Preview the best practices, the architecture, and the results you can achieve when you pair PostgreSQL on Azure with AMD technology.

Ready to Postgres Like a Pro? Subscribe to the  YouTube channel and follow the PostgreSQL Hub for Azure Developers.

The post Take your PostgreSQL-backed apps to the next level appeared first on Microsoft for Developers.

That… did not happen.

Instead, you all showed up. In a big way.

The repo now has 175+ agents, 208+ skills, 176+ instructions, 48+ plugins, 7 agentic workflows, and 3 hooks – all contributed by the community.

What started as a curated list has become something much bigger, and we needed to match that energy. The space has evolved so quickly that some of the customizations we originally supported aren’t even a thing any longer (looking at you prompts and chat modes).

Today we’re announcing the Awesome GitHub Copilot website, a Learning Hub, and a plugin system to make all of Awesome GitHub Copilot easier to use.

The problem with a very long README

Let’s face it, it was a little bit difficult to find what you were looking for in the Awesome Copilot repo.

The repo worked great when it had a couple dozen resources. But with 600+ items? The README, scratch that, we had multiple READMEs for each customization, turned into a scroll marathon. Finding what you needed meant a lot of Ctrl+F and patience. We needed a better front door.

The new website

The Awesome GitHub Copilot website is built to be easy to navigate (with a memorable URL https://awesome-copilot.github.com!) and deployed on GitHub Pages. It wraps the repo in a proper website with search, so you can find what’s in there without scrolling one of the READMEs forever.

The big things:

• Full-text search across every resource – agents, skills, instructions, hooks, workflows, and plugins. You can narrow results by category.
• Resource pages for each category with live search, modal previews so you can see what a resource looks like before committing, and direct links back to the source. Plus one-click install into VS Code or VS Code insiders.
• The Learning Hub more on that one below!

The original Awesome Copilot repo itself hasn’t gone anywhere. If you want to still browse via the native GitHub interface, be our guest.

Of course, you still contribute any content through the repo. Once your PR has been merged, your new content will show up on the website.

The Learning Hub

It may be fair to sum up developer sentiment around AI tooling right now by saying: “whoa – everything is moving so fast all the time – I cannot keep up!”

Everybody is feeling it. Some of the resources we included when we launched Awesome Copilot back in July 2025 aren’t even things any longer. Anybody remember prompts? Yeah, it’s moving fast.

This is where we hope the Learning Hub will help out. The idea of the Learning Hub is to explain the fundamental concepts behind customizing the AI responses from GitHub Copilot.

In other words – what’s a skill and why is it important? How is a plugin different than a hook?

Then since Awesome Copilot contains ready-to-use examples of all of those – how do you tailor them exactly for your needs? Or write your own from scratch?

That’s what you’ll learn from The Learning Hub.

Plugins

Plugins are how the industry is thinking of distribution of customization files of the like Awesome Copilot contains. A plugin bundles related agents, skills, and commands into a single installable package – themed collections for specific domains like frontend development, Python, Azure cloud, or team-specific workflows.

Various IDEs or agentic runtimes like GitHub Copilot CLI support marketplaces of plugins. We’re very happy to announce that Awesome GitHub Copilot is a default plugin marketplace for both GitHub Copilot CLI and VS Code!

There are 48+ plugins in the repo today. The website has its own plugin page with search, tag filters.

And you can install any of those plugins as simply as:

copilot plugin install <plugin-name>@awesome-copilot

What else is new

A few more things worth knowing about. We menntioned above that the landscape is changing quickly and there are a couple of other new customization types that are available now:

• Agentic Workflows are natural-language GitHub Actions that run AI coding agents autonomously. There are 7 examples in the repo right now, covering things like daily issue reports, codeowner file updates, and stale repo detection.
• Hooks let you set up event-triggered automations during Copilot coding agent sessions – useful for session logging, governance auditing, and custom post-processing.

We also did a Skills migration. Consolidating the resource model from the original 8 types down to a cleaner set. Skills are now the standard unit for bundling reusable knowledge, which makes contributing (and consuming) a lot more straightforward.

Get involved

This is a community project. Everything in the repo was contributed by people who found something useful and wanted to share it.

A few ways to start:

1. Browse the website at https://awesome-copilot.github.com and find something that fits your workflow.

2. Try a plugin install one from the plugin page and see how it changes your Copilot experience.

3. Walk through the Learning Hub at https://awesome-copilot.github.com/learning-hub if you want to understand how AI response customization works end to end.

4. Contribute PRs are welcome! Check the contributing guide for details.

5. Star the repo at https://github.com/github/awesome-copilot to keep up with new additions.

Thank you

Seriously — thank you. We put up a repo and you filled it with 600+ resources. Every agent, skill, and instruction in there exists because somebody thought it was worth sharing. We’ll keep building on this.

Keep sending PRs.

The post Awesome GitHub Copilot just got a website, and a learning hub, and plugins! appeared first on Microsoft for Developers.