weekly.ai-news.cz
The AI week, distilled.
Session catalog · auto-updated

Microsoft Build 2026 — featured sessions

A developer-focused digest of Microsoft Build 2026 sessions in our wheelhouse — agents, Foundry, GitHub Copilot, data and Windows. Each card distils a session from its official slides and transcript, grouped by theme and linked to the source.

June 2–3, 2026 · Updated 2026-06-09

120 sessions in scope · 120 analysed · 107 transcripts · 51 decks · 116 recordings

← Back to Build 2026 briefing

Agents: build & govern

BRK200 Breakout From transcript

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

Mario Rodriguez, Evan Boyle

This session demos how GitHub Copilot agents can span planning, coding, review, CI/CD, and operations to help teams finish work and ship reliably. It introduces an “agent-native engineering system” framing (surfaces, runtime, automation, quality, memory, trust) and shows Copilot app workflows like canvases, cloud sandboxes, automations, Chronicle memory, and agent-driven PR merge/review/security review.

What's new
  • GitHub Copilot app positioned as an orchestrator to help finish work (triage, CI, review, merge, deploy) rather than just create parallel tasks
  • Canvases: agent-drivable UI surfaces inside the Copilot app, including custom canvases stored in a repo’s .github folder and shared with teammates
  • Canvas extensions can be installed from a gist/URL, and GitHub is launching a canvas marketplace (first-party and third-party extensions)
  • copilot --cloud: run agent tasks in the cloud using GitHub sandboxes (fast micro VMs) with isolation, statefulness, and tightly-scoped credentials
  • Chronicle: a per-user memory of sessions across Copilot surfaces, including /chronicle search and /chronicle standup
  • Agent merge: an automation that monitors a PR and iterates on conflicts/CI/review feedback until it is ready to merge
APIs & SDKs
  • GitHub Copilot app canvas extension model — Mechanism to author/install canvases that the agent can read and manipulate; extensions can be authored into a repo’s .github folder and installed from a gist/URL; buttons can send structured instructions/state to the agent.
  • Chronicle SQL API — Direct SQL access exposed to the agent to query a data store of the user’s Copilot sessions (used alongside full-text search) for continuity and summarization workflows like standup generation.
  • GitHub sandboxes — Stateful, isolated micro-VM environments used by copilot --cloud to run tasks remotely with scoped credentials.
What you can build
  • Kick off multiple isolated agent sessions from a set of GitHub issues, each attached to its own context/work tree
  • Build an internal triage dashboard (canvas) that buckets incoming issues/themes and starts new agent sessions directly from the board
  • Create a daily “morning brief” automation that summarizes critical PRs/issues and links you need to look at
  • Create a cloud automation that triggers on “issue created” to attempt reproduction, generate a failing test, label the issue, and comment repro steps
  • Use Chronicle to find prior work across devices/surfaces (e.g., locate context for a previously fixed bug) and auto-generate a standup update for the last 24 hours
  • Orchestrate multi-session, multi-model PR code review and security review, then run a “Rubber Duck” critique step before posting PR comments
Code & CLI: copilot --cloud/chronicle search/chronicle standup/review/security reviewCreate Session toolCreate Canvas skill.github folder (repo-scoped canvas/extensions)
AgentsDeveloperGitHub CopilotGitHubDeployment PipelinesGitHub Copilot CLI
Session page ▶ Watch
BRK200-R1 Breakout From transcript

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

Mario Rodriguez, Evan Boyle

The speakers demo GitHub Copilot acting as an end-to-end SDLC agent: triaging issues, implementing changes, running work in cloud sandboxes, and driving PRs through review and CI to merge. They focus on reducing production bottlenecks by adding agent-native UI surfaces (the GitHub Copilot app and extensible “canvases”), runtime isolation via sandboxes, and quality/security checks (code review + security review + cross-model critique). The session also introduces “Chronicle” as a private, personal data lake across Copilot sessions to recover context and automate standups.

What's new
  • New GitHub Copilot app focused on finishing work (issues/PRs/triage) rather than managing parallel chats
  • “Canvases” in the GitHub Copilot app: dynamically loaded, agent-capable UI extensions with bi-directional agent tools
  • Canvases/extensions can be installed from a gist or repo and shared (e.g., “share extension as gist”)
  • Copilot CLI “voice mode” (speaker says it shipped in the CLI) for dictating tasks to the agent
  • Copilot CLI supports “Copilot --cloud” using GitHub sandboxes (micro VMs) with suspend/resume continuity
  • “Chronicle”: a personal, private data lake over Copilot sessions across products/devices with SQL + full-text search, plus a “chronicle standup” report generator
  • “Agent Merge” to keep a PR moving (fix conflicts, monitor CI, respond to review feedback, merge when green/approved)
  • PR review workflow includes /review and /securityreview, plus multi-model sub-agents and “Rubber Duck” cross-model critique
APIs & SDKs
  • GitHub Copilot app canvases (extension mechanism) — Dynamically loaded UI extensions that expose tools to the agent and can call back into the app (bi-directional), used for custom workflows like triage boards, kanban boards, and log/trace visualization.
  • GitHub sandbox (Copilot CLI --cloud) — Stateful micro-VM runtime for running agent work remotely with suspend/resume; sessions can be resumed from the CLI and changes can be pulled back locally.
  • Chronicle — Private per-user session store across Copilot products/devices; agent can query via SQL and full-text search to retrieve prior work context and generate standup summaries.
  • Copilot Code Review — Agent-based PR feedback used alongside Agent Merge; demonstrated as producing comments the merge agent can respond to and incorporate.
  • Security review (powered by GitHub Advanced Security tech) — Security-focused review invoked via /securityreview in PR review mode, combined with multi-model sub-agents.
What you can build
  • Bulk-triage a backlog: select multiple issues and kick off separate agent sessions pre-loaded with issue context
  • Build a team-specific triage dashboard canvas that loads top issues into JSON and asks the agent to generate themes and populate the UI
  • Install and run a shared “agent kanban board” canvas from a gist; create cards that trigger agent work
  • Create a log/trace visualizer canvas for local app performance monitoring that updates in real time
  • Offload long-running prototype work to a remote sandbox via Copilot CLI, then resume later and pull changes down
  • Recover lost context by searching prior Copilot sessions and code edits with Chronicle (e.g., ‘tricky Rust bug last week’)
  • Automate daily focus with a local “morning brief” that aggregates issues/PRs across multiple channels
  • Auto-reproduce new bug issues in the cloud: attempt repro, generate a failing test, label the issue, and comment with steps/test
Code & CLI: github/appCopilot --cloudCopilot -- resumechronicle searchchronicle standup/diff/review/securityreviewYOLO onShare extension as gist
AgentsDeveloperGitHub CopilotGitHubDeployment PipelinesGitHub Copilot CLI
Session page ▶ Watch
BRK202 Breakout From transcript

Azure DevOps meets GitHub: the path to AI powered SDLC

Dave Burnison, Dan Hellem, Lan Kaim

This session shows how to pair GitHub (Copilot, Actions, Advanced Security) with Azure DevOps (Boards, Pipelines, Test Plans) to enable “agentic” workflows without forcing an all-at-once migration. Demos cover using the GitHub Copilot app/CLI with an Azure DevOps MCP server to query and update work items and pipelines, plus preview capabilities for migrating repos and bringing Copilot-powered reviews and security fixes into Azure DevOps.

What's new
  • Azure DevOps MCP Server available as local and remote options (public preview), with tools for work items, repos, wiki, test plans, search, and pipelines
  • Azure DevOps MCP Server adds support for Service Principals and Managed Identities (remote)
  • Enterprise Live Migrations (public preview) for low-downtime, full-fidelity migration of Azure DevOps Git repos to GitHub Enterprise Cloud with data residency
  • Copilot code reviews for Azure Repos (technical preview): no Copilot license or GitHub account required; billed to Azure subscription
  • Copilot Autofix for GitHub Advanced Security in Azure DevOps (technical preview), starting with select CodeQL alerts and planned expansion
  • Azure DevOps + GitHub integration scale: up to 2,000 repos per connection
APIs & SDKs
  • Azure DevOps MCP Server · preview — MCP tools to access Azure DevOps work items, repos, wiki, test plans, search, and pipelines from clients like GitHub Copilot (app/VS Code/CLI).
  • GitHub Copilot App · preview — Desktop app for agent-driven development; GitHub-native experience built on GitHub Copilot CLI; can connect to Azure DevOps via the Azure DevOps MCP server.
  • GitHub Copilot CLI — CLI experience that shares MCP server configuration with the GitHub Copilot app to query repo context and Azure DevOps artifacts together.
  • Enterprise Live Migrations (ELM) · preview — Migration tooling to move Azure DevOps Git repositories to GitHub Enterprise Cloud with data residency using validation, continuous sync, and scheduled cutover; CLI shown and UX screens referenced.
  • Copilot code reviews for Azure Repos · preview — Request Copilot code review on Azure Repos pull requests; implemented via a dynamic pipeline that clones/diffs and posts suggestions back to the PR; billed to Azure subscription.
  • Copilot Autofix for GitHub Advanced Security in Azure DevOps · preview — Generate fixes for supported CodeQL alerts via a dynamic pipeline that creates a PR with suggested changes; planned integration with security campaigns mentioned.
What you can build
  • Use the GitHub Copilot app connected to the Azure DevOps remote MCP server to list and inspect assigned work items (state New/Active) and jump to their links
  • Query Azure Pipelines run status and test results from Copilot via MCP without leaving the Copilot app
  • Convert Azure DevOps Wiki content into repo-based Copilot custom instructions/agents (markdown files) and use them to refine work items (e.g., acceptance criteria)
  • Assign implementation of an Azure Boards work item to a Copilot agent and review results via PRs, including security checks like CodeQL on agent-authored code
  • Turn GitHub Advanced Security security campaigns into Azure Boards Features/User Stories linked back to campaigns/alerts for backlog tracking
  • Use Copilot CLI with the same MCP configuration to ask natural-language questions spanning code + Azure Boards (e.g., work item status and related PR)
Code & CLI: https://github.com/microsoft/Build26-BRK202https://aka.ms/GitHubAzureDevOpsBuild2026https://nam.dcv.ms/VeDNq3VRhXhttps://aka.ms/adoELMhttps://aka.ms/AzureDevOpsRoadmaphttps://github.blog/changelog/2026-05-14-github-copilot-app-is-now-available-in-technical-previewhttps://docs.github.com/en/enterprise-cloud@latest/copilot/concepts/agents/coding-agent/risks-and-mitigations#unvalidated-code-can-introduce-vulnerabilitieshttps://docs.github.com/en/enterprise-cloud@latest/code-security/concepts/about-code-qualityhttps://github.github.com/gh-awhttps://github.blog/ai-and-ml/automate-repository-tasks-with-github-agentic-workflowsgh.io/mer
DeveloperGitHub Advanced SecurityGitHub CopilotGitHubAzure DevOpsDeployment Pipelines
Session page ▶ Watch
BRK203 Breakout From transcript

From CLI to PR: Automating the path to merged code

Evan Boyle, Cassidy Williams, Katie Liu

This session shows how GitHub Copilot CLI can act as an agentic partner from issue selection through implementation, PR creation, and review/CI iteration. Speakers deep-dive into CLI mechanics like model switching, skills and custom agents, plan vs autopilot modes, and parallel subagents (/review, /fleet) to drive code changes and PR workflows. They also connect the CLI to the GitHub Copilot SDK and the Copilot app, with examples spanning terminal, browser, and Office integrations.

What's new
  • Copilot CLI Voice Mode is available outside the experimental flag
  • New Copilot CLI TUI (terminal UI) is available
  • Copilot CLI can be used inside JetBrains IDEs (including agent picker support and other Copilot CLI experiences)
  • Copilot CLI /new turns the CLI into a session manager with switchable parallel sessions
  • /pr includes an auto-fix capability to resolve CI failures or Copilot Code Review feedback
  • /every enables interval-based automations within a session
APIs & SDKs
  • GitHub Copilot CLI — Terminal agent with interactive assistance, multi-file context, tool execution, lifecycle hooks, and MCP server integration; includes built-in agents (EXPLORE/TASK/GENERAL/REVIEW), skills, custom agents, and slash-command workflows like /review, /pr, /fleet, /research, /every, /new.
  • GitHub Copilot SDK — SDK built on top of Copilot CLI to integrate agentic experiences into apps (languages listed: TypeScript, Python, .NET, Go, Java, Rust).
  • GitHub Copilot App — Desktop app powered by Copilot CLI; stated to use the new Rust SDK.
What you can build
  • Run parallel, multi-model PR/code reviews via /review (including prompting to use multiple model families in parallel)
  • Create and manage multiple concurrent terminal agent sessions without tmux using /new and /sessions
  • Open and manage pull requests from the CLI with /pr, including auto-fixing CI failures and review feedback
  • Generate research reports using /research with citations and export to a gist
  • Schedule a periodic report workflow (e.g., hourly “top 10 messages to respond to”) using /every plus MCP servers
  • Define reusable team workflows using skills (.github/skills/*/SKILL.md) and custom agents (.github/agents/*.agent.md), including MCP server configuration
Code & CLI: copilot --model claude-sonnet-4.6/model gpt-5.4COPILOT_MODEL=gpt-5.3-codex~/.copilot/config.json.github/skills/{skill-name}/SKILL.md.github/agents/*.agent.mdCOPILOT_SKILLS_DIRS/review/new/pr/fleet/research/experimentalVoice Mode (hold Spacebar in demo)/rubber-duck/every/clear/sessions/shareaka.ms/CopilotCLIBestPracticesaka.ms/CopilotCLIBeginnerTutorialgithub.com/microsoft/build26-brk203github.com/features/copilot/cliEvanBoyle/build-2026-cli-live (demo repo name mentioned in transcript)
AgentsDeveloperGitHub CopilotGitHubGitHub ActionsGitHub Copilot CLI
Session page ▶ Watch
BRK205 Breakout From transcript

Aspire for agents: Transform how you build and deploy distributed apps

David Fowler, Maddy Montaquila, PJ Meyer

This session positions .NET Aspire as an open-source, code-first toolchain for composing, running, debugging, and deploying distributed apps with built-in observability and agent-friendly workflows. The speakers show how the Aspire CLI, AppHost (C# or TypeScript), integration packages, and the OpenTelemetry-powered Aspire Dashboard work together to reduce local/dev-to-prod drift and to give coding agents structured access to system topology, logs, and traces.

What's new
  • Aspire AppHost supports authoring in TypeScript as well as C# (for defining the distributed app model/topology)
  • Aspire CLI includes a new non-blocking `aspire start` command designed for coding agents (with `aspire run` as the blocking variant)
  • Aspire Dashboard is powered by OpenTelemetry and exposes its capabilities via an API so agents can access the same data/actions as humans
  • Aspire CLI is available via WinGet; Homebrew and npm distribution were stated as upcoming
  • Aspire adds agent-oriented features such as structured minimal-token CLI output, preconfigured agent skills, and MCP support out of the box via `aspire init`
  • Aspire Dashboard supports resource-scoped custom commands (e.g., seeding/clearing a database) authored from the AppHost
APIs & SDKs
  • Aspire CLI — Interactive control plane to create/run/deploy distributed apps; agent-ready commands like start/run/ps/logs and agent skills initialization.
  • Aspire AppHost (C#) — Code-first definition of distributed app resources and relationships (services, containers, endpoints, env injection) used for dev and deployment asset generation.
  • Aspire AppHost (TypeScript) — TypeScript-based AppHost option for defining the same app model/topology that would otherwise be expressed in C#.
  • Aspire Dashboard — OpenTelemetry-based dashboard for resources, logs, traces, metrics; also serves agent consumption via an exposed API and MCP server.
  • OpenTelemetry — Standardized tracing/metrics/logs pipeline used by Aspire Dashboard; shown for end-to-end traces across frontend, API, and database.
  • Aspire integration packages — Curated set of 100+ packages to wire services and platform behaviors (e.g., Postgres, Node/Vite, certs, OTel env injection) using shared primitives.
  • Foundry integration for Aspire — Uses Azure authentication present on the dev machine (e.g., Azure CLI/VS Code) to prompt for subscription/region and provision dev resources, passing references back into the app model and configuring roles.
What you can build
  • Define a full distributed app topology in a single AppHost and run it locally with consistent wiring (ports/endpoints/config) across frontend, backend, and dependencies
  • Give coding agents deterministic system context (topology + health + telemetry) and avoid fragile “readme-driven” startup steps
  • Use the dashboard as a consolidated viewer for multi-process logs and OpenTelemetry traces to debug cross-service flows
  • Add resource-scoped operational commands (e.g., seed database, clear data) that stay up to date with the repo and are invokable from the dashboard
  • Run isolated parallel worktrees for multiple agent sessions with randomized ports to prevent conflicts
  • Provision Azure-backed dev resources (example shown with Foundry) through parameter prompts instead of manual portal/.env setup, and avoid committing secrets
Code & CLI: aspire initaspire startaspire runaspire psaspire stopAspire logsAspire log searchaka.ms/aspire/build26aka.ms/aspire/build26/whats-new/blogaka.ms/aspire/build26/whats-new/docsaka.ms/aspire/build26/aspire-repoaka.ms/build26/brk205aspire.devWinGet
AzureAgentsDeveloperOSSDevToolsAgentic SDLC
Session page ▶ Watch
BRK206 Breakout From slides

Your agent, anywhere: Multi-client, multi-device with GitHub Copilot SDK

Patrick Nikoletich, Steve Sanderson

This session explains how the GitHub Copilot SDK lets you take an agent beyond a local machine and make it usable across multiple clients, devices, and cloud environments. The speakers cover the CLI/SDK foundations, deployment patterns, and what’s next, including sandboxing, multi-tenant session virtualization, and ephemeral remote environments.

What's new
  • GitHub Copilot SDK is now Generally Available
  • Copilot SDK includes a cross-platform sandbox (MXC Sandbox) in Preview for isolated agent sessions/tool calls on Windows, macOS, and Linux
  • New extensibility supports session virtualization for multi-tenant scenarios (remote sessions, virtualized filesystem and session store)
  • Remote cloud environments for on-demand ephemeral compute for agentic sessions (Preview)
  • Runtime is being rewritten in Rust with expected >10x startup and memory performance improvement
  • Preview scenario: remoting into a Windows Cloud PC via a browser plugin from macOS
APIs & SDKs
  • GitHub Copilot SDK · ga — SDK to build and embed agents with server support, extensibility (skills/tools/hooks/MCP), session management, streaming, remote sessions, and multiple deployment options.
  • MXC Sandbox · preview — Cross-platform sandboxing for agent sessions/tool calls with filesystem, network, and process isolation (Windows process container isolation, macOS sandbox profiles, Linux namespaces/cgroups).
What you can build
  • Embed a Copilot-powered agent into desktop or web apps with a simple backing architecture
  • Run agents in cloud containers with proxy isolation (secrets outside container; runtime inside)
  • Deploy agents in air-gapped clouds (e.g., government clouds without internet access)
  • Run in private VNets with Azure VNet inference for data residency control
  • Build a multi-tenant agent service using session virtualization (N tenants ≈ 1 process)
  • Use remote sessions to access the same agent across machines/clients
Code & CLI: aka.ms/CopilotSDKaka.ms/CopilotSDKGettingStartedgithub.com/github/awesome-copilotgithub.com/microsoft/build26-brk206aka.ms/CopilotSDKServerSampleGitHub Copilot CLI
APIAgentsDeveloperGitHub CopilotGitHubGitHub Copilot CLI
Session page ▶ Watch
BRK206-R1 Breakout From transcript

Your agent, anywhere: MultiClient, MultiDevice with GitHub Copilot SDK

Patrick Nikoletich, Steve Sanderson

This session shows how to build multi-session agentic apps using the GitHub Copilot SDK and then harden and deploy them beyond a single local machine. The speakers demo custom tool wiring, prompt customization, and multiple isolation models (including OS-managed sandboxing in preview and per-session virtual filesystems) and discuss remote cloud environments for portable, long-running agent sessions across clients/devices.

What's new
  • GitHub Copilot SDK is GA (1.0)
  • Rust language support is added with GA
  • OS-managed sandboxing is available in preview for Copilot SDK, built on MXC (cross-platform sandboxing for Windows/macOS/Linux)
  • SessionFS enables per-session virtual file systems for isolation and portability (e.g., syncing session state to storage and restoring it later)
  • Remote cloud environments for Copilot SDK are available in preview to run agents in ephemeral cloud sessions and reconnect from different clients
APIs & SDKs
  • GitHub Copilot SDK · ga — Embed the Copilot agent runtime in apps/services; create clients and sessions; configure prompts, tools, permissions; run multi-session orchestration.
  • Copilot SDK OS-managed sandboxing (MXC) · preview — Preview isolation model that uses OS controls to restrict agent capabilities such as filesystem access and network egress via a policy (shown as JSON).
  • SessionFS (Copilot SDK) — File-system abstraction for per-session state/files with pluggable implementations (in-memory, on-disk, or custom) to isolate sessions and enable migration/restore.
What you can build
  • Run multiple agent sessions in parallel within one runtime to process independent work items (agent orchestration)
  • Expose custom tools (functions/methods) for agents to update app state and call business backends (e.g., SQL-backed property search)
  • Constrain agents by default with an empty toolset and selectively enable built-in tools (e.g., web fetch) as needed
  • Mitigate prompt injection by enforcing OS-level sandbox policies that block filesystem writes and other operations
  • Host a multi-user server app using an 'empty preset' and only isolated built-in tools, rather than enabling full CLI defaults
  • Persist, migrate, and restore session state by syncing per-session files/directories to backend storage (e.g., blob store) and reclaiming disk when users disconnect
Code & CLI: aka.ms/CopilotSDKaka.ms/CopilotSDKGettingStartedaka.ms/CopilotSDKServerSamplegithub.com/microsoft/build26-brk206github.com/github/awesome-copilotaka.ms/build/evalsCopilot SDK server sample (search term used in session)JustBash (third-party library used for virtual Bash implementation)MCP serversCopilot CLI modeempty preset
APIAgentsDeveloperGitHub CopilotGitHubGitHub Copilot CLI
Session page ▶ Watch
BRK208 Breakout From transcript

Ensuring your code works when AI testing isn’t enough

Simon Willison

Simon Willison presents practical verification patterns for “agentic engineering”: shipping real software with coding agents without reading every line they produce. He focuses on workflows that improve confidence—active refactoring during review, prototype-driven validation, documentation checks, preview environments, sandboxing, and eliminating flaky tests—while scaling down big-team quality practices to individual developers.

What's new
  • Frames “agentic engineering” as the term for professional-grade development with coding agents (as distinct from “vibe coding”).
  • Recommends “active refactoring during review” as a more effective way to validate agent-written code than passive line-by-line review.
  • Uses agents to stress-test API designs by generating throwaway prototype features against a new API and learning from what breaks.
  • Introduces “agentic documentation”: diff against main and have an agent propose doc updates, while enforcing “no opinions, no rationales” in generated docs/comments.
  • Advocates continuous deployment to per-PR preview environments via GitHub Actions to shift verification from code reading to running real systems.
  • Pushes “zero tolerance for flaky tests,” using agents + Docker to reproduce CI-only failures (example: Python 3.14 on Linux) and isolate root causes.
APIs & SDKs
  • GitHub Actions — Used to build workflows that deploy each pull request to a fresh preview environment for hands-on verification.
  • Docker — Used by agents to reproduce CI environments locally (e.g., Linux CI failures) and debug flaky or environment-specific issues.
  • Content Security Policy (CSP) — Defense-in-depth header-based controls to reduce impact of inevitable bugs (blast radius reduction).
  • Sandboxed iframes — Browser security mechanism to run potentially untrusted JavaScript with constrained capabilities.
  • WebAssembly + WASI — Server-side sandboxing approach with constrained file/network/CPU/memory to run untrusted code; discussed as a robust containment layer.
  • Playwright — Browser automation for UI testing; highlighted as reducing flakiness via built-in waiting/retry behaviors.
What you can build
  • Review high-stakes changes by having the agent refactor code/tests during review (rename, dedupe, add comments) so the reviewer gains understanding.
  • Validate an API design by asking an agent to prototype multiple features against the API in throwaway branches and learn from friction points.
  • Prototype UI/UX or interaction patterns (e.g., paste-detection treated as file input) and later instruct an agent to port the proven prototype into the product.
  • Keep documentation trustworthy by diffing against main and having an agent identify and patch doc updates before merging.
  • Deploy every PR to a dedicated preview environment to verify behavior by running the system, not by reading generated code.
  • Harden systems by reducing blast radius with CSP, sandboxed iframes, and WebAssembly/WASI-style sandboxing, then have agents attempt sandbox escape.
Code & CLI: Codex DesktopClaude Codegit diff against mainGitHub gistPlaywrightSeleniumChrome DevTools Protocol
AgentsDeveloperGitHub CopilotGitHubApp ModOSS
Session page ▶ Watch
BRK227 Breakout From transcript

Distributed systems to AI platforms with Mark Russinovich & Ion Stoica

Mark Russinovich, Ion Stoica, Darby Kosten

Mark Russinovich and Ion Stoica discuss how classic distributed-systems fundamentals (consensus, load balancing, locality) still apply to AI serving and agentic workloads, while non-determinism, tight coupling (e.g., KV cache, MoE), and cross-layer optimization change how platforms are built and operated. They cover implications for serverless/containerized infrastructure, multi-region training, and the growing importance of security (prompt injection/jailbreak risk) and confidential computing for sensitive AI data.

What's new
  • Partnership announced between Azure and Anyscale (Ray)
APIs & SDKs
  • Azure Functions — Referenced as an example of short-lived serverless containers; used to contrast 'serverless' vs 'short-lived'.
  • GitHub Copilot CLI — Mentioned as one option in the developer experience toolbox for building agentic/coding workflows.
What you can build
  • Route LLM inference requests to preserve KV-cache locality and avoid wasted compute/bandwidth
  • Design serving systems that remain stateful to avoid expensive GPU initialization and state reloads, while handling harder fault tolerance
  • Record inputs/outputs/traces for debugging non-deterministic agentic systems by replaying execution traces
  • Decide when to use agents to synthesize a workflow vs implementing a deterministic workflow for repetitive processes
  • Apply confidential computing enclaves plus attestation to reduce the trusted computing base when processing sensitive personal or enterprise data with agents
Code & CLI: aka.ms/build/evalsApache SparkApache MesosRayvLLMKubernetesSlurmSkyPilotPyTorchTensorRT-LLMWasm sandboxesLean
Next.jsAgent 365Post Quantum Cryptography
Session page ▶ Watch
BRK240 Breakout From transcript

Build context-aware agents: From data to decisions

Amanda Silver, Marco Casalaina

This session argues that agent failures in production are more often caused by missing shared context (people/work signals, business semantics, enterprise knowledge/policies, and web grounding) than by model capability. Amanda Silver and Marco Casalaina walk through Microsoft IQ Platform (Work IQ, Fabric IQ, Foundry IQ, Web IQ) and a “refund agent” demo that uses these layers for grounding, delegation, and governed action. The talk emphasizes reuse (shared context across many agents), permission-aware access, and traceability for enterprise deployment.

What's new
  • Work IQ is generally available June 16
  • Web IQ grounding APIs are available for select Azure customers
  • Foundry IQ introduces a new serverless developer tier
  • Fabric IQ can generate ontologies from existing Power BI semantic models ("Generate Ontology")
  • Agents can use a Fabric ontology via an MCP server, and Foundry IQ can connect to a Fabric ontology as a data source
APIs & SDKs
  • Work IQ API · ga — Agent-oriented API layer for organizational intelligence with components called Chat, Context, Tools, Workspaces, and Organizational Intelligence; supports access via A2A, MCP, and REST API.
  • Microsoft Web IQ grounding APIs — Suite of grounding APIs across Web, News, Images, Video, and Browse to return structured, citation-ready context for agent grounding.
  • Foundry IQ — Enterprise knowledge/context engineering layer with agentic retrieval engine and knowledge bases; positioned as permission-aware and governed grounding for agents.
  • Fabric IQ — Business context layer built on OneLake, Power BI semantic models, and ontologies to enable agent reasoning and actions over business entities and rules.
  • Microsoft Agents SDK — Referenced in the refund agent architecture for implementation (noted with CloudAdapter + aiohttp).
  • MSAL (OBO token via MSAL) — Used for agentic user authorization in the refund agent flow (on-behalf-of token).
What you can build
  • Build an enterprise agent that retrieves M365 context (mail/Teams/calendar) and performs actions like drafting/sending email within governed permissions (Work IQ Tools)
  • Ground an agent’s responses in external real-world information with citations across web/news/images/video (Web IQ)
  • Create a reusable, permission-aware enterprise knowledge base that multiple agents can query via agentic retrieval (Foundry IQ knowledge base)
  • Let agents reason over business meaning (customers/orders/shipments) using Fabric ontologies instead of raw schemas and tables (Fabric IQ)
  • Delegate structured-data querying to a dedicated “data agent” so downstream agents don’t carry data dictionaries, example queries, and business acronyms in their prompts (context delegation)
  • Instantiate an agent template into a Teams-available agent with its own identity, inbox, and permission scope, then delegate work by forwarding emails to it (Work IQ + Teams)
Code & CLI: GitHub Copilot CLIaka.ms/microsoft-iqaka.ms/build26-BRK240aka.ms/MicrosoftIQLabaka.ms/iq/discussionsaka.ms/agentsleague/aisfaiohttpCloudAdapterApp InsightsGlobalProtect
AgentsGitHub Advanced SecurityFoundry IQMicrosoft FoundryGovernanceWork IQ
Session page ▶ Watch
BRK242 Breakout From transcript

Turn your agents into action: Connect tools, APIs, and documents

Ronak Chokshi, Joe Filcik, Maria Naggaga

This session introduces Foundry “Toolbox,” a way to bundle heterogeneous tools (APIs, MCP servers, skills, connectors, etc.) behind a single MCP-compatible endpoint with centralized auth, discovery, and governance. It also shows how the “Content Understanding” service turns messy documents (PDFs, DOCX, images, video, etc.) into structured, grounded outputs (JSON/markdown) to reduce hallucinations and improve agent workflows. Demos covered tool search to limit context/tool loading and document parsing/classify/extract pipelines with confidence scores and grounding back to source content.

What's new
  • Foundry Toolbox: reusable bundles of tools managed in Foundry, exposed through a single consistent interface
  • Tool Search inside Toolbox selects only the needed tool at runtime to reduce context-window/tool-loading overhead
  • Unified endpoint is MCP-compatible and provides one auth experience across tool types
  • Browser automation tool (built on Playwright) is available and supports scraping and form fill
  • Content Understanding is GA (speaker stated GA since six months ago) and is used by Foundry IQ and Microsoft 365 Copilot for document/PDF questions
  • Content Understanding updates coming in July: section-boundary splitting, new training process using knowledge sources, pre-built analyzers with token cost reductions, and “agentic extraction” mode
APIs & SDKs
  • Foundry Toolbox (unified MCP-compatible endpoint) — Bundle and publish tools; agents consume via a single MCP-compatible endpoint with centralized auth and observability.
  • Tool Search (within Toolbox) — Runtime selection of the best tool from a toolbox using tool metadata so only required tools are brought into context.
  • Content Understanding · ga — Parse/classify/extract pipeline that converts multimodal files into structured JSON/markdown with grounding and confidence scores.
  • Content Understanding Studio — UI to create/visualize analyzers that classify documents and extract fields using business-rule guidance.
  • Foundry IQ (Content Understanding-backed ingestion) — Knowledge-source ingestion that can use Content Understanding to extract high-fidelity structure (tables/figures) for grounding.
  • Browser automation (Playwright-based tool) — Automation capability for agents to scrape information and fill in forms.
What you can build
  • Bundle multiple integrations (e.g., Entra, SharePoint, ticketing, Teams, Blob Storage, search) into a single toolbox for reuse across agents
  • Reduce agent token/context usage by dynamically selecting only the needed tool via Tool Search
  • Expose the same toolbox endpoint to different runtimes/apps (demo showed hosted agent and an Azure Container Apps-hosted agent using the same endpoint)
  • Preprocess uploaded files with Content Understanding as a context provider to support more file types and improve answer fidelity
  • Extract structured tables and chart data from PDFs for downstream Q&A and workflow automation
  • Create document analyzers to classify inputs (e.g., “work order”) and extract fields (e.g., technician) using explicit business rules
Code & CLI: ai.azure.comaka.ms/fibeyLangGraphLangChainLogic AppsPlaywrightAzure Container AppsAzure API CenterAzure API Management
APIAgentsDeveloperMicrosoft FoundryGovernanceMCP
Session page ▶ Watch
BRK243 Breakout From transcript

Claw and agent harness in Microsoft Foundry

Glenn Condron, Amanda Foster, Shawn Henry

This session breaks down what an “agent harness” is (agent loop plus context management, tools/skills, sub-agents, memory, lifecycle hooks, and human-in-the-loop) and why these capabilities matter for long-running, tool-using agents. The speakers demoed running a claw-like Hermes agent on Foundry Hosted Agents with triggerable routines, then showed how to build custom harnesses and multi-agent workflows using Microsoft Agent Framework and finally publish agents into Microsoft 365 Copilot and Teams.

What's new
  • Foundry Hosted Agents “Routines” (preview) for triggering agents on a schedule/recurrence and letting agents create their own maintenance routines
  • Microsoft Agent Framework version 1.0 (aka.ms/agent-framework) organized around Workflows, Harness, and Agent Loop
  • Agent Harness Loop in Microsoft Agent Framework is in public preview; Auto sub-agents are in preview; Tools permission is in preview
  • Microsoft Agent Framework adds Copilot SDK integration and Claude Code SDK integration (listed as new features)
  • One-click publish from Foundry to Microsoft 365 Copilot and Teams, with Entra ID and tenant-admin governance, plus native streaming/citations/suggested actions/attachments
  • New agent type described as “Autopilot agents” that act on their own behalf and have a user account (mailbox/calendar/OneDrive)
APIs & SDKs
  • Microsoft Agent Framework · ga — SDK/library for building agents and multi-agent workflows (Python and C#) with agent loop + workflows + harnesses; connects to Foundry models/tools/hosting and other agent providers.
  • Foundry Hosted Agents — Foundry hosting environment for running agents with sandboxed execution and session-scoped file systems; shown hosting a Hermes agent backend endpoint.
  • Foundry Hosted Agents Routines · preview — Feature to trigger an agent to run based on recurrence prompts against a chosen agent+session; agents can create routines to perform self-maintenance.
  • AGUI — Open standard endpoint surface for connecting UI to agents; demo showed enabling an AGUI endpoint on top of an Agent Framework agent.
What you can build
  • Run a claw-like, long-running agent (Hermes) on Foundry Hosted Agents while keeping a local TUI client, and let it shut down on idle to control cost
  • Use session IDs to create isolated per-agent environments/file systems and recreate fresh instances from a deployed snapshot
  • Schedule self-maintenance tasks (e.g., curating/deleting stale generated skills, backing up state) using Foundry Hosted Agents routines
  • Build multi-agent systems with Microsoft Agent Framework workflows (Sequential, Handoff, Author/Critic, Magentic, or custom directed workflows) combining agents and regular code
  • Attach an agent harness to an existing Agent Framework chat client (AsAgentHarness) to get built-in tools and context compaction, then customize tools, memory stores, telemetry, and sub-agents
  • Publish Foundry agents into Microsoft 365 Copilot and Teams and choose personal scope vs org-wide distribution via admin approval
Code & CLI: aka.ms/agent-frameworkai.azure.comaka.ms/build26-brk243aka.ms/foundry/discordAsAgentHarnessCopilotKitFoundry Toolkit Agent Inspector
AgentsGitHub CopilotMicrosoft FoundryMCPOSSAgent Observability
Session page ▶ Watch
BRK247 Breakout From abstract

Scott and Mark learn how agents reshape software engineering

Mark Russinovich, Scott Hanselman, Darby Kosten

This breakout discusses how AI agents are changing day-to-day software engineering and the broader SDLC, focusing on where agents speed up development and where they fail. The speakers promise practical lessons, common failure modes, and guidance on how engineers and organizations can adapt, positioned as "real talk" rather than hype.

What you can build
  • Evaluate where AI agents can accelerate parts of the SDLC versus where human review remains essential
  • Identify likely agent failure modes in development workflows and plan mitigations
  • Adjust engineering practices and team processes to incorporate agentic tooling responsibly
  • Create organizational guidance for adopting agent-driven development without over-relying on automation
AgentsDeveloperAgentic SDLCDev Tools
Session page ▶ Watch
BRK250 Breakout From transcript

Observe and control agents across any framework with open source tools

Sarah Bird, Sandeep Atluri, Mehrnoosh Sameki, Katelyn Rothney

This session walks through an end-to-end loop for shipping safer agentic apps: identify agent risks, turn requirements into evaluations, apply enforceable controls, and observe/iterate in production. Using a banking agent example, the speakers introduce two open-source projects—ASSERT for spec-driven evaluations and Agent Control Specification (ACS) for portable policy enforcement across agent frameworks—then connect them to Microsoft Foundry for cloud evals, tracing, monitoring, and optimization.

What's new
  • Announced ASSERT (open source): Adaptive Spec-Driven Scoring for evaluations and regression testing for AI agents
  • Announced Agent Control Specification (ACS) (open source) as a portable control layer with lifecycle checkpoints (input/model/tool calls/output) and multiple policy styles (Rego rules, classifiers, LLM judges)
  • Agent Control Specification released as a module within the MIT-licensed Agent Governance Toolkit (AGT)
  • Agent Governance Toolkit repo published: github.com/microsoft/agent-governance-toolkit
  • ASSERT repo published: github.com/responsibleai/ASSERT
  • Microsoft Foundry integration story: run Foundry Evaluations on production traffic and feed results into Agent Optimizer
APIs & SDKs
  • ASSERT · announced — Open-source evaluation framework that turns natural-language requirements into a behavior taxonomy, generates stratified single- and multi-turn test sets, runs inference with full traces, and scores traces against policy with rationales/policy citations.
  • Agent Control Specification (ACS) · announced — Open standard/spec layer that defines intervention checkpoints across the agent lifecycle and returns consistent policy decisions/effects; designed to be portable across agent frameworks and policy engines.
  • Agent Governance Toolkit — MIT-licensed toolkit including ACS, an MCP Security Gateway, identity/trust, sandboxing, audit/compliance features, and an 'Agent SRE' module (circuit breakers, SLO/error budgets, canary/chaos testing, OpenTelemetry tracing).
  • Microsoft Foundry Evaluations — Cloud evaluation capability described for measuring agent quality/safety/task performance continuously (scheduled and against production traffic), including adversarial attack simulation.
  • Agent Optimizer (Microsoft Foundry) — Foundry capability described as consuming evaluation results to improve agent performance.
What you can build
  • Generate application-specific evals from a natural-language policy spec (e.g., prevent unauthorized transactions, leakage, social engineering) and run them as regression tests in CI/CD
  • Create and review an editable taxonomy of permissible/impermissible behaviors, then auto-generate single-turn and multi-turn scenarios to stress an agent
  • Enforce deterministic policies at multiple checkpoints (input/tool/output) and re-run evals to quantify before/after safety and over-refusal impact
  • Apply a policy that detects SSNs in user input and blocks/rewrites before sending data to the model
  • Instrument agent traces including tool calls and intermediate actions for debugging and performance visibility (OpenTelemetry + Application Insights mentioned for Foundry observability)
  • Move from local testing to production monitoring by sampling production traffic for continuous evaluation in Microsoft Foundry
Code & CLI: github.com/responsibleai/ASSERTgithub.com/microsoft/agent-governance-toolkitaka.ms/build/evalsmicrosoft.com/en-us/research/project/romaRegoOPA/RegoCedarOpenTelemetryApplication Insights
ObservabilitySecurityAgentsMicrosoft FoundryResponsible AI
Session page ▶ Watch
BRK251 Breakout From transcript

Build secure and enterprise-ready agents with Agent 365

Neta Haiby, Kendra Springer, Ray Zhong

This session shows how Microsoft Agent 365 acts as a control plane to observe, secure, and govern agents across their lifecycle, including non-Microsoft agents. Speakers demo onboarding a LangChain Node.js agent using the Agent 365 SDK and discuss how Agent 365 integrates with Entra, Defender, Purview, and other enterprise controls to apply identity-aware access, telemetry, and policy-based governance.

What's new
  • Microsoft Agent 365 is described as “General Availability” and positioned as the control plane for agents
  • Agent 365 SDK wraps existing agents (not an agent-hosting or agent-building SDK) to make them discoverable and manageable in Agent 365
  • Registry sync ingests agents from connected platforms (example shown: Amazon Bedrock, Google Vertex AI) into the Agent 365 registry for visibility and carries through platform permissions (e.g., delete) where available
  • Agent 365 “templates” aggregate policies from Entra, Defender, Purview (and SharePoint) into reusable configurations applied during agent approval/publish
  • Agent 365 “rules” automate lifecycle actions such as reassigning agent ownership or automatically blocking agents when risk is identified
  • Admin center experiences include agent inventory/registry, per-agent activity views, exceptions, usage analytics, and dependency visibility for multi-agent solutions
APIs & SDKs
  • Microsoft Agent 365 SDK — Developer-integrated SDK to onboard/wrap agents (including third-party frameworks) for agent ID/identity, observability, tools/messaging integration, threat protection, governance, and (via Purview) data security.
  • Purview API/SDK — Used for agent data security and logging/audit scenarios; slides note data security via Purview API or SDK and transcript mentions access to logs and document/data-source level investigation.
What you can build
  • Onboard a LangChain (Node.js/TypeScript) agent into Agent 365 for telemetry/observability using OpenTelemetry instrumentation (as described in the demo recap)
  • Create an agent blueprint (reusable definition of tools/data/rules) and publish an agent for tenant users via an admin approval flow
  • Use agent identity patterns: run on behalf of a user (user credential passthrough) or run as an agent’s own user identity with its own permissions
  • Apply enterprise policies (e.g., sensitivity labels, DLP, retention, legal hold, eDiscovery) to agent activity using existing Purview-based governance controls (as described in the Genspark segment)
  • Monitor and investigate agent risks and activity in Microsoft 365 admin center, including drilling into policy sources (Entra/Purview) and blocking an agent
  • Integrate agents with Microsoft 365 surfaces via MCP servers (example: Word and OneDrive), enabling document creation and @mention-based notifications from Word comments
Code & CLI: aka.ms/A365SDK-StartGitHub - microsoft/Agent365-Samplesaka.ms/A365SDK-BlogAgent 365 CLIAzure CLIOpenTelemetryVS CodeLangChainNode.jsTypeScript
SecurityAgent 365PurviewResponsible AIGovernanceFoundry Control Plane
Session page ▶ Watch
BRK261 Breakout From transcript

Build and ship faster with a developer-optimized experience on Windows

Kayla Cinnamon, Craig Loewen, Clint Rutkas

This session walks through new and updated Windows developer experiences across setup, terminal/CLI workflows, WSL, and PowerToys, with demos rather than slides. It also covers tooling for building Windows apps (WinApp CLI, agent “skills” for WinUI 3/Windows App SDK) and a performance workflow using Sample Profile Guided Optimization (SPGO).

What's new
  • Windows Developer Config (winget configuration) repo published to automate developer machine setup; config is idempotent
  • New Windows Run dialog leveraging the architecture of PowerToys Command Palette
  • Vertical taskbar personalization returning (shown as Insider Program feature)
  • Intelligent Terminal experiment: in-terminal companion agent that can use installed agents/models
  • WSL Containers: a native container solution delivered via WSL with a new CLI (wslc / container alias) plus an API usable from Windows apps
  • Sample Profile Guided Optimization (SPGO) workflow for performance gains without instrumentation (hardware counter sampling via xperf, feeding SPD back into compilation)
APIs & SDKs
  • WinApp CLI — CLI for managing Windows SDKs, packaging, generating app identity/manifest/certificates, and build tools for Windows app development.
  • Win Dev Skills (agent plugin) — Agent plugin/bundle of skills (described as including skills/MCP servers/custom agents) for building WinUI 3 and Windows App SDK apps; includes workflows like building/running, design, code review, testing, packaging, migrating from WPF, and setup.
  • WSL Containers CLI (wslc / container) · announced — WSL-provided CLI to run Linux container commands, build images from Containerfiles, run containers, and map ports to Windows.
  • WSL Containers API (NuGet) · announced — API surfaced as a 'WSL Containers' NuGet package to build and run Linux containers as part of a Windows app build/run (demoed from a C# project), including session lifecycle, port mapping, and options like volume mounts and GPU access.
  • SPGO (Sample Profile Guided Optimization) — Compiler optimization workflow using hardware performance counter sampling (xperf → ETL/SPT → SPD) to guide inlining/code layout/hot-cold splitting, without instrumented builds.
What you can build
  • Bootstrap a Windows dev machine using an idempotent winget configuration that installs WSL/Ubuntu plus common tools (Git, GitHub CLI, Copilot CLI, VS Code)
  • Use Intelligent Terminal to work with an agent alongside your normal prompt (e.g., iterating on a failing regex) without the agent taking over the terminal UI
  • Run Linux containers directly from WSL via wslc/container, build from existing Containerfiles, and forward container ports to localhost on Windows
  • Use Windows Coreutils binaries (e.g., grep, wc) directly on Windows for Unix-like pipelines in the Windows terminal
  • Build a Windows WinUI 3 app with an agent assisted by Win Dev Skills, including running automated UI testing from the workflow
  • Integrate Linux container execution into a Windows app via the WSL Containers NuGet API so the app can start/stop a per-app WSL VM and run containerized services behind a native UI
Code & CLI: microsoft/WindowsDeveloperConfigaka.ms/wsldocslearn.microsoft.com/cpp/build/sample-profile-guided-optimizationaka.ms/intelligent-terminalmicrosoft/winappClimicrosoft/win-dev-skillsaka.ms/powertoysaka.ms/terminalaka.ms/wingetaka.ms/wslwslccontainer (alias for wslc)dotnet builddotnet runxperflazywslc
AIAgentsWindowsWindows DeveloperAzure LinuxVS Code
Session page ▶ Watch
BRK262 Breakout From transcript

Building Agents You Can Trust on Windows

Kirupa Chinnathambi, Patrick Nikoletich, Stuart Schaefer

This session argues that as agents move from answering questions to taking real actions, relying on prompts and app-level guardrails is insufficient due to a growing blast radius. It presents Windows platform primitives for agent identity, policy-driven containment via Microsoft Execution Containers (MXC), and centralized manageability/supervision patterns. Demos show policy-scoped file and network access, runtime enforcement/telemetry, and GitHub Copilot CLI/SDK integrating sandboxing controls.

What's new
  • Windows introduces three key platform capabilities for agent safety-by-design: agent identity, containment, and manageability
  • Microsoft Execution Containers (MXC) provides a policy-driven execution layer that composes an appropriate isolation boundary at runtime using OS primitives
  • GitHub Copilot CLI and Copilot SDK shipped an out-of-box sandbox (experimental flag) with plans to move to GA and become default
  • Public preview capabilities highlighted: protecting the local filesystem and restricting outbound network access (available in the GitHub Copilot SDK)
  • Taskbar Tasks API is referenced as a next step for agents on Windows (aka.ms/agent-taskbar)
APIs & SDKs
  • Microsoft Execution Containers (MXC) — Declarative, policy-driven execution/containment for agent actions; maps developer requirements and IT policy to OS primitives and composes containers dynamically.
  • GitHub Copilot CLI · preview — Adds optional sandboxing (behind an experimental flag) with a /sandbox command to toggle and configure protections like filesystem and network policies.
  • GitHub Copilot SDK · preview — SDK integration point for the sandboxing capabilities (filesystem protection and outbound network restriction) and for building UX around sandbox blocks/overrides.
  • Taskbar Tasks API — Referenced Windows API for agent task integration via aka.ms/agent-taskbar (no details provided in slides/transcript).
What you can build
  • Run an agent under a distinct Windows-recognized agent identity (separate from the human user) with its own permissions and audit trail
  • Contain agent tool execution using declarative policies that scope filesystem read/write paths, outbound hosts, timeouts, and limited UI access (e.g., clipboard read)
  • Detect and diagnose agent failures by observing sandbox enforcement events (e.g., blocked attempts to access sensitive system areas)
  • Use Copilot CLI sandbox to block destructive actions like deleting desktop files, while keeping the user aware that the sandbox is active
  • Restrict outbound network access to prevent risky operations (e.g., preventing actions that would make a private repo public) and reduce prompt-injection impact
  • In an SDK-integrated app, detect when sandbox blocks an action and provide user-controlled flows to review/disable sandbox to complete expected work
Code & CLI: github.com/microsoft/mxcaka.ms/agent-taskbar/sandbox (GitHub Copilot CLI slash command)Copilot CLI experimental flag (enables sandbox)
WindowsMCPAgents on WindowsGitHub Copilot CLI
Session page ▶ Watch
BRKSP92 Breakout From transcript

Scale agentic AI from on-device to cloud orchestration

Colin Helms, Imran Sheik Mohamed, Karthik Vijayan, Jayneel Vora

This breakout walks through three demos showing how agentic AI workloads can span client, edge, and cloud. It covers on-device inference via OS-level APIs, pooling VRAM across multiple small PCs to run larger local models, and a Kubernetes-based agent “harness” on Azure connected to a CPU-served LLM for private, scalable workflows.

What's new
  • Aion 1.0 Instant released (speaker: “released just yesterday”), shown running fully on-device on Intel Panther Lake NPU
  • Intel graphics driver capability to set up to 93% of system RAM as VRAM (slide + demo)
  • Llama.cpp RPC used to pool VRAM across multiple systems and expose an OpenAI-compatible endpoint
  • Copilot CLI can be pointed at local models via environment variables (demo)
  • MXC (Microsoft execution containers for agents) was “announced yesterday” and can be experimented with via Copilot CLI (per speaker)
  • Azure demo: OpenClaw “Harness” deployed on Kubernetes, mapped to an SGLang-served model on an Azure VM, with autoscaling of replicas based on CPU utilization
APIs & SDKs
  • WinML — OS-level API surface used to run the on-device model (with OpenVINO underneath, per demo).
  • OpenVINO — Used under the on-device workflow; also referenced for single-machine performance versus Vulkan in llama.cpp-based setups.
  • llama.cpp (RPC) — Shards a model across multiple machines, runs RPC servers per node, and can expose an OpenAI endpoint to point tools/agents at pooled local inference.
  • Copilot CLI — Shown as an agent-facing CLI that can be configured to target a local OpenAI-compatible endpoint for code-checking/workflows.
  • MXC (Microsoft execution containers for agents) · announced — Execution containers for running agent actions with configurable access to MCP servers, filesystems, and network; described as policy-manageable settings.
  • SGLang — LLM serving engine used in the Azure demo; mentioned with upcoming speculative decoding draft-model support.
What you can build
  • Run a chat-style agent locally on an NPU using OS-level APIs without writing NPU-specific code
  • Pool VRAM across multiple small Windows 11 PCs to run a larger local LLM and serve it via an OpenAI-compatible endpoint
  • Point Copilot CLI at a local model endpoint (instead of a cloud model) for code review/checking workflows
  • Host a private LLM on an Azure VM and connect it to a Kubernetes-deployed agent harness that can call tools (e.g., GitHub CLI) and summarize results
  • Autoscale agent harness replicas on Kubernetes based on CPU utilization to support multiple personas/agents
Code & CLI: Copilot CLIllama.cppSGLangvLLMOpenVINOWinMLGitHub CLIOC status
AIAzureCopilotMS TeamsAgentsDeveloper
Session page ▶ Watch
BRKSP94 Breakout From transcript

Orchestrate special agents with NVIDIA Nemotron models on Foundry

Joey Conway, AYSEN Ilkbahar, Stephen McCullough

This session shows how NVIDIA Nemotron open models can be used inside Microsoft Foundry hosted agents to build enterprise agentic workflows. The speakers focus on a system-of-models approach, using Nemotron models for agent tasks, plus Foundry features like agent identity via Entra ID, a managed toolbox of MCP tools, secure sessions, and trace/observability to make agent actions auditable and controllable.

What's new
  • NVIDIA announced Nemotron 3 Ultra (largest Nemotron open model to date) and said it will be available on Tuesday
  • Nemotron 3 Ultra uses multi-teacher on-policy distillation and supports NVFP4 optimized for Blackwell
  • Nemotron 3 Ultra uses a single checkpoint that runs in NVFP4 on Blackwell and can fall back to run on Hopper
  • Nemotron 3 Ultra supports up to 1 million tokens of context length (input side)
  • Foundry hosted agents support bringing your own container/harness and provide an agent identity that can be governed via Microsoft Entra ID
  • Foundry toolbox provides a single control plane to connect/manage MCP servers and constrain allowed tool functions, plus traces for step-by-step inspection
APIs & SDKs
  • Microsoft Foundry hosted agents (Foundry Agent Service) — Hosted agent runtime that can run a custom harness/container, provide isolated sessions, tool/MCP management via a Foundry-managed toolbox, and trace/observability of agent actions.
  • Microsoft Entra ID — Used to assign a managed identity to a Foundry-hosted agent and grant/revoke access to resources similarly to a human user (example shown with Azure Storage IAM).
  • NVIDIA Nemotron 3 Ultra · announced — Open model for reasoning/orchestration; described as a 550B model with 55B active parameters, NVFP4 support, 1M context, and agentic eval focus (tool use, long-horizon planning).
  • NVIDIA Nemotron 3 Super — Nemotron model size used in the demo as the backing model for a Foundry-hosted Hermes Agent session; described as published in March.
  • NVIDIA Nemotron 3 Nano — Small Nemotron model size referenced for tiered deployment; described as published in December and as a small MoE model (30B, active 3B).
What you can build
  • Deploy a custom agent harness (e.g., Hermes Agent) into Foundry hosted agents and connect it to enterprise tools via a managed toolbox
  • Route agent tasks across multiple models (frontier reasoning, Nemotron for complex sub-tasks, local/edge models for latency-sensitive steps)
  • Let an agent read Outlook email, make code changes in GitHub, run tests in a sandbox, and open a pull request end-to-end
  • Create a reusable ‘skill’ from user feedback (e.g., always add a specific reviewer, always include docstrings) and reuse it across future sessions
  • Use Foundry traces to audit which MCP servers/tools were called and in what sequence, for debugging and enterprise audit trails
  • Publish a hosted agent so it can be used directly from Microsoft Teams and retain learned skills across sessions
Code & CLI: https://build.nvidia.comhttps://github.com/nvidia/skillsLLM Perf Benchchat completions endpointHermes AgentNeMo Gym
Agents
Session page ▶ Watch
DEM301 Demo From transcript

Rethinking CI: Actions, AI Agents, and the End of Commit-Fail-Commit

Salil Subbakrishna, Denizhan Yigitbas

This demo shows two approaches GitHub is using to shorten the commit–fail–commit loop in CI: agentic workflows that auto-investigate failures, and a new runner debugger that lets you inspect and interact with a live job. Agentic workflows are authored as Markdown, compiled into Actions YAML via a GitHub CLI extension, and can automatically file an issue with root-cause analysis and suggested fixes when a workflow fails.

What's new
  • GitHub Actions “agentic workflows” will enter public preview next week (as stated in-session).
  • Agentic workflows are authored as Markdown and compiled into Actions YAML (a “.lock.yaml” output was mentioned to differentiate from non-agentic workflows).
  • A prebuilt “CI failure doctor” agentic workflow can auto-trigger on workflow failure and open an issue with diagnosis and suggested remediation steps.
  • Sneak peek: an internal GitHub Actions runner debugger that waits for a debugger client to connect, enabling interactive investigation without adding print statements or extra workflow steps.
APIs & SDKs
  • GitHub CLI extension for agentic workflows ("aw") · preview — Compiles agentic workflow Markdown files into GitHub Actions YAML via a CLI command.
  • Debug Adapter Protocol (DAP) — Protocol used by the Actions runner debugger so multiple editors/clients (e.g., VS Code, Neovim) can connect to and debug a running job.
  • GitHub Actions VS Code extension (modified version) — Provides a command to connect to a running Actions job for debugging.
What you can build
  • Auto-triage failed CI runs by triggering an agentic workflow that investigates logs/context and opens an issue with root cause and suggested fixes.
  • Customize an agentic workflow’s behavior by editing its Markdown prompt (optionally with Copilot assistance) and recompiling.
  • Share agentic workflow Markdown files across repositories/teams like normal repo files, then recompile in each repo.
  • Debug a workflow that “succeeds but is strange” by connecting a debugger client to the live runner and inspecting job context/environment variables.
  • Validate suspected fixes during debugging by running commands (e.g., git diff) directly on the runner to confirm expected file sets/inputs.
Code & CLI: gh aw compileGitHub debug running job (VS Code command)
AgentsDeveloperGitHub CopilotGitHubMCPGitHub Actions
Session page ▶ Watch
DEM302 Demo From transcript

Build and deploy an Azure app with your agent team

Brady Gaster, Rong Lu

Speakers demo a workflow that starts from a blank repo and uses GitHub Copilot agents to generate a multi-agent “customer insights” system, then deploy it as a hosted agent. The demo stays inside VS Code and Copilot tooling, showing local debugging with Agent Inspector, adding evaluations, and then provisioning/deploying cloud resources and a React front end using Copilot + a multi-agent tool called Squad.

What's new
  • Foundry Toolkit for VS Code includes an Agent Inspector UI for visualizing multi-agent workflows, sending test payloads, debugging, and inspecting runtime events
  • VS Code flow to deploy a local agent into a “hosted agent” running in the Foundry service, with live log streaming and Copilot-assisted troubleshooting from extracted logs
  • Copilot-driven evaluations can be submitted via a Foundry MCP server and viewed back inside VS Code
  • Foundry “toolbox” can bundle tools (e.g., Azure AI Search + a Fabric connector) behind a unified endpoint and unified authentication for agent access
  • Azure MCP tools and “Azure skills” (markdown guidance) are used to help Copilot compose multi-step Azure/Foundry tasks from the CLI
APIs & SDKs
  • Microsoft Agent Framework — Open-source framework used to orchestrate multiple agents into a workflow (classification, enrichment, triage, aggregation).
  • Microsoft Foundry service (hosted agents) — Runs the agent system as a managed hosted agent with playground and server-side log streaming.
  • Foundry Toolkit for VS Code — VS Code extension used for Foundry skills/knowledge, Agent Inspector, evaluations UX, and hosted-agent deployment workflow.
  • Foundry MCP server — Used behind the scenes to submit agent evaluations to the Foundry service.
  • Azure MCP server (Azure MCP tools) — Provides MCP tools accessible from Copilot/CLI for Azure and Foundry-related tasks.
  • Azure Skills (microsoft/azure-skills) — Markdown ‘skills’ that instruct Copilot how to combine MCP tools to accomplish Azure tasks.
What you can build
  • Build a multi-agent customer feedback pipeline that classifies sentiment, enriches with customer/order data, triages actions, and aggregates results
  • Connect a single agent in a workflow to enterprise data and search via a toolbox (Azure AI Search + Microsoft Fabric connector)
  • Debug and visualize multi-agent execution in VS Code, including per-agent inputs/outputs and runtime event inspection
  • Add and run agent evaluations from Copilot and view evaluation results inside VS Code
  • Deploy the agent as a hosted agent in Foundry and use live server logs to diagnose issues with Copilot
  • Deploy a React front end to Azure Container Apps that calls the hosted agent backend; provision infra via CLI with Copilot assistance
Code & CLI: Foundry Toolkit for VS Code: https://aka.ms/foundrytkAzure Skills repo: https://github.com/microsoft/azure-skillsGitHub Copilot feature page: https://github.com/features/copilotSquad repo: https://github.com/bradygaster/squadCommand: squad initCommands: skills listCommand palette search shown: "MCP show server name"Tool referenced: GitHub Copilot CLICLI referenced: azd
AzureAgentsDeveloperGitHub CopilotGitHubDeployment Pipelines
Session page ▶ Watch
DEM303 Demo From transcript

Late to agentic coding? Don’t panic, build.

Cassidy Williams, Martin Woodward

A demo-focused walkthrough of using GitHub Copilot’s agent experiences to go from ideas to working code, emphasizing planning, iteration, and guardrails. The speakers show creating GitHub Issues from prompts, using plan mode to refine implementation steps, and running an agent-built gesture game locally while discussing team adoption and cost control.

What's new
  • GitHub Copilot app is built on top of GitHub Copilot CLI and uses the same underlying engine on the machine
  • Copilot app can detect and follow existing GitHub Issue templates/standards when creating issues
  • Copilot app supports model choice (including auto mode), adjustable reasoning level, and “bring your own key”/local models (including models hosted on Foundry)
  • A new Copilot CLI command named "chronicle" was mentioned, including options like "standup" and "cost tips"
  • Copilot CLI supports a "remote on" flow to pipe an agent session for remote control (e.g., from a phone)
APIs & SDKs
  • GitHub Copilot CLI — Command-line interface used as the foundation for the Copilot app; referenced for running agent sessions and commands like yolo/allow-all, remote on, and chronicle.
  • GitHub Copilot (github.com/copilot) — Web experience where you can “@copilot” or assign Copilot to an issue to research or complete work in a GitHub conversation.
  • MCP servers — Pluggable skills/servers that can be added to Copilot sessions; example given was using a Playwright MCP server to screenshot websites and reason about design.
  • Playwright MCP server — Example MCP server used to open pages and take screenshots for visual validation and style inspiration.
What you can build
  • Collect product ideas from a team and auto-create structured GitHub Issues that follow your issue templates
  • Ask Copilot to produce a step-by-step implementation plan (“plan mode”), then iterate by asking questions to find gaps
  • Have Copilot implement a feature/game, run it locally, and review the result interactively
  • Use a second-model “rubber duck” pass to critique a plan and improve it
  • Use MCP tools (e.g., Playwright) to validate UI/design via screenshots and apply styling inspiration
  • Manage token/cost efficiency by using auto model routing and cost-focused guidance
Code & CLI: GH.IO/DEM303/IDEAgithub.com/copilotCopilot CLI slash command: yoloCopilot CLI command: remote onCopilot CLI command: chroniclechronicle option: standupchronicle option: cost tipsSpec KitPlaywright (via MCP server)MediaPipe (mentioned as a gesture-recognition choice in a generated plan)
AgentsDeveloperGitHub CopilotGitHubGitHub ActionsGitHub Enterprise
Session page ▶ Watch
DEM306 Demo From transcript

OM1: Modular, hardware-agnostic orchestration layer for next-gen robotics

Prachi Sethi

OM1 is an open-source, modular orchestration layer intended to connect different robot hardware stacks to a shared “cognitive” layer driven by LLM-based decision-making. The demo walked through OM1’s architecture, local laptop setup (API key + config + run command), and a cloud simulator workflow including SLAM mapping and navigation, with references to live use on a Unitree Go2.

What's new
  • OM1 is open source and positioned as a modular, hardware-agnostic orchestration layer for robots
  • Portal workflow: create an API key, register/label robot type, and manage robots/simulations from a web UI
  • Cloud simulator supports multiple robot types and environments (e.g., apartment, warehouse) with video stream/teleop UI
  • Autonomy features described: face detection/anonymization, SLAM map generation, autonomous navigation, obstacle avoidance, person following
  • Unitree Go2-specific feature described: auto-charging when battery drops below a threshold
  • Two runtime implementations mentioned: a Python version and a faster Go version, with an ongoing migration toward Go
APIs & SDKs
  • OM1 API key (portal-managed) — API key used by local/robot agents to identify a machine in the portal and enable app deployment/configuration
  • OpenRouter — LLM provider routing option to plug in different models/providers for the robot’s Cortex/LLM component
  • Ollama — Option to run/host local models and have OM1 route robot responses through a locally hosted LLM
  • Google ASR — Speech recognition input option for microphone/audio in agent inputs
What you can build
  • Run a local “virtual agent” on a laptop that listens and responds based on a configurable system prompt/personality
  • Connect a physical robot via OM1 and control modes like conversation, greeting, and navigation
  • Generate and save a SLAM map in a simulator, label locations (e.g., kitchen/living room), then issue navigation requests like “go to the kitchen”
  • Use teleoperation and live stream viewing from the portal for a connected robot or simulator instance
  • Enable person-following and greeting behaviors where the robot approaches a person, greets them, and holds a short conversation
  • Use telepresence/video-call style interaction to check in remotely (navigate the robot to a room and start a call)
Code & CLI: export OEM_API_KEY=...uv runcloud SIM (file/command referenced as starting the simulator)
AIAgentsGitHubOSS
Session page ▶ Watch
DEM315 Demo From transcript

Embracing frontier R&D with Microsoft Discovery

John Link, Viktor Veis

This demo frames “Agentic Discovery” as a workflow shift from AI assisting individual R&D steps to teams of agents running the full scientific loop (hypothesis, experimentation, reasoning) under human guidance. The speakers show Microsoft Discovery’s local app experience, its graph-based “Bookshelf” retrieval, and the Discovery Engine that creates/assigns tasks to agents to iterate autonomously. The session also positions an enterprise cloud offering for governed, scalable R&D alongside the lightweight local on-ramp.

What's new
  • Microsoft Discovery is generally available for organizations (enterprise cloud).
  • Microsoft Discovery local app announced as a free download; available “this summer” in Preview; requires only a GitHub Copilot account to start.
  • Bookshelf uses graph-based retrieval (GraphRAG) and converts indexed PDFs to markdown during ingestion.
  • Discovery Engine automates an investigation loop by creating tasks, matching them to agents, delegating subtasks, and potentially abandoning unpromising directions based on model confidence.
APIs & SDKs
  • Microsoft Discovery (enterprise cloud) · ga — Governed, production-grade platform for running agentic discovery workflows at scale (enterprise deployment).
  • Microsoft Discovery local app · preview — Local, VS Code-like experience for running core discovery capabilities (Bookshelf + Discovery Engine) without needing an Azure account.
  • Bookshelf (GraphRAG) — Graph-based information retrieval over a corpus (e.g., scientific papers) to ground discovery work with entities and relationships.
  • Discovery Engine — Task-and-agent orchestration for running iterative scientific-method loops (hypotheses/experimentation/reasoning) over long-running explorations.
What you can build
  • Index a corpus of scientific PDFs into a Bookshelf and query it to produce a generated Jupyter notebook with analysis and charts.
  • Generate an executive-summary “1-pager” from the same research output for less technical stakeholders.
  • Create custom agents (name/description/tools/instructions in markdown) and run parallel task trees with dependencies.
  • Automate iterative research by letting the Discovery Engine spawn new tasks/agents, delegate subtasks, and continue exploration over hours/days.
  • Use proprietary internal papers/knowledge alongside public literature to tailor discovery outputs to an organization.
  • Run locally without Azure, or use enterprise services with integrations to Azure HPC and Azure AI Foundry (when an Azure account is available).
Code & CLI: aka.ms/MicrosoftDiscoveryDocshttps://github.com/microsoft/discoveryMicrosoft Start Discovery (GitHub community repo, referenced in demo)aka.ms/build/evals
AIAzureAPIAgentsAzure Kubernetes Service (AKS)​​GitHub Copilot
Session page ▶ Watch
DEM332 Demo From transcript

From zero to teammate in 25 minutes: Build a Teams agent live

Aamir Jawaid, Umang Sehgal

This demo shows building and deploying a Microsoft Teams agent from an existing web app using the refreshed Teams CLI, the Teams SDK, and a Teams “dev agent” skill in GitHub Copilot. It also previews new Teams agent UX capabilities for group chats/channels and demonstrates turning an agent into a cross-M365 “teammate” with its own identity (including sending email from its own address).

What's new
  • Teams SDK positioned as a consolidation of Teams AI library-era components into a streamlined developer experience (GA called out for TypeScript, C#, Python on slide).
  • Refreshed Teams CLI: interactive UX for humans, progressive-disclosure help for agent use, and structured JSON output via a --json flag.
  • Teams SDK “skills plugin” used to integrate an existing app/agent into Teams via Copilot-assisted scaffolding in the demo.
  • New/previewed group chat agent UX capabilities: emoji reactions, targeted messages (private messaging within group chat), slash commands, and quoted replies.
  • “Agent 365 / Agents 365” concept shown to give agents an identity that works across M365 surfaces (e.g., Teams + Outlook), with IT visibility/observability and governance framing.
APIs & SDKs
  • Teams SDK · ga — SDK for building agents/apps for Teams; includes agent UX (streaming, feedback, follow-up suggestions, citations, starter prompts) and group UX (targeted messages, threaded replies, quoted replies, reactions).
  • Teams CLI — CLI to create/manage Teams apps and bots, generate install links, manage secrets/permissions; includes agent-friendly progressive disclosure and machine-readable JSON output.
  • Teams Skills / Teams SDK skills plugin — Skill/plugin used in the demo to help GitHub Copilot integrate an existing application into Teams (the Copilot session is scaffolded with a Teams dev agent skill that can use Teams CLI and read Teams docs).
  • Teams AI library — Prior-year library referenced as what existed before the Teams SDK consolidation (TypeScript and C# mentioned).
  • Agent 365 — Concept/platform referenced for giving agents an identity and enabling them to operate across M365 tools with governance/observability.
What you can build
  • Turn an existing web-based agent into a Teams agent that works in 1:1 chat.
  • Create the Teams app/bot registration and get an install link in one CLI flow rather than multiple manual steps.
  • Bring the same agent into a Teams group chat/channel and interact with it there.
  • Use Copilot (with a Teams dev agent skill) to scaffold and integrate Teams support into an existing codebase.
  • Create multiple “teammates” as personas from an agent blueprint, each scoped to a project/context.
  • Send an email from an agent’s own mailbox/identity (shown via Outlook) triggered from within Teams.
Code & CLI: teams app createteams appteams app updateteams app listteams app getteams -h / teams app -h / teams app update -h (progressive disclosure help)--json (Teams CLI JSON output flag)aka.ms/teams-sdkaka.ms/Teams-Skillsaka.ms/teamscliaka.ms/Agent365
AgentsDeveloperSkillsEnterprise
Session page ▶ Watch
DEM333 Demo From transcript

How Foundry integrates with open-source frameworks and tools

Nagkumar Arkalgud, Facundo Santiago

The demo builds a practical “OpenClaw-like” agent locally using LangChain/LangGraph-style code and then operationalizes the same agent in Microsoft Foundry without rewriting the core loop. It shows adding enterprise tools via MCP, codifying repeatable behavior with markdown-based skills, enabling browser automation with Playwright CLI, and moving to hosted deployment with observability via OpenTelemetry and Application Insights plus agent-to-agent consumption via A2A.

What's new
  • Foundry models expose OpenAI-compatible APIs so LangChain can target Foundry models via configuration rather than rewriting the agent loop
  • Foundry can host a LangGraph agent and expose it as an OpenAI-compatible Responses API endpoint
  • Foundry integrates with Application Insights and OpenTelemetry, including GenAI semantic conventions, to inspect traces spanning model calls and tool actions
  • Hosted agents in Foundry expose an A2A endpoint that A2A-compatible clients can use to discover the agent card and send messages
APIs & SDKs
  • Model Context Protocol (MCP) — Open protocol for tool discovery and invocation; demo uses a Work IQ Mail MCP server to expose Microsoft 365 mail actions (search messages, get message details, draft replies).
  • OpenAI-compatible API (Foundry models) — Protocol compatibility that allows LangChain chat models to call Foundry-hosted models.
  • Responses API (OpenAI-compatible, hosted via Foundry) — Adapter wraps the same LangGraph agent and exposes it as a Responses-compatible endpoint locally or in the cloud.
  • OpenTelemetry — Tracing/observability for the hosted agent; demo mentions Microsoft OpenTelemetry distro plus OpenTelemetry GenAI semantic conventions to capture spans, latencies, inputs/outputs, and tool actions.
  • Application Insights — Backend used to view traces for the Foundry-hosted agent, including tool calls and token usage details.
  • A2A (agent-to-agent communication) — Hosted agent exposes an A2A endpoint for discovery (agent card) and message sending from other runtimes/clients.
What you can build
  • Run a minimal local agent loop that calls a Foundry model via OpenAI-compatible APIs
  • Connect an agent to enterprise Microsoft 365 mail capabilities through a Work IQ Mail MCP server without hardcoding Microsoft 365 HTTP endpoints
  • Add repeatable behaviors (e.g., inbox triage) as markdown skill documents that the agent reads when relevant
  • Enable browser automation by exposing Playwright via a CLI tool interface and guiding usage with a skill
  • Deploy the same LangGraph agent as a Foundry-hosted agent via a Responses-compatible endpoint
  • Have another runtime (Copilot CLI) discover and invoke the hosted agent via A2A using an MCP-based directory
Code & CLI: create_deep_agentPlaywright CLICopilot CLIApplication Insights Traces tabMicrosoft OpenTelemetry distroOpenTelemetry GenAI semantic conventions
AgentsDeveloperMicrosoft FoundryMCPOSSAgent Observability
Session page ▶ Watch
DEM334 Demo From transcript

Build agents for chats, channels, and meetings in Microsoft Teams

Lily Du, Umang Sehgal

This demo session shows how Teams agents can move from 1:1 chat into collaborative spaces (group chats and channels) without creating noise. The speakers frame effective “collab agents” around three pillars—manners, privacy, and polish—and demo new Teams agent UX primitives like emoji reactions, threaded/quoted replies, targeted messages, and Markdown/Adaptive Cards to keep group workflows clean and trustworthy.

What's new
  • Announced emoji reactions for agents in Teams
  • Announced quoted replies for agents in Teams
  • Announced threaded replies for agents in Teams channels
  • Announced targeted messages from an agent (private messages visible only to a specific user in a shared conversation)
  • Announced targeted messages to an agent from within a group chat using slash commands (bidirectional private messaging)
  • Announced Markdown support for agent responses in Teams
APIs & SDKs
  • Teams SDK · ga — SDK for building Teams agents and integrating agent UX features (e.g., streaming, citations, reactions, threaded/quoted replies, targeted messages, cards, Markdown).
  • Teams CLI — CLI referenced as a way to build/try Teams agent capabilities.
  • Adaptive Cards — UI card framework used by agents to produce structured, interactive outputs with in-message calls to action.
What you can build
  • Build a Teams agent that reacts with emojis to acknowledge messages or signal long-running work
  • Keep agent responses scoped to the right place by replying in channel threads (rather than spamming the main channel)
  • Use quoted replies so an agent’s answer stays tied to the exact message it is responding to
  • Enable private, user-specific agent messages inside shared group conversations (targeted messages) to preserve trust and focus
  • Let users privately message an agent from within a group chat via slash commands, then post a public summary back to the group
  • Use Adaptive Cards and Markdown to make agent outputs scannable, structured, and actionable inside Teams
Code & CLI: http://aka.ms/teams-sdkhttps://aka.ms/Teams-Skillshttps://aka.ms/teamsclihttp://aka.ms/adaptivecardshub
AgentsDeveloperSkillsEnterprise
Session page ▶ Watch
DEM340 Demo From transcript

Build work-ready agents with Foundry + Work IQ, govern with Agent 365

Srikumar (Sri) Nair

This demo shows wiring a Microsoft Foundry agent to Work IQ via MCP to ground the agent in a user’s M365 work context (email, Teams, SharePoint) and adding Foundry IQ as a knowledge source backed by Azure AI Search indexing. It then walks through building eval datasets and running built-in evaluators (including groundedness), publishing the agent to Teams/M365 Copilot, and reviewing governance/observability controls in Agent 365 including agent identity, registry, tool governance, and policy controls.

What's new
  • Work IQ stated to be generally available mid-June ("next two weeks")
  • Work IQ exposes MCP plus additional interfaces mentioned: agent-to-agent (A2A) and REST APIs
  • Work IQ includes a secure agent workspace (scratch pad) that can be cleared when the agent runtime ends
  • Foundry agent publishing flow creates the bot service automatically and publishes to Teams and M365 Copilot channels, and registers the agent in the Agent 365 registry
  • Agent 365 provides an SDK to instrument non-Microsoft-stack agents (examples given: LangChain, AWS Bedrock) for observability/security/governance
  • Agent 365 supports tool governance for MCP/connectors, including setting Rego policies and the ability to block a tool (example: Work IQ MCP) across the tenant
APIs & SDKs
  • Work IQ MCP · ga — MCP endpoint added as a tool in Foundry to give an agent access to work context (email, Teams chat, SharePoint) under appropriate permissions.
  • Work IQ REST APIs — Additional interface mentioned alongside MCP for accessing Work IQ capabilities.
  • Work IQ A2A — Agent-to-agent interface mentioned as another protocol exposed by Work IQ.
  • Agent 365 SDK — SDK for instrumenting agents (including those built with LangChain or running on AWS Bedrock) to get Agent 365 observability/security/governance capabilities.
What you can build
  • Add Work IQ to a Foundry agent in one step to enable runtime tool calls over work data (email/Teams/SharePoint) with approval prompts (human-in-the-loop)
  • Connect Foundry IQ knowledge bases sourced from blob/container documents and indexed via Azure AI Search for grounded answers with citations
  • Run single-turn or multi-turn evals using either existing conversations or an uploaded hand-authored dataset
  • Evaluate an agent on task completion, task adherence, customer satisfaction, groundedness, and coherence; inspect tool selection and tool output utilization scores
  • Publish an agent to a company store and deploy it to Teams and M365 Copilot while sending it through an admin approval flow
  • Use Agent 365 registry/admin center to review agent identity, permissions, observability, and tool/MCP governance
Code & CLI: LangChainAWS BedrockAzure AI SearchIntuneMicrosoft DefenderGitHub CopilotRego policies
Agent 365Foundry IQMicrosoft FoundryResponsible AIGovernanceWork IQ
Session page ▶ Watch
DEM350 Demo From transcript

GitHub Agentic Workflows: Automation That Actually Reads the Room

Ari LiVigni, Alejandro Menocal

This demo shows GitHub Agentic Workflows, where you define GitHub Actions-like automation in a Markdown file and compile it into a generated workflow (lock file). The presenters walk through a GitHub Skills exercise that scaffolds repo files, then uses an agent to create a workflow that periodically fetches GitHub updates and opens a ready-to-review pull request using a sandboxed, “safe output” approach for write operations.

What's new
  • GitHub Agentic Workflows are releasing in public preview next week
  • Workflows can be defined in Markdown (natural language) and compiled into a generated lock file used to run the workflow
  • Security model discussed: agent runs with read-only permissions; write operations (creating issues/PRs) happen via a “safe output” step
APIs & SDKs
  • GitHub Agentic Workflows · preview — Define automation in Markdown, compile to a generated lock file that runs as a workflow and can open issues/PRs via safe outputs.
  • GitHub Actions · ga — Underlying workflow execution model; agentic workflows compile down into an Actions workflow/lock file.
  • MCP server — Mentioned as installed as part of the scaffolded setup for agentic workflows.
What you can build
  • Triage CI/test failures and propose fixes
  • Create daily issues/reports summarizing repository status
  • Open pull requests that update docs/tests or other repo content
  • Build a scheduled workflow that fetches updates (blogs/changelogs/notes in the repo) and proposes website content updates via PR
Code & CLI: GitHub Skills exercise (linked via QR code in the demo)aka.ms/build/evals
AIAutomationAgentsDeveloperGitHub CopilotGitHub
Session page ▶ Watch
DEMSP380 Demo From transcript

Build automated agents using optimized AI Foundry models on Snapdragon

Darren Oberst, Meghana Rao, Morris Novello

This demo shows how to build multi-step, schedule-driven enterprise agents that run locally on Snapdragon X Series PCs using models from Foundry Local. The flow is authored in LLMware Model HQ (no-code drag-and-drop), can call into JIRA and other systems, and can be exposed as a local Windows service so developers can trigger agents and fetch outputs via an API.

What's new
  • LLMware Model HQ integrates with Foundry Local to run optimized models locally on Snapdragon PCs with NPU acceleration
  • Agents can be run on a schedule and can execute without user prompting for repetitive multi-step workflows
  • No-code agents can be exposed as a backend Windows service and invoked over an API on localhost
  • Agent outputs can be generated as consumable artifacts (CSV, Excel workbooks, PowerPoints) and sent via email; sharing over Teams/Slack was mentioned as options
  • Agents can be packaged and shared as a ZIP containing JSON configuration plus custom data assets, without sharing credentials
  • Workflows can mix local small models with optional cloud model call-outs for specific steps
APIs & SDKs
  • Windows ML API — Used to run Foundry Local models on-device; described as an integration path behind Model HQ on Snapdragon PCs.
  • ONNX Runtime APIs — Alternative backend integration option mentioned for running models locally.
  • Qualcomm execution providers — Execution provider used underneath to target the Qualcomm NPU for best local performance.
  • LLMware SDK (Model HQ service API) — SDK used to call a no-code agent programmatically (e.g., call/run agent asynchronously, then fetch outputs by execution ID).
  • JIRA API — Data source integration used in the demo to pull issues and filter/summarize them.
What you can build
  • Daily scheduled JIRA triage: pull issues via JIRA API, filter for critical/open items, generate per-issue summaries, and email a condensed spreadsheet
  • Build an air-gapped version of an agent workflow that runs entirely locally (except for external data pulls, when used)
  • Expose a local agent as an API endpoint on localhost and integrate it into a custom application
  • Turn a Snapdragon laptop into a small local "server" by exposing the service beyond localhost (described as possible)
  • Hybrid workflow: run most steps locally (extraction/summarization) and call out to a cloud model for a single complex step, then continue locally
Code & CLI: LLMware Model HQFoundry LocalWindows service (Model HQ backend switch)client.call_agent (method name shown in code example)run_agent (method name described for async execution)get agent outputs by execution ID (API pattern described)
AIComputeAgentsDeveloperLocal AIMicrosoft Foundry
Session page ▶ Watch
DEMSP381 Demo From transcript

Scale agentic AI cost-efficiently on Azure with Arm Cobalt VMs

Gova Babu, Pranay Bakre, Sameer Nori

This demo focused on running agentic, cloud-native applications with local (in-cluster) LLM inference on Azure Cobalt Arm-based VMs, orchestrated on AKS. The speakers described Cobalt 200 VM preview, its claimed per-core performance uplift vs. the previous generation, and showed a shopping-cart microservices app augmented with an agent workflow and CPU-based inference.

What's new
  • Azure Cobalt 200 VMs are in preview (announced in the keynote, referenced in this session).
  • Cobalt 200 VMs include native support for Azure Boost (as stated in the session).
  • New/expanded Cobalt 200 VM offerings mentioned: D/DP/ECDS plus memory-optimized ("~16 GB per core") and local-storage-dense LCDS SKUs (as described by the speaker).
  • Cobalt 200 preview is available in eight regions, with planned expansion at GA (as stated in the session).
APIs & SDKs
  • Azure Kubernetes Service (AKS) · ga — Kubernetes platform used to run a mixed-node cluster and deploy a microservices app plus in-cluster LLM inference tiers on Cobalt VMs.
What you can build
  • Run CPU-based LLM inference for an agentic workflow entirely inside an AKS cluster (no third-party LLM calls).
  • Deploy a polyglot microservices app (shopping cart example) across Arm-based Cobalt node pools.
  • Use an in-cluster “shopping agent” that routes requests, searches products, applies constraints (budget/categories), and maintains conversation context via a cache.
  • Scale distributed microservices across “hundreds of nodes” on Cobalt VM families (claimed suitability for microservices scaling).
Code & CLI: MCP (mentioned in session tags; no concrete usage details provided in transcript)
Azure Kubernetes Service (AKS)​​MCPAKS
Session page ▶ Watch
DEMSP382 Demo From transcript

Build AI apps with Oracle Database@Azure, MCP, and GitHub Copilot

Rajya Laxmi Yellajosyula, Partha Srinivasan

This demo shows how to use Oracle and Microsoft MCP servers with GitHub Copilot in VS Code to provision and work with Oracle Database@Azure and Microsoft Fabric using natural-language prompts. The flow covers creating and validating synthetic data in Oracle Autonomous Database, moving it into Fabric (via CSV, with mention of GoldenGate and Fabric Mirroring options), then building Fabric notebooks, pipelines, ML experiments, and a Power BI dashboard plus a Fabric data agent.

What's new
  • Oracle MCP servers are available in the OCI portal and are also available in the Microsoft AI Catalog (speaker states a blog released today)
  • Fabric MCP server can be used from a VS Code extension to access Fabric workspaces, lakehouse artifacts, and create notebooks/pipelines via tools invoked by GitHub Copilot
  • Oracle Database@Azure is described as accessible via Azure Marketplace as a native database offering running in Azure datacenters
  • Oracle data can be brought into Fabric via OCI GoldenGate replication (real time) or Fabric Mirroring (near real time), per speaker
APIs & SDKs
  • Oracle MCP server — Translates natural-language prompts into Oracle database operations (including SQL execution via SQLcl) for schema discovery, table creation, data validation, and tuning-related checks.
  • Microsoft Fabric MCP server — VS Code extension exposing tools used by GitHub Copilot to list workspaces, inspect lakehouse tables/relationships, create/deploy Fabric notebooks, and assemble/run Fabric data pipelines.
  • Microsoft Fabric REST APIs — Used alongside Fabric MCP server tooling to create/deploy notebooks, create ML experiment artifacts, and create semantic models and data agents in Fabric.
  • SQLcl — Oracle command-line utility used under the hood to run SQL against the Oracle database during MCP-driven operations.
  • OCI GoldenGate connector — Enterprise option mentioned for transporting/replicating Oracle data into Fabric in real time.
  • Fabric Mirroring — Fabric option mentioned for mirroring Oracle data into Fabric in near real time.
What you can build
  • Provision Oracle Autonomous Database on Azure Marketplace and connect to it from VS Code using an Oracle MCP server
  • Create tables and generate synthetic dataset in Oracle DB using natural-language prompts, then validate row counts and sample queries
  • Export Oracle data to Microsoft Fabric OneLake (demo uses CSV) and verify landing via Fabric MCP server tools
  • Use Fabric MCP server + Copilot to discover lakehouse tables and generate an ER-style relationship view (PK/FK)
  • Generate Fabric notebooks and a Fabric data pipeline that transforms bronze-layer tables into a gold-layer table and validates writes back to the lakehouse
  • Create an ML experiment for viewership forecasting (speaker uses a "profit" model) and persist forecast results as a Delta table, then auto-generate a Power BI dashboard and a Fabric data agent over the resulting tables
Code & CLI: VS CodeGitHub CopilotOracle SQLclMicrosoft Fabric OneLakePySparkDelta tablePower BI
AIAzureVector EmbeddingsAPIAgentsMCP
Session page ▶ Watch
DEMSP385 Demo From transcript

Build context-aware agents using GitHub Copilot, Elastic, and Azure AI

Jeff Vestal

This demo shows how to extend PR reviews beyond static checks by having an agent compare code changes against historical production incidents and OpenTelemetry traces stored in Elasticsearch. A GitHub Action calls an Elastic Workflow that invokes an Elastic Agent Builder agent; if it finds a semantic match to past incidents, it posts a PR comment with trace/incident context and suggested fixes. The flow is also accessible from VS Code using GitHub Copilot with an Elastic MCP server, letting developers investigate and apply fixes without leaving the editor.

What's new
  • GitHub Actions PR workflow calling Elastic Workflows + Elastic Agent Builder to review diffs against production telemetry and incident/postmortem data
  • Agent posts automated PR comments when it detects a semantic match to prior incidents (not keyword matching), including trace examples and remediation suggestions
  • Elastic Agent Builder supports skills (guidance/knowledge) vs tools (functions) such as querying Elasticsearch, semantic/vector search, workflows, and MCP server calls
  • ESQL-based tool examples to search incidents and find similar traces/latency spikes, with semantic matching backed by embeddings in the cluster
  • VS Code flow using GitHub Copilot with an Elastic MCP server to call the same incident/trace tools and apply code changes from the editor
APIs & SDKs
  • GitHub Actions — Trigger PR checks and call an Elastic Workflow URL; parse the response and post a PR comment when the agent reports a match
  • Elastic Workflows — Workflow endpoint invoked from GitHub Actions; collects PR metadata/diff and calls the agent, returning content used to comment on the PR
  • Elastic Agent Builder — Agent platform used to implement an AI pull request reviewer with custom instructions, skills, and tools for querying traces/incidents
  • Elasticsearch ESQL — SQL-like query language used in agent tools; demonstrated for incident search with a match query used for semantic/vector matching
  • Model Context Protocol (MCP) — Protocol used to expose Elastic agent tools via an Elastic MCP server so GitHub Copilot in VS Code can call functions like searching incidents and finding similar traces
  • GitHub Copilot (Agent Mode) — Used in VS Code to interpret the PR comment, call MCP-exposed Elastic tools, and apply code changes suggested by the incident-aware review
  • OpenTelemetry — Trace data stored in Elasticsearch and queried by the agent to cite prior regressions and provide examples from production telemetry
  • Azure AI Foundry — Not detailed in the transcript beyond being listed as powering the solution in the session metadata/abstract
What you can build
  • Block or warn on PRs that reintroduce known production failure patterns by matching diffs to historical incidents and OTel traces
  • Add an incident-aware PR reviewer step to an existing GitHub Actions pipeline by calling an external workflow endpoint
  • Query and summarize past incidents for a specific endpoint/route, including related traces and latency spike evidence
  • Use VS Code Copilot with an MCP server to investigate production telemetry context for a code change and apply a safer fix
  • Create reusable “skills” from recurring incident RCAs (e.g., race condition patterns) to guide agent review behavior
Code & CLI: Elastic MCP serverEQL/ESQL (Elasticsearch SQL-like query language)KibanaGitHub Actions workflow (calling a workflow URL and posting PR comments)VS CodeGitHub Copilot
AIObservabilityAgentsGitHub CopilotVisual Studio CodeMicrosoft Foundry
Session page ▶ Watch
DEMSP386 Demo From transcript

Develop faster on Windows with AI playbooks and local agents

Adrian Macias

This demo shows AMD’s “AI Playbooks” approach for getting from setup to first commit faster on Ryzen AI PCs, emphasizing local-first agentic coding workflows. The speaker also introduces “Lemonade” as a routing/abstraction layer that can run requests locally (CPU/GPU/NPU) or route to cloud endpoints, including multimodal routing across model types using an OpenAI-compatible API pattern.

What's new
  • Introduced/featured “Lemonade” and “Lemonade routers” as a routing/abstraction layer in the ROCm stack for local vs cloud inference and device selection (CPU/GPU/NPU)
  • A new Lemonade “launch” feature to start agentic tools/frameworks from Lemonade (examples mentioned: Codex, Claude, Gaia, OpenCLAW)
  • “AI Playbooks” developer portal content launched recently, with playbooks open-sourced on GitHub (including unreleased playbooks visible in the public repo)
  • An “omnimodal” routing capability in Lemonade that assembles collections of models (e.g., image generation, image edit/control-net style flow, speech) and routes by query context
  • A client-focused semantic filtering/routing approach to keep sensitive queries local (example: detecting personal info such as a Social Security number) and to route low-value queries locally for cost control
  • A headless “Halo box” appliance-style PC shown as an always-on agent host; ordering/launch stated as coming in June
APIs & SDKs
  • Lemonade (embeddable DLL) — Embeddable local routing layer (“tracks and switches”) that abstracts hardware/runtime differences and routes inference across CPU/GPU/NPU and optionally to cloud endpoints; includes model collection management and modality-aware routing.
  • OpenAI-compatible inference endpoint API — Used as the standard API surface so apps/agents can target a common endpoint interface while routing execution to either cloud endpoints or local PC via Lemonade.
  • ROCm stack — Underlying AMD software stack referenced as the layer Lemonade integrates into; includes GPU acceleration and related tooling.
  • vLLM Router — Referenced as a more sophisticated semantic router used in earlier demos; Lemonade can plug into it for routing decisions/policy enforcement.
What you can build
  • Run agentic coding workflows fully offline on a Windows laptop by routing to local GPU/NPU/CPU
  • Dynamically switch an agent’s tasks between local models and cloud models based on convergence, quality needs, or resource availability
  • Apply semantic rules/policies so sensitive prompts stay local (firewalled) while non-sensitive work can use remote endpoints
  • Route multimodal requests ("draw…", "narrate…", "edit this image…") to the appropriate model type in a single app experience
  • Standardize an app on an OpenAI-style inference API while changing the execution target (local PC vs various cloud endpoints) via routing
  • Prototype an always-on, headless local agent host that runs background tasks overnight and produces a morning task list/dashboard
Code & CLI: developer.amd.comROCmHIPDocker (mentioned as heavy for some client setups)vLLM RouterOpenRouterVitisComfyUIVulkanllama.cppStable Diffusionwhisper.cppCocoroNotion
AIAPIAgentsDeveloperWindows DeveloperAgents on Windows
Session page ▶ Watch
DEMSP387 Demo From transcript

Secure agent workflows in GitHub Copilot with NVIDIA OpenShell

Ali Golshan, Alex Watson

This demo presents NVIDIA OpenShell as a zero-trust runtime for running coding agents in isolated sandboxes, with policy enforcement moved down to the infrastructure/kernel layer rather than only at the agent/model layer. It shows two workflows: using GitHub as a persistence/audit layer for multi-agent work, and an agent negotiating additional permissions that are checked via a formal “policy prover” before hot-reloading updated sandbox policies.

What's new
  • OpenShell is open source under Apache 2.0, with architecture and roadmap published in its GitHub repo
  • Policy enforcement is designed to be deterministic at the infrastructure/kernel layer, with credentials held outside the sandbox via a gateway
  • A “Policy Prover” can mathematically analyze proposed policy changes (OPA/Rego or YAML described as formal logic) to determine the effects of granting new permissions
  • Policies can be hot-reloaded into a running sandbox (no sandbox restart required) to minimize agent workflow latency
  • OpenShell emits audit logs in OCSF (Open Cybersecurity Schema Framework) format for security tooling integration
  • OpenShell supports pluggable sandboxing “drivers” (examples mentioned: Firecracker, hardened containers, trusted computing, Kubernetes SIG sandboxing primitives)
APIs & SDKs
  • OPA / Rego policy — Define sandbox/network/file access controls for agents; used as input to OpenShell’s policy enforcement and policy negotiation flow.
  • OCSF (Open Cybersecurity Schema Framework) — Security/audit event log format emitted by OpenShell for downstream ingestion (Splunk and Datadog mentioned as compatible targets).
What you can build
  • Run GitHub Copilot-style coding agents inside isolated, per-agent sandboxes with default-deny (zero-trust) permissions
  • Store multi-agent artifacts/notes/audit trails into GitHub as a persistence layer, then have a synthesis agent aggregate results
  • Let an agent request additional capabilities (e.g., GitHub write access) and have the request validated by a policy prover before granting
  • Prevent secret leakage by keeping credentials/tokens/keys in a gateway outside the sandbox blast radius
  • Route LLM inference requests based on PII presence (local model for PII; frontier model when no PII; optional rewriting via differentially private fine-tuned models)
Code & CLI: OpenShell GitHub repo (examples directory referenced)OpenShell terminal interfaceOpenShell “drivers” (Firecracker, hardened container, trusted computing, Kubernetes SIG sandboxing primitives mentioned)Google A2A agent-to-agent protocol (mentioned as an option for high-rate inter-agent communication)
Agents
Session page ▶ Watch
DEMSP388 Demo From transcript

Ship faster with Claude Code and Cowork in Microsoft Foundry

Caroline Matthews, Ryan Whitehead

This demo shows how long-running coding agents can operate inside Microsoft Foundry using Claude models, including planning across files, running tests, and recovering from failures. The speakers focus on practical patterns for keeping agents productive and safe: permissioning via Auto mode, separating code generation from evaluation, and giving agents richer perception (browser/computer use and image understanding).

What's new
  • Claude Opus 4.8 was released the prior week and is available in Microsoft Foundry
  • Claude Code “Auto mode” uses a classifier between requests and the model to auto-approve low-risk actions while prompting on riskier ones (research preview)
  • Claude Code supports “rewind” to return to an earlier state and rerun a task with different settings
  • A “/workflows” command was shown to manage dynamic workflows with multiple sub-agents (designers, a picker/judge, and testers) for a single task
APIs & SDKs
  • Microsoft Foundry (Claude models catalog: Opus 4.8, Sonnet 4.6, Haiku) — Run Claude models in Foundry with enterprise controls; used here for long-running agentic coding and image-based security review.
  • Claude Code Auto mode · preview — Classifier-mediated permissioning that lets an agent proceed on low-risk actions (e.g., reading files, running tests) while interrupting for higher-risk actions (e.g., arbitrary bash).
  • Claude Code rewind — Reset files/state back to an earlier point and rerun the same prompt under different execution settings (e.g., enable Auto mode).
  • Claude Code dynamic workflows (/workflows) — Create and coordinate multiple sub-agents (idea generation, selection/judging, testing) within one task.
  • Claude browser use (in Chrome) — Agent interacts with a real Chrome browser (not just headless scraping) as part of tool use.
  • Claude computer use — Agent can operate across a machine UI (example mentioned: driving an iOS simulator and responding to what it sees).
What you can build
  • Let a coding agent add a new endpoint to a FastAPI app, update README, and run tests with fewer permission interrupts using Auto mode
  • Implement a “planner / generator / evaluator” agent pattern so one agent writes code and a separate agent judges it (including adversarial review and test generation)
  • Use image understanding in Foundry to review an app screenshot and identify potential security risks that are not explicitly labeled
  • Run multi-agent dynamic workflows to generate multiple solution designs, pick one, implement it, and execute a parallel testing pass
  • Kick off a longer task (e.g., build an arcade game) and let it continue while you’re away, only interrupting for higher-risk approvals
Code & CLI: Claude Code/workflows
AIAgentsDeveloper
Session page ▶ Watch
DEMSP390 Demo From transcript

Create multimodal AI agents with persistent memory

Edo Segal

Napster CTPO Edo Segal demos building a video-based, multimodal agent using the Napster Omniagent API, positioned as an experience layer on top of an Azure AI Foundry agent. The talk emphasizes persistent memory and deploying the same agent across channels (web, phone, WhatsApp, kiosk) with an “edge MCP” approach that wires agent actions/state into a website at the JavaScript source level.

What's new
  • Public preview of “Napster on Azure” via Azure Native Integrations (unified Marketplace billing + provisioning via Azure portal)
  • Omni Agent API: one API for multimodal agents (video/audio/text) across multiple surfaces (website, WhatsApp, phone call, kiosk) with persistent memory
  • Approach to generate an “edge MCP server” embedded in a website’s JavaScript source to let an agent control the site via DOM locally (instead of remote tool calls)
  • A workflow described as: provision Azure resource in Azure portal → SSO to Napster portal → Omni agent connects to Azure AI Foundry agent (Foundry as “intelligence layer”, Napster as “experience layer”)
  • New “skills” described: an “identify” skill to analyze web app source and create the embedded MCP wiring, and an “agent” skill to create/provision the Foundry agent
APIs & SDKs
  • Napster Omni Agent API — Single API to create multimodal agents (video/audio/text) and run them across channels with persistent memory; integrates with Azure AI Foundry agents as the underlying intelligence layer.
  • Napster on Azure (Azure Native Integrations) · preview — Azure-native provisioning/billing and portal-based setup that links Azure resources to the Napster portal via SSO and uses Azure AI Foundry underneath.
  • Edge MCP server (embedded in site JavaScript) — Generated MCP interface that lives in the browser to expose site capabilities/state to the agent for local DOM-based control and state updates.
What you can build
  • Add a video/avatar agent to an existing website that can navigate and operate the UI (e.g., filter products and add to cart) using an embedded browser-side MCP bridge
  • Deploy the same agent experience across web, kiosk, WhatsApp, and phone calls while retaining persistent memory of the user
  • Provision an agent through Azure portal + Marketplace billing, then manage its intelligence layer in Azure AI Foundry while using Napster for the multimodal experience layer
  • Build in-store/field experiences (kiosk in a noisy store environment; holographic display device “The View”) backed by the same agent backend
Code & CLI: Azure portalAzure MarketplaceAzure AI FoundryVisual StudioGit (local repo on developer laptop)
AIAPIAgentsEnterprise
Session page ▶ Watch
DEMSP393 Demo From transcript

Orchestrate omnichannel AI agents with Foundry and Twilio

Rachel Baskin

This demo shows how Twilio Agent Connect integrates Twilio voice/SMS/chat with Microsoft Foundry hosted agents to preserve customer context across channels. The architecture uses API Management for webhook validation and routing, Cosmos DB for session persistence, and websockets for low-latency voice streaming via Foundry Voice Live.

What's new
  • Twilio Agent Connect (TAC) native integration with Microsoft Foundry via an open-source SDK with connectors for Twilio and Foundry
  • A hosted-agents deployment option for TAC that uses API Management + hosted agents + Cosmos DB for per-conversation session mapping and memory injection
  • Use of Foundry hosted agents features (traces, monitoring, evals, playground) out-of-the-box after deployment
  • Voice streaming integration using a TAC Voice Live connector that integrates with Foundry Voice Live over websockets
  • Twilio channels (voice/SMS/chat) route through APIM which validates Twilio signatures and maps Twilio conversation IDs to hosted-agent session IDs
APIs & SDKs
  • Twilio Agent Connect · announced — Twilio product for real-time conversation management, persistent memory, and multichannel orchestration; used here to bridge Twilio channels into Microsoft Foundry agents.
  • Agent Connect SDK (open source) — Open-source SDK with two connectors (Twilio connector and Foundry connector) used to build one agent across channels; includes a hosted-agents deploy option and a Python class that bridges hosted-agent requests from Twilio.
  • Microsoft Foundry hosted agents · preview — Agent compute primitive providing per-session sandboxing, state persistence, unique agent identity, and built-in observability (traces/monitor/evals) used as the runtime for the Twilio-integrated agent.
  • Foundry Voice Live API — Used for streaming inference over websockets for low-latency voice interactions via the TAC Voice Live connector.
  • Hosted agents WebSocket support · preview — Websocket support used to enable low-latency voice channel hosting/streaming; referenced as recently in public preview.
  • Hosted agents Invocations API — Referenced as recently available and used as part of enabling the hosted-agents deployment option.
What you can build
  • Build an omnichannel customer-support agent that carries context from a voice call into SMS follow-ups (and vice versa)
  • Deploy a Twilio-connected Foundry agent using hosted agents with per-conversation isolation/sandboxing
  • Validate Twilio webhooks and route events through Azure API Management before invoking a hosted agent
  • Store and inject contextual memory for conversations via Azure Cosmos DB
  • Stream voice interactions with low latency using websockets + Foundry Voice Live
  • Use hosted-agent traces/monitoring/evals to inspect and evaluate real customer conversations
Code & CLI: GitHub repo: "Twilio Agent Connect to Microsoft" (open source)pip install (TAC hosted agents app class is installable in Python)azd upAzure API ManagementAzure Cosmos DBTwilio Conversation Relay
AIAzureAPIAgentsDeveloperFoundry IQ
Session page ▶ Watch
DEMSP394 Demo From transcript

Scale enterprise .NET apps with AI-assisted cross-platform workflows

Sam Basu, Colin Whitlatch

Uno Platform and Kahua demo an AI-assisted workflow for building and iterating on enterprise .NET apps that target web (WASM), desktop, and mobile from a shared codebase. The focus is on contextual AI: agents grounded in Uno docs and able to inspect and interact with a running app UI, plus live visual editing via Hot Design/Hot Reload in both browser and IDE.

What's new
  • Uno Platform Studio 3.0 announced
  • Uno Platform Studio app: build a full cross-platform .NET app in the browser with "literally nothing to install", then export to GitHub or local for IDE/CLI work
  • Specialized Uno Platform agent with 60+ skills released "as of today"
  • MCP tooling to ground agents in latest docs and enable app UI interactivity (e.g., screenshot/click) for verification loops
  • UI component previews to validate components in isolation across responsive boundaries, data-context states, and themes
APIs & SDKs
  • Uno Platform Studio 3.0 · announced — AI + design tooling (agent skills/plugins, MCP integration, previews, snippets, Hot Design/Hot Reload) for building and validating Uno Platform .NET apps across platforms.
  • Uno Platform Studio app · announced — A client experience that runs on desktop, web, and mobile to generate and iterate on a full .NET app in-browser and export to GitHub or local for further development.
  • Uno Platform — Open-source cross-platform .NET stack to build apps from a single shared codebase targeting iOS, Android, WebAssembly/browser, Windows, macOS, and Linux.
  • MCP servers/tools (Uno context + app interactivity) — Model Context Protocol servers/tools used to ground the agent in Uno docs and provide UI interactivity (e.g., click, screenshot) so the agent can validate changes against a live running app.
What you can build
  • Spin up a real cross-platform .NET app from a prompt directly in a browser, preview light/dark modes and multiple form factors, then export to GitHub/local
  • Use a runtime visual designer (Hot Design) to inspect visual tree and tweak UI live, syncing changes back into C#/XAML in the IDE
  • Run the same app on desktop from VS Code and iterate with Hot Reload/Hot Design while inspecting live bound data in templates
  • Have an AI agent drive and verify the UI via app-interactivity tools (screenshots/clicks) to support UI/integration testing loops
  • Validate UI components via isolated previews across responsive breakpoints, themes, and data-context states
Code & CLI: Visual Studio CodeVisual StudioGitHub CopilotMCP (Model Context Protocol)WebAssemblySkiaMVVMMVUXGPT-5 mini
AIAgents.NETDeveloperGitHub CopilotVisual Studio Code
Session page ▶ Watch
DEMSP395 Demo From transcript

Teach AI agents to manage context with Elastic Agent Builder

Deepti Dheer, Mike Richter

This demo shows how Elastic Agent Builder (referenced as part of Elasticsearch 9.4 in the abstract) can help agents manage long-running context by using skills, tools, and connectors to retrieve the right information without bloating prompts. The speakers focus on running Elastic on Azure (including Marketplace procurement and enterprise networking/identity) and demonstrate a support scenario that pulls data from Elastic indices plus systems like SharePoint, GitHub, and Slack within one conversation flow.

What's new
  • Elastic available on Azure with hosted and serverless offerings; purchasable via Microsoft Marketplace for a single Azure bill (and can use Azure commitment dollars)
  • Elastic on Azure supports Microsoft Entra ID sign-in to access Elastic (portal access and management)
  • Elastic managed service can be accessed over Azure Private Link (treated as part of a customer's VNet)
  • Elastic Agent Builder supports transparent display of tool/skill calls during an agent run (to reduce “black box” behavior)
  • Agent Builder supports custom skills and custom tools, including tools created using ES|QL, indexed data workflows, and MCP
APIs & SDKs
  • Elastic Agent Builder (Elasticsearch 9.4) — Build and customize agents with skills, tools, connectors, and a conversation flow intended to manage context and reduce prompt bloat.
  • ES|QL — Elastic query language used to create agent tools.
  • Azure Private Link — Private connectivity from Azure VNets to Elastic managed service for compliance/private access needs.
  • Microsoft Entra ID — Identity used to sign into Elastic via the Microsoft portal identity for unified access.
What you can build
  • Deploy Elastic on Azure and procure it via Microsoft Marketplace for consolidated billing
  • Build an agent that answers support analytics questions and generates a dashboard that can be saved
  • Create custom skills to constrain agent behavior to specific instructions and formats (keep the agent “in a swim lane”)
  • Create custom tools backed by Elastic indexed data (e.g., policy lookup) and ES|QL queries
  • Use connectors/federated search to retrieve relevant documents from SharePoint and engineering issues from GitHub within the same agent conversation
  • Add a workflow step to post an approved summary into a Slack channel (with explicit user approval for write actions)
Code & CLI: ES|QLMicrosoft MarketplaceAzure Private LinkMicrosoft Entra ID
AIAgentsDeveloper
Session page ▶ Watch
LAB500 Lab From slides

Terminal to Party: Live-Coding with GitHub Copilot CLI and Hydra

Christopher Harrison, Toby Padilla

This lab walks you through using GitHub Copilot CLI to build a browser-based live-coding "vibes" app with code-generated music and Hydra visuals synced to it. It emphasizes agentic workflows in the CLI—planning, context/instructions, multiple agents, and tool permissions—using a starter project that combines Hydra with the GitHub Copilot SDK.

What's new
  • GitHub Copilot SDK positioned as a programmable SDK (“engine behind GitHub Copilot”) for adding agents to your own application
  • Copilot CLI supports managing MCP servers, custom agents, skills, plugins, and model selection via slash commands
APIs & SDKs
  • GitHub Copilot SDK — Programmable SDK for integrating Copilot-like agents into an application.
  • Hydra (hydra-synth) — Open-source live-codeable video synth and coding environment for browser-based visuals.
  • GitHub Copilot CLI — CLI workflow for planning and implementing changes with agents, models, MCP, reviews, diffs, plugins, and skills.
What you can build
  • Build a browser-based app with an in-page code editor that generates music from code and synchronizes Hydra visuals
  • Add in-app chat to “talk to Copilot” to create new visual/music themes and generate code
  • Use Copilot CLI agentic loops to plan, implement, review, and iterate on a multi-part project
  • Use instruction files and a PRD to provide durable context and improve Copilot outcomes
  • Manage tool permissions during development (reset permissions vs enable-all)
Code & CLI: https://github.com/hydra-synth/hydrahttps://hydra.ojack.xyz/docs/https://github.com/github/copilot-sdkhttps://awesome-copilot.github.comaka.ms/CopilotCLICommandsaka.ms/CopilotCLIBestPracticesaka.ms/CopilotCLIBeginnerTutorialgithub.com/features/copilot/cli/plan <describe what you're building>/agent/model/plan/mcp/cwd/cd/reset-allowed-tools/yolo/context/diff/review/skills/plugin
AgentsDeveloperGitHub CopilotGitHubGitHub ActionsOSS
Session page
LAB502 Lab From slides

Make GitHub Copilot Work Your Way: Custom Tools, Context and Workflows

Josh Johanning, Tiago Pascoal

This hands-on lab walks through shaping GitHub Copilot to match team workflows by creating and configuring custom agents, instructions, and agent skills. It also covers extending Copilot with plugins, using Copilot CLI, and connecting agents to external services via MCP across VS Code, Visual Studio, and CLI.

What's new
  • Build custom agents by defining roles, instructions, and tool scope
  • Create reusable Agent Skills for domain knowledge
  • Connect agents to external services using MCP, including a remote MCP server
  • Install a Copilot plugin from a marketplace
  • Use GitHub Copilot CLI in developer workflows
  • Bonus: use Copilot cloud agent
APIs & SDKs
  • GitHub Copilot CLI — CLI-based Copilot usage covered in the lab workflows.
  • MCP — Mechanism to connect agents to external services, including connecting to a remote MCP server.
What you can build
  • Build a Space Invaders game with Copilot assistance
  • Install and use a Copilot plugin from a marketplace
  • Explore agent customizations in Visual Studio Code
  • Author custom instructions to steer agent behavior
  • Author an agent skill and reuse it across workflows
  • Connect an agent to a remote MCP server
Code & CLI: https://aka.ms/build2026-LAB502github.com/github-samplesgithub.com/github-samples/pets-workshophttps://learn.github.com
AgentsDeveloperGitHub CopilotGitHubVisual Studio CodeMCP
Session page
LIVE199 Broadcast Stage From transcript

Imagine Cup World Championship

Patrick Brown, Rohan Ganesh, Surya Kukkapalli, Troy McBride, Vivaan Sawant, Advika Vuppala, Hans Yang

The Imagine Cup 2026 World Championship showcases three student-led startups pitching and demoing their products: CopyFlag (copyright infringement detection and takedowns), SpoilSafe (sensor-driven food spoilage predictions), and Revora Health (AI-agent-assisted physical therapy matching and support). The session also highlights founder lessons on trust-building, customer-driven pivots from “data” to “actions,” and turning personal pain points into products.

What's new
  • Imagine Cup 2026 grand prize increased from $100,000 to $150,000
  • CopyFlag named 2026 Imagine Cup World Champion
What you can build
  • Detect AI-modified copyright infringement by fingerprinting and searching the web for copies of uploaded content, then recommend takedowns based on a confidence threshold
  • Send takedown requests from an “Alert Center” workflow after user confirmation
  • Predict likely future infringement (“who, when, what”) using product history and seller data, and act on repeat-offender relationship maps in bulk
  • Collect volatile gas, temperature, and humidity sensor data in real time and output automated time-to-spoilage predictions for specific food batches
  • Compare storage-condition scenarios for the same food type and generate operational decisions (e.g., keep vs. discount immediately)
  • Use an AI agent to intake an injury description, match a patient to a physical therapist quickly, capture ongoing recovery insights, and forward them to the therapist to update a care program
Code & CLI: GitHub EducationReplit
AzureAgentsGitHubFoundry IQMicrosoft FabricMicrosoft for Startups
Session page ▶ Watch
LIVESP126 Broadcast Stage From transcript

Qualcomm quick take: Live from Microsoft Build

Ana Schafer, Morris Novello

A short broadcast interview from the Qualcomm space at Microsoft Build focused on Microsoft–Qualcomm collaboration for AI agents across devices. The speakers highlight tight integration with Foundry Factory and Windows ML, plus booth demos around porting apps natively and workflow automation for inference and orchestration across form factors.

What's new
  • Microsoft–Qualcomm partnership described as including tight integration with Foundry Factory and Windows ML
  • Booth/session demos described for AI agents that help developers port apps natively
  • Workflow automation for inference positioned as a way to reduce token usage and support orchestration across form factors
APIs & SDKs
  • Foundry Factory — Referenced as part of the Microsoft–Qualcomm tight integration for building AI-agent-related experiences and workflows.
  • Windows ML — Referenced as part of the Microsoft–Qualcomm tight integration supporting AI experiences and inference-related workflows.
What you can build
  • Build context-aware AI agents that pull data across multiple device types (e.g., ring, pendant) and extend up to the data center
  • Use AI agents to help port existing applications to run natively (as described in demos)
  • Automate inference workflows to reduce token usage and coordinate workloads across different form factors
AIAgentsDeveloper
Session page ▶ Watch
OD832 Pre-recorded From transcript

From workflows to agentic automation with Azure Logic Apps

Divya Swarnkar

This session introduces Logic Apps Automation, a new Logic Apps-based offering aimed at reducing setup friction while keeping enterprise controls for running agentic workflows in production. It also shows a managed “knowledge as a service” capability for RAG inside workflows and a tighter integration where Azure AI Foundry agents can be created/managed and invoked from Logic Apps with end-to-end operational visibility.

What's new
  • Azure Logic Apps Automation announced; available in public preview at auto.azure.com
  • Logic Apps “knowledge as a service” for managed RAG in workflows (upload files; automatic chunking/vectorization; retrieval as a workflow step); public preview
  • Logic Apps + Azure AI Foundry integration: pick Foundry agents from within a Logic Apps workflow, or create a new Foundry agent from Logic Apps via Foundry APIs and keep it in sync
  • Project/App governance model in Logic Apps Automation: project-scoped shared resources/policies plus app-level collaboration and permissions
  • Operational traces include per-step inputs/outputs, execution times/status, and token utilization; correlated run ID across Logic Apps and Foundry views
APIs & SDKs
  • Azure Logic Apps Automation · preview — Hosted Logic Apps experience at auto.azure.com with projects/apps, sandboxed agent execution, natural-language workflow scaffolding, and enterprise controls (RBAC, auditability, VNet support).
  • Logic Apps Knowledge (managed RAG) · preview — App-scoped knowledge base backed by Cosmos DB (vector store) and Azure OpenAI (embeddings + chat), with file upload, grouping, automatic ingestion/chunking/embedding, and retrieval used by agents in workflows.
  • Azure AI Foundry integration in Logic Apps — Invoke Foundry-hosted agents from Logic Apps workflows; browse agents in a Foundry project and create/provision a new agent from Logic Apps (via Foundry APIs) with deep links between portals and correlated logs.
  • GitHub Copilot SDK — Used for an “invoice agent” that runs on an isolated sandbox and can be provided business context plus skills (including support for MCPs) for reasoning/actions.
What you can build
  • Invoice processing workflow combining deterministic steps (e.g., ServiceNow ticket creation, Salesforce updates) with an agent for invoice validation
  • Document intake workflow where an agent classifies incoming documents and, if it’s a contract, validates against organizational approval rules grounded in an in-app knowledge base
  • Auto loan approval workflow orchestrating multiple Foundry agents (duplicate check + approval decision) with long-running human approval in Microsoft Teams
  • Enterprise agent operations: observe runs step-by-step with auditability, real-time streaming into actions, and token utilization per agent step
Code & CLI: auto.azure.comCosmos DBAzure OpenAIMicrosoft Entra IDGitHub Copilot agentsGitHub Copilot SDKMCPsAzure DevOpsGitHubMicrosoft TeamsARM RBAC
AzureAgentsDeveloperDevelopment pipeline
Session page ▶ Watch
OD840 Pre-recorded From transcript

Enable enterprise agents with Agent 365 SDK

Jeremiah Follis

This session explains how Agent 365 SDK helps make custom and third‑party agents enterprise-ready by layering observability, governance, and security onto existing agent stacks. It focuses on treating an agent as an "actor" with its own scoped identity, auditable actions, and admin-controlled access to tools and data, and shows how Microsoft Entra, Purview, and Defender outcomes light up once integrated.

What's new
  • Agent 365 was made generally available on May 1st along with the Agent 365 SDK
  • Agent 365 is natively integrated (no extra work) for agents built in Agent Builder, Copilot Studio, and Foundry so they show up automatically with identity/observability/governance/security
  • Agent 365 connects directly to third-party platforms including Vertex AI and AWS Bedrock, enabling agent registration via connected platform integration
  • Agent 365 SDK adds OpenTelemetry-based tracing for agent inputs/outputs, tool calls, and model invocations, with either Microsoft OpenTelemetry Distro (auto-instrumentation) or direct OTel endpoint injection
  • Agent 365 SDK enables admin-governed tool access including Microsoft 365 data via MCPs (mail, calendar, OneDrive, SharePoint, Teams) with auditable/revocable permissions and support for bringing/registering custom MCPs
  • Entra Agent ID can be enabled via the SDK to apply Entra controls (identity protection, conditional access, ID governance) to agents
APIs & SDKs
  • Agent 365 SDK · ga — Adds enterprise controls to existing agents (observability via OpenTelemetry tracing, governance for tool/data access, and security via Entra Agent ID integration).
  • Agent 365 CLI — CLI referenced by the Agent 365 team lead as part of the SDK/CLI toolchain for developers.
  • Microsoft OpenTelemetry Distro — Recommended path for Agent 365 SDK observability with auto-instrumentation for OpenAI, LangChain, and Agent Framework plus hooks for other components.
  • Purview APIs — APIs developers can use to wire Microsoft Purview data controls (e.g., sensitivity labels/DLP) into agents outside the Microsoft 365 surface area.
  • Entra Agent ID — Agent identity capability enabled through Agent 365 SDK so admins can apply Entra identity and access controls to agents.
What you can build
  • Register third-party or custom-built agents into an enterprise registry so admins can discover and manage them (addressing agent sprawl)
  • Instrument an existing agent with OpenTelemetry traces for end-to-end visibility into prompts, responses, tool calls, and model invocations
  • Enable Defender threat hunting for agents using the observability signals and investigate alerts in the Defender portal
  • Expose Microsoft 365 data access through admin-governed MCP tool access (mail, calendar, OneDrive, SharePoint, Teams) with revocable permissions
  • Apply Entra controls to an agent identity (audit logs, sign-in logs, conditional access, lifecycle/access governance)
  • Enforce Purview policies at runtime (sensitivity labels, DLP) on agent interactions with Microsoft 365 apps (e.g., Teams) and beyond via Purview APIs
Code & CLI: Agent 365 CLIOpenTelemetry (OTel) endpointMicrosoft OpenTelemetry DistroMCPsMicrosoft Defender portalMicrosoft 365 Admin CenterMicrosoft Entra audit logsMicrosoft Entra sign-in logs
SecurityAgent 365Responsible AIGovernanceEnterpriseIdentity
Session page ▶ Watch
OD849 Pre-recorded From transcript

Dataverse plugin: unleashing coding agents on the enterprise

Suyash Kshirsagar, Kent Weare

This session demos the Dataverse Skills plugin that gives coding agents guardrailed, tool-backed access to Dataverse schema, data, queries, security, and solution packaging. Speakers show three role-based flows (builder, DevOps analyst, admin) where plain-English prompts trigger multi-step operations like model creation, Excel imports with lookup resolution, CRM queries/updates, and security configuration with validation.

What's new
  • Dataverse Skills plugin enables natural-language, multi-step Dataverse operations from coding tools without requiring the org URL
  • Connection flow can discover the Dataverse environment from Microsoft sign-in, configure the MCP server, and verify connectivity from a single prompt
  • One prompt can create a Dataverse data model including tables, relationships (including many-to-many), plus a main form, a view, and package everything into a named solution
  • Plugin can import Excel reference data and resolve lookups using business keys (not GUIDs), then run validation queries (e.g., row counts, parent links)
  • Natural-language querying can scope results by named user (e.g., "Carlos") by resolving system-user identity and generating/running a Python-based query script
  • Admin flow includes pre-flight privilege verification, creation of security components (business units, roles, field security, access team templates), impersonation-style validation with a pass/fail matrix, and auditing enablement with checks across org/table/column layers
APIs & SDKs
  • Model Context Protocol (MCP) server — Agent integration point the plugin configures to connect tools to Dataverse operations (connection verification and subsequent guarded actions).
  • Python SDK — Used behind the scenes to generate and run scripts for tasks like querying Dataverse/CRM data and supporting import/query workflows.
  • Dataverse Skills plugin — A plugin providing guarded skills for Dataverse schema, data, query, security, and admin operations driven by natural-language prompts.
What you can build
  • Connect to a Dataverse environment using Microsoft sign-in without knowing the org URL, with automatic verification
  • Generate a complete Dataverse app data model from a business description (tables, columns, lookups, self-referential relationships, many-to-many), plus form and filtered view, inside a solution
  • Import multiple Excel files into newly created tables while resolving lookups via business keys and reporting failures
  • Run sanity-check queries like table row counts and relationship validation after imports
  • Query CRM data in plain English (e.g., open opportunities over a threshold, customers who haven’t reordered in N days) with automatic joins and date math
  • Automate admin/security changes via prompts: create business units/roles/field security/access team templates, assign users, validate access per user, share a single record via a team template, and enable auditing with layered checks
Code & CLI: MCP serverPython SDK
AgentsDeveloperGitHub CopilotVisual Studio CodeMCPData
Session page ▶ Watch
OD858 Pre-recorded From transcript

Your PC, Your Rules: AI Agents Meet Windows Personalization

Samantha Song

This session shows a concrete pattern for mapping natural-language personalization requests to real Windows changes via an MCP-backed “skill” contract (skill.md). It demos agent-driven Dynamic Lighting effects, Windows theme changes (wallpaper/accent/mode), and notification-triggered lighting, with emphasis on structured tooling, permissions/scope, and rollback as part of reliable OS automation.

What's new
  • Open-source Copilot skill repo for Windows personalization built around a skill.md contract agents can read and invoke
  • Agents can drive Windows Dynamic Lighting via public LampArray APIs to implement per-device, per-lamp animations
  • A theming module can orchestrate multiple OS changes in one intent (e.g., wallpaper + accent color + mode + lighting)
  • A notification watcher can react to Windows toast events to trigger lighting feedback (e.g., flash red on messages)
APIs & SDKs
  • Model Context Protocol (MCP) servers — Used as the tool interface that skills expose so agents can map prompts to structured tool calls and then to Windows personalization actions.
  • Windows LampArray APIs — Public APIs used to discover Dynamic Lighting devices and set per-lamp colors/animations (e.g., keyboard + lamp effects).
  • Windows toast notifications (event watching) — Watched to trigger reactive behaviors like flashing lighting on incoming notifications; described as resuming with no state loss.
What you can build
  • Generate and run custom Dynamic Lighting animations from a natural-language prompt (e.g., koi pond, campfire, shooting stars)
  • Apply a full “vibe” in one action: wallpaper + accent color + light/dark mode + RGB lighting
  • Sync lighting effects to on-screen content (described as reflecting colors on the screen while videos play)
  • Flash lighting cues for notifications by monitoring Windows toast events
  • Package and share a reusable skill interface via skill.md so multiple agents can invoke the same tooling
Code & CLI: skill.mdgithub.com/samanthamsong/windows personalization skillGitHub Copilot CLIC# driverPython effect scriptsrender frameMSIX package themesExplorer accent registry path
WindowsMCPAgents on WindowsPersonalizationWindows APIsDynamic Lighting
Session page ▶ Watch
ODSP900 Pre-recorded From transcript

Performance tuning on Cobalt with Arm Performix

David Haikney

This session demos Arm Performix, a performance analysis toolkit designed to profile and optimize workloads running on Azure Cobalt instances. It shows a workflow built around "targets" (remote systems accessed via SSH) and "recipes" (repeatable profiling/benchmark experiments), moving from system-level characterization to code-level hotspots and CPU microarchitecture analysis. The demo also highlights an MCP server integration to connect profiling results to an LLM for confidence-based optimization suggestions inside a dev workflow.

What's new
  • Arm Performix performance analysis toolkit (built in collaboration with Microsoft performance experts) for workloads on Cobalt
  • Performix provides both a UI and a CLI for running the same analyses
  • Performix includes an MCP server to couple profiling results with an LLM and suggest optimizations
  • Performix is available now, free to download and free to use
APIs & SDKs
  • Arm Performix MCP server — Exposes profiling runs (including system info, profiling data, disassembly, and source linkage) to an LLM for generating confidence-based optimization suggestions.
What you can build
  • Add a remote Cobalt instance as a profiling target using SSH credentials (host/user/port/keys)
  • Run system characterization microbenchmarks to validate instance-level performance (e.g., memory bandwidth vs access size / cache behavior)
  • Profile system utilization via heat maps across cores, either by launching a workload, attaching to a process, or profiling all processes
  • Find and attribute code hotspots back to source code across languages (including Java and .NET)
  • Compare profiling runs to understand changes across experiments (e.g., instruction mix differences such as NEON vs SVE implementations)
  • Use CPU microarchitecture analysis (top-down methodology) to identify cache behavior, stalls, and branch mispredictions
AutomationAzureComputeDeveloperGitHub CopilotLocal AI
Session page ▶ Watch
ODSP904 Pre-recorded From transcript

Build AI-powered collaboration on a visual canvas

This session shows Lucid’s AI features for generating and editing diagrams and whiteboard content directly from text prompts, plus AI-assisted ideation, sorting, and summarization on a shared canvas. It also demonstrates connecting an AI agent to the Lucid MCP server to create, fetch, share, and update Lucid documents programmatically as part of a developer workflow.

What's new
  • Lucidchart: generate diagrams from text prompts in the Lucid AI Prompt Editor, in an assisted layout container with auto-reflowing connectors
  • Lucidchart: update an existing AI-generated diagram (add/remove steps, change decisions/branches) via the AI tool, not only manual edits
  • Lucidspark: AI-powered mind map expansion and sticky-note idea generation (e.g., generate nine sticky notes from a prompt)
  • Lucidspark: sort selected sticky notes into AI-derived categories with optional custom instructions (e.g., by first letter, or by priority high/medium/low)
  • Lucidspark: summarize selected board content (noted as currently focused on content like diagrams/sticky notes/frames, with broader widget summaries mentioned as future work)
  • Lucid MCP server: enables searching, fetching, summarizing, sharing, and creating Lucid diagrams via an agent connection
APIs & SDKs
  • Lucid MCP server — Server an AI agent can connect to for searching, fetching, summarizing, sharing, and creating Lucid diagrams/documents programmatically.
What you can build
  • Turn a natural-language process description into a flowchart draft you can refine (with assisted layout and auto-adjusting arrows)
  • Generate BPMN choreography and sequence diagrams from prompts (example: loan application process)
  • Create ERDs from high-level instructions or pasted code describing classes and relationships
  • Generate network diagrams and cloud architecture diagrams (AWS/Azure/Google Cloud) with logical container grouping
  • Run whiteboard ideation: expand mind maps and generate/expand sticky-note brainstorms, then summarize or sort them into categories
  • Automate diagram workflows: have an agent create multiple diagrams from a codebase, share them with reviewers, then fetch reviewer edits and compare them back to the code
Code & CLI: GitHub (referenced: a BPMN converter repo used in the demo; specific repo name not provided)
AIAutomationDeveloperMCPAI Toolkit
Session page ▶ Watch
ODSP906 Pre-recorded From transcript

Apply orchestration patterns for production AI agents

Cliff Simpkins

UiPath presents Maestro as an execution/orchestration layer to take AI agents from demos to governed, observable, auditable production workflows with human approvals and durable state. The session focuses on Microsoft-first environments (Teams, Microsoft 365, GitHub Copilot, VS Code) and shows new/updated UiPath capabilities including Teams deployment for conversational agents, a developer-friendly Flow canvas, a case-management canvas for exception-driven work, and agentic testing in UiPath Test Cloud.

What's new
  • UiPath conversational agents can be deployed to Microsoft Teams via a standard Teams packaging process for 1:1 chat and channel workflows
  • GitHub Copilot can be given full context on UiPath via UiPath “skills” + UiPath CLI installed through NPM, enabling build/deploy/manage workflows from VS Code
  • Maestro Flow: a new developer-friendly orchestration canvas whose schema is natively supported by coding agents; Flow is in early access and planned to be publicly available “in the coming weeks”
  • Evaluations (test cases) are coming to end-to-end processes in Flow
  • Maestro Case: a new canvas for dynamic, exception-driven processes with rule/agent-driven stage activation and rationale in an execution trail
  • Agentic testing in UiPath Test Cloud: autonomous test case execution with Autopilot, autonomous exploration, and a “Delegate” assistant to handle testing admin work
APIs & SDKs
  • UiPath Maestro — Orchestration/execution layer for agentic processes with governance, observability, human approvals, durable state, retries/timeouts, and audit trails.
  • UiPath CLI · ga — CLI tooling to control/build/deploy/manage UiPath automations and integrate with coding agents; described as live now with GitHub Copilot support.
  • UiPath skills for GitHub Copilot · ga — Copilot skills installed via NPM to give Copilot context on UiPath platform APIs/CLI commands/deployment patterns.
  • Maestro Flow · preview — Developer canvas for Maestro processes with local files in VS Code, agent configuration inline, tracing, and support for coding-agent authored schemas.
  • Maestro Case — Case-management canvas for dynamic, exception-driven processes (parallel work, rework, escalations) with rationale/execution trail.
  • UiPath Test Cloud (Autopilot, Delegate) — Agentic testing capabilities for autonomous execution/exploration and automating testing admin tasks (results, reporting, issue filing).
What you can build
  • Deploy a UiPath-built conversational agent into Microsoft Teams for employees to submit info, check status, and receive updates
  • Model a long-running, multi-system enterprise process with human approval steps and trace/audit visibility using Maestro
  • Develop and version-control Flow orchestrations as local files in Visual Studio Code and review changes via Git
  • Add multi-trigger entry points to an orchestration (e.g., webhook trigger plus Outlook ‘email received’ trigger)
  • Build an invoice/billing-dispute orchestration with extraction, data lookups, discrepancy detection, approval tasking, ERP API calls, and notifications
  • Implement loan origination as an exception-driven case plan (rework, escalations, parallel underwriting) with agent/rule-driven stage activation
Code & CLI: NPM (install UiPath skills and CLI)Visual Studio CodeGitHub CopilotClaude CodeGemini CLIBPMN 2.0Outlook (email received trigger)webhook triggerPlaywrightAppiumSAPEpicCitrixJirauipath.com/developers
AIMS TeamsAgentsDeveloperGitHub CopilotGitHub
Session page ▶ Watch
ODSP907 Pre-recorded From transcript

Monitor GenAI applications beyond golden signals

Session explains why classic golden signals (latency, errors, traffic, saturation) are necessary but insufficient for GenAI apps due to non-determinism, variable cost, new attack vectors, and subjective quality. It proposes adding three monitoring dimensions—cost, safety/security, and quality—with concrete example metrics and tagging-based cost attribution.

What's new
  • GenAI observability should combine LETS (latency, errors, traffic, saturation) with three added dimensions: cost, safety/security, and quality
  • Cost attribution should be built via mandatory tagging at feature, user, model/provider, and endpoint (region/environment/provider) levels
  • Security monitoring metrics highlighted: prompt injection rate, PII detection rate, content moderation score, and jailbreak attempts
  • Quality monitoring metrics highlighted: hallucination rate, relevance score, user satisfaction, answer completeness, retrieval quality, and response coherence
  • Latency should be instrumented per pipeline stage (e.g., RAG retrieval time, LLM call time, total request time)
APIs & SDKs
  • Datadog Large Language Model Observability — Monitoring approach described as capturing LLM-call metrics (e.g., latency, errors, tokens/sec, API rate limit usage) plus cost, quality evals, tracing tool usage, and safety/security signals like PII masking and prompt injection detection.
What you can build
  • Break down end-to-end latency into RAG retrieval, LLM call, external API calls, and total request time to find bottlenecks
  • Segment error monitoring beyond HTTP codes to include model-provider errors (context length exceeded, safety filter triggered, model overloaded) by endpoint/model/user segment
  • Segment traffic by feature, user type, and model to manage capacity, model rate limits, and costs
  • Monitor saturation with emphasis on GPU utilization and model/API rate limits
  • Detect cost escalations from token creep, model drift, and uncached calls using granular cost attribution tags
  • Track GenAI safety/security risks (PII leakage/data exfiltration, prompt injection/jailbreaking, denial of wallet, model extraction) via dedicated security metrics
AIAutomationAzureAzure MonitorCost ManagementPlatform Engineering
Session page ▶ Watch
ODSP908 Pre-recorded From transcript

Streamline your end-to-end developer workflow with AI

Will Wang

Will Wang walks through a four-phase workflow for shipping a product end-to-end—ideation, building, team communication, and go-to-market—using AI to reduce friction. The session focuses on practical habits around GitHub Copilot in VS Code, Teams transcripts, and reusing tested prompts (including via Logitech MX hardware) to move faster while keeping documentation and follow-ups consistent.

What's new
  • Pattern: keep a separate AI chat/session per feature to avoid context-window spillover, and write a detailed handoff doc after each session for continuity
  • Pattern: standardize and reuse tested prompts (for docs, tests, outreach) to get more consistent AI output and reduce time spent rewriting instructions
  • Workflow: use Microsoft Teams meeting transcripts plus AI-written action items/docs to keep teams aligned and retain artifacts after calls
APIs & SDKs
  • GitHub Copilot (VS Code / Copilot Chat) — Used for writing code, generating documentation, and creating tests via prompts during feature development.
  • Microsoft Teams (transcription) — Used to capture call transcripts; paired with AI-written documentation/action items for team alignment.
What you can build
  • Generate code, tests, and documentation in VS Code with GitHub Copilot using reusable prompts
  • Create a per-feature development workflow where each feature has its own AI session and a written handoff doc
  • Run team meetings with an AI-generated HTML brief plus Teams transcripts to track decisions and action items
  • Capture product ideas quickly (notes + screenshots) during research/reading to avoid losing them
  • Go-to-market by posting where users gather (e.g., Twitter, Product Hunt, open source on GitHub) and running fast feedback loops via outreach messages
Code & CLI: VS CodeGitHub CopilotMicrosoft TeamsLogitech MX Master 4Logitech MX Creative Keypad
AIAgentsGitHub CopilotWindowsWindows DeveloperVS Code
Session page ▶ Watch
ODSP909 Pre-recorded From transcript

Take AI agents from prototype to production with OpenTelemetry

Harry Kimpel

This session shows how to make a multi-agent travel planner observable end-to-end by using the Microsoft Agent Framework with built-in OpenTelemetry tracing and sending telemetry to New Relic. It covers tracing agent/tool execution, adding custom spans/metrics and log correlation, plus adding eval-driven CI/CD quality gates and layered prompt-injection defenses that are also instrumented.

What's new
  • Microsoft Agent Framework includes built-in OpenTelemetry support to emit traces for agent runs and tool calls with minimal setup
  • OpenTelemetry log correlation adds trace/span context to logs so errors can be jumped to the originating trace/span
  • CI/CD quality gates driven by evaluation tests (LLM-based scoring) can fail builds when output quality drops below a threshold
  • Microsoft Foundry guardrails can be configured for jailbreak attempts, indirect prompt injection, and content safety and combined with evaluator-catalog evaluations
APIs & SDKs
  • Microsoft Agent Framework — Define agents (name/description/model/tools), orchestrate multi-agent/tool-calling loops, and emit built-in OpenTelemetry spans for agent invocations and tool calls.
  • OpenTelemetry — Standard instrumentation for traces/metrics/logs; uses OTLP exporter environment variables and enables trace/log correlation via trace/span IDs.
  • New Relic — Observability backend receiving OTLP telemetry and showing traces, correlated logs, dashboards, and alerts for performance, quality, and security signals.
  • Microsoft Foundry guardrails — Platform-level protections configurable for jailbreak attempts, indirect prompt injection, and content safety; can be paired with built-in evaluations from an evaluator catalog to produce metric scores.
What you can build
  • Instrument an agent app so every agent run becomes a trace with child spans for each tool call and durations/status codes
  • Identify bottlenecks by inspecting which tool or reasoning step dominates end-to-end latency
  • Add custom spans with business attributes (e.g., destination category) to filter and debug traces by domain context
  • Create custom metrics (counters/histograms) like itineraries per hour, average quality score, and cache-hit percentage for dashboards
  • Correlate logs to traces to jump from an error log to the exact failing span/tool call for faster root-cause analysis
  • Add layered prompt-injection defenses (platform guardrails + app-level detection) and instrument them to track attempts and guardrail effectiveness
Code & CLI: FlaskMicrosoft What the Hack repositoryWhat the Hack #073: New Relic agent observabilityGitHub CodespacesOTLP exporter (OpenTelemetry environment variables)New Relic endpointNew Relic API key (as mentioned for exporter configuration)
AIObservabilityReliabilityMonitorAgentsMCP
Session page ▶ Watch
ODSP912 Pre-recorded From transcript

Build agentic testing systems to validate AI generated code

This session argues that AI-generated code needs a deterministic validation layer because traditional testing and manual review can’t keep up with agent-written changes. Sparsh Kesari demos TestMu AI’s Kane CLI as an “agentic testing” approach: describe an end-to-end objective in natural language, run it in a local browser or headless from an agent, and get reproducible evidence plus generated Playwright code.

What's new
  • TestMu AI announced Kane CLI, a command-line validation layer for agentic end-to-end testing
  • Kane CLI can take natural-language objectives, execute them in a local browser, and optionally validate on cloud cross-browser/cross-device/cross-environment setups
  • Kane CLI generates Playwright test code by default from the natural-language objective
  • Kane CLI outputs agent-native NDJSON structured results intended to be readable by agents
  • Kane CLI provides shareable evidence (video logs and trace runs) plus a shareable link to review execution
APIs & SDKs
  • Kane CLI · announced — Command-line tool to run intent-based end-to-end validation (local browser or headless via an agent), generate Playwright tests, and emit shareable run evidence and NDJSON outputs
  • Kane SDK — SDK to import Kane into CI pipelines, custom agents, or tests
  • Playwright (generated output) — Kane CLI generates Playwright test scripts corresponding to the executed natural-language objective
What you can build
  • Turn a natural-language end-to-end objective into an automated browser run and a generated Playwright test
  • Run multi-step workflows that span multiple sessions (e.g., checkout, extract an order ID, use it in a second flow)
  • Integrate end-to-end validation into CI/CD by auto-playing tests defined in a markdown-based test.md framework
  • Use an AI coding agent (e.g., Claude/Codex/Copilot mentioned) to invoke headless end-to-end validation and consume NDJSON results
  • Capture trace/video evidence and share a replayable run link for review before merge/deploy
Code & CLI: Kane CLIKane SDK (import Kane)Playwright (generated test script)NDJSON output formatagent.mdtest.mdnpm module install (command not shown in transcript)
AIAutomationReliabilityResiliencyMonitorAgents
Session page ▶ Watch
ODSP914 Pre-recorded From transcript

Run AI at scale with Ray + Kubernetes using Anyscale on Azure

Daniel Arrizza, Katarina Stanley

This session walks through building an end-to-end AI workflow on Anyscale on Azure: multimodal data prep, distributed fine-tuning with PyTorch, batch embedding generation, and deploying an always-on inference service. The demo focuses on how Ray on AKS provides a Python-native distributed runtime with managed operational features like scaling, checkpointing, and observability inside an Azure subscription.

What's new
  • Anyscale on Azure runs Ray on Azure Kubernetes Service (AKS) inside your Azure subscription and is available through the Azure portal
  • Integrated with Microsoft Entra ID for RBAC
  • Managed Ray lifecycle on AKS, plus a priority-aware scheduler aimed at improving GPU utilization
  • Anyscale services support zero-downtime version updates and independent scaling of components
  • Ray Train checkpointing can resume after failures, including mid-epoch (as described in the demo)
  • Ray Data streams data to GPUs to keep utilization high, and can scale CPU nodes to avoid input bottlenecks
APIs & SDKs
  • Ray — Python distributed compute framework used here for data processing (Ray Data), distributed training (Ray Train/TorchTrainer), and model serving (Ray Serve) on AKS.
  • Ray Train (TorchTrainer) — Orchestrates distributed PyTorch training with scaling configuration (workers/GPUs) and checkpointing for resiliency.
  • Ray Data — Data pipeline layer used to stream training data to GPUs and scale CPU resources to keep accelerators fed.
  • Ray Serve — Serving framework used to compose multiple models behind an endpoint (image-to-text step + fine-tuned model) and return JSON responses.
  • PyTorch — Deep learning framework used for the fine-tuning and inference code within Ray-orchestrated training and serving.
  • Anyscale CLI — CLI shown for interacting with Anyscale (including listing "skills" intended to work with code AI assistants) and for creating jobs/services.
What you can build
  • Create an Anyscale cloud in Azure, selecting an existing AKS cluster or using a one-liner to create a cluster
  • Interactive development on a Ray cluster via workspace, including VS Code desktop SSH or web-based VS Code
  • Fine-tune an open-source model on multimodal product data using PyTorch wrapped by Ray Train with checkpointing
  • Generate batch embeddings across a large catalog and validate embedding similarity for recommendations
  • Deploy a recommendation API using Ray Serve that chains an image-to-text model and a fine-tuned model and returns JSON
  • Monitor and debug workloads using workspace metrics/logs and Ray workload observability to find bottlenecks
Code & CLI: Anyscale CLIanyscale skillsRay TrainTorchTrainerRay DataRay ServeAzure Kubernetes Service (AKS)Azure Container RegistryMicrosoft Entra ID
AIAzureCost ManagementObservabilityPlatform EngineeringReliability
Session page ▶ Watch
ODSP915 Pre-recorded From transcript

Resolve support cases with multi-agent workflows

Carlos Camacho

This session demos an open-source multi-agent system that routes support questions to specialized agents to diagnose and resolve issues across partner ecosystems. It shows deploying an Azure MCP server from the OpenShift AI MCP catalog onto Red Hat OpenShift, then using it via an Azure support agent with authentication/authorization and auditing via OpenTelemetry.

What's new
  • OpenShift AI MCP catalog provides pre-built MCP servers that can be deployed to a cluster (demo: Azure MCP server)
  • Catalog deployment handles container image, configuration, and authentication via managed identity (per demo description)
  • Multi-agent quickstart includes routing based on intent, agent access control, and an audit trail backed by OpenTelemetry events
APIs & SDKs
  • MCP (Model Context Protocol) — Used as the tool/server integration layer; Azure MCP server is deployed from a catalog and consumed by an agent without custom glue code.
  • ADK — Used to develop the agents in the demo (routing agent and support agents).
  • OpenTelemetry — Used to store events for audit logging and tracing of security and request outcomes.
  • Managed identity — Used for authentication when configuring the Azure MCP server deployment to connect to an Azure tenant.
What you can build
  • Deploy an Azure MCP server from an MCP catalog onto an OpenShift cluster and connect it to an Azure tenant
  • Build a chat-based support experience that routes user questions to specialized agents based on detected intent
  • Wrap an MCP server inside a domain-specific support agent and expose executed MCP tools/results back to the user
  • Enforce per-agent access control so users can be allowed/denied at request time
  • Capture an audit trail of requests and security events, and inspect accepted/denied outcomes via traces/logs
Code & CLI: PatternFlyAzure MCP serverOpenShift AI MCP catalogRed Hat AI secure MCP catalogAzure and Red Hat OpenShift AI (ARO)A2A
AIAzureObservabilityPlatform EngineeringVector EmbeddingsAgents
Session page ▶ Watch
ODSP918 Pre-recorded From transcript

Build persistent and scalable AI agent memory with TiDB

Ravish Patel

This session shows how to implement persistent AI agent memory using TiDB with a single SQL table that supports chat/state storage plus semantic, keyword, and hybrid retrieval. The demo walks through auto-generating embeddings on insert via an Azure OpenAI deployment, running vector search and full-text search, combining them with RRF, and using ACID transactions for multi-table agent updates.

What's new
  • Single-table setup for agent memory: SQL columns + vector search + full-text search on the same table
  • Automatic embeddings on insert using a SQL function (embed_text) that calls an Azure OpenAI deployment
  • Hybrid retrieval implemented as vector search + keyword search + Reciprocal Rank Fusion (RRF) ranking in SQL
  • ACID transactions across tables for multi-step agent writes (e.g., insert memory + update per-user aggregates)
  • TiDB features positioned for agent workloads: scale-to-zero, database branching per agent, resource control, fast scale-out (separate compute/storage)
APIs & SDKs
  • TiDB SQL function embed_text — Generates vector embeddings from inserted text by calling an Azure OpenAI deployment and storing the vector in a generated column.
  • TiDB vector search (HNSW index) — Stores embeddings in a vector column and supports similarity search via a vector index for semantic recall.
  • TiDB full-text search (multilingual parser) — Keyword search using a full-text index that supports multiple languages for exact term matching.
  • TiDB Python SDK (pytidb) — Python SDK claimed to provide hybrid search and RRF in a few lines.
  • TiDB MCP server + agent rules — MCP server and agent rules for integrating TiDB into Cursor/Claude workflows.
What you can build
  • Persist agent chat history and per-user state in SQL while enabling retrieval for context recall
  • Run semantic recall over past memories using vector similarity search without a separate vector database
  • Run keyword lookups (e.g., cities, identifiers) using full-text search on the same table
  • Implement hybrid retrieval (semantic + keyword) with RRF to improve relevance for agent memory queries
  • Perform reliable multi-step agent updates with transactions across memory and aggregate “facts” tables
Code & CLI: pip install pytidbgithub.com/pingcap/agentrulestidb.compingcap.com/ai/agenticai
AIAzureStorageVector EmbeddingsAgentsDeveloper
Session page ▶ Watch
ODSP919 Pre-recorded From transcript

Move from data to intelligence with Oracle MCP and Microsoft IQ

Ram Kakani, Jeff Smith

This session shows how to build an enterprise agent in Azure AI Foundry that queries Oracle Database@Azure through an Oracle-managed Model Context Protocol (MCP) server, while using Microsoft IQ components for reasoning and work-context orchestration. The demo walks through wiring an agent to an Oracle Remote MCP Server, grounding it with documents from OneLake and Azure Blob Storage, and using Work IQ to draft an Outlook email based on live Oracle data and ongoing email threads.

What's new
  • Oracle offers managed, hosted MCP servers for Oracle databases in Oracle Cloud Infrastructure and for Oracle Databases running at Azure, with the MCP server itself at no additional cost (pay only for database/AI usage).
  • Azure AI Foundry agents can connect to an "Oracle Remote MCP Server" tool via a catalog entry by providing endpoint plus region and OCID, with key-based or OAuth-based authentication.
  • Oracle MCP access can be granted via Azure Entra ID users and group membership, using an OAuth 2 on-behalf-of (OBO) flow so the agent acts on the user’s behalf and the database sees the end-user identity.
APIs & SDKs
  • Model Context Protocol (MCP) — Protocol used by agents (MCP clients) to call tools exposed by an MCP server, including patterns like natural-language-to-SQL via an Oracle MCP tool.
  • Oracle managed MCP server (Oracle Database@Azure / OCI) — Managed, hosted MCP server that exposes Oracle-database-backed tools to MCP clients/agents; configurable tools and authentication; integrates with Azure Entra ID identities via groups.
  • Foundry Agent Service — Hosts agents and an MCP client with native MCP support that can point to an MCP server (shown with Oracle MCP server).
  • Microsoft IQ (Foundry IQ, Fabric IQ, Work IQ) — Used for reasoning/grounding (Foundry IQ), historical analytics (Fabric IQ), and work-context delivery plus actions like email drafting (Work IQ).
  • Microsoft Entra Agent ID — Gives each agent an identity with least-privilege scoping (governance plane).
  • Agent 365 Governance — Tenant-wide inventory and governance for agents (as described in the governance plane).
What you can build
  • Build an AP analyst agent in Azure AI Foundry that runs live reads against Oracle Database@Azure via an Oracle Remote MCP Server (no ETL).
  • Ask natural-language questions (e.g., unpaid invoices over a threshold across a time window) and have the agent translate to SQL and run queries through MCP tools with human-in-the-loop approval.
  • Ground agent recommendations using a knowledge base built from compliance reports in Microsoft OneLake and vendor/contract documents in Azure Blob Storage.
  • Use Work IQ to search relevant Outlook email threads, summarize what was agreed, and generate a draft reply email based on current Oracle invoice status.
Code & CLI: OCI SDK (referenced as prior boilerplate code developers used to write for setup and connections)
AIAPIAgentsMCPDataApp Integration
Session page ▶ Watch
ODSP923 Pre-recorded From transcript

Create enterprise apps with AI and MCP

Jason Beres

This session demos building enterprise UI quickly using Infragistics Ignite UI components, App Builder (low-code WYSIWYG), and VS Code with MCP servers plus Agent Skills. Jason Beres shows generating a CRM-style app, publishing code to GitHub, then using Copilot-driven prompts to add a fully featured data grid and to generate a dashboard UI from an image using Ignite UI for Blazor.

What's new
  • Infragistics announced a new WinUI component suite at Build 2026
  • Ignite UI CLI can generate VS Code MCP configuration (mcp.json and MCP servers) via an AI config command
  • Ignite UI Agent Skills can be installed (e.g., from igniteui/igniteui-blazor) and used with tools including GitHub Copilot and Claude Code
  • App Builder can publish generated apps to GitHub, Azure DevOps, or as a downloadable zip
APIs & SDKs
  • Ignite UI (Infragistics UI components for Angular/React/Blazor/Web Components) — Component library used to build enterprise UIs (data grids, charts, theming) with consistent APIs across supported web frameworks.
  • Infragistics App Builder — Low-code WYSIWYG tool with conversational AI to assemble screens, enable grid features, apply themes, and export to framework-specific code (e.g., Blazor, React).
  • Ignite UI CLI — CLI used in the demo to add AI/MCP configuration into a VS Code project and to support theming and skill-driven agent workflows.
  • Ignite UI MCP servers — MCP servers started from VS Code to let agents consult Ignite UI tooling/knowledge when modifying the app based on prompts.
  • Ignite UI Agent Skills (e.g., igniteui/igniteui-blazor) — Installable skills that guide agents to generate/modify Ignite UI apps (theming, grids, and generating Blazor UI from an image design).
  • Infragistics WinUI component suite · announced — New WinUI components including data grid, charts, geospatial maps, inputs, and a Dashboard Tile; shown with XAML usage like Infragistics XamCategoryChart.
What you can build
  • Create a CRM-style enterprise app UI via App Builder, then export production code for Blazor Server or React
  • Enable rich data grid capabilities (group by, filtering, column moving/pinning/resizing/hiding, exporting) with minimal or no hand coding
  • Publish generated app code to a new GitHub repository directly from App Builder, then clone and iterate in VS Code
  • Use Copilot prompts plus MCP servers/skills to add a new grid bound to JSON data, including logo image rendering and multi-row collapsible headers
  • Generate a Blazor dashboard UI from a screenshot/image and iterate on the result with an agent (bind to live data, add screens, tweak layout)
  • Build WinUI desktop apps with Infragistics components and customize via Copilot chat, using consistent APIs across Infragistics platforms
Code & CLI: .NET runIgnite UI CLI (AI config)GitHub skill installigniteui/igniteui-blazorVisual Studio CodeGitHub CopilotClaude Code
AICopilotAgents.NETDeveloperVisual Studio Code
Session page ▶ Watch
ODSP925 Pre-recorded From transcript

Deliver production-ready AI search on unstructured data with RAG

This session explains core RAG concepts (vs. context- and cache-augmented generation) and why production RAG is complex due to many moving parts across ingestion, embeddings, retrieval, evaluation, and UI. It then walks through a vendor-provided approach (Progress Agentic RAG) and a demo using a .NET/Blazor app calling a C# SDK to return both conversational answers and structured JSON for charting from ingested PDF financial statements.

What's new
  • Progress Agentic RAG positioned as a managed "RAG as a service" platform with document ingestion, agent-driven extraction, and hybrid retrieval (keyword, semantic, graph) with agent reranking
  • Built-in evaluation agent/metric called "REMi" described as monitoring system stability as data is ingested and retrieved
  • SDK availability stated for .NET, TypeScript/JavaScript, and Python, plus REST APIs for deeper customization
  • An HTML widget builder is shown for quickly embedding a search experience with citations/retrieval into a web page
APIs & SDKs
  • Progress Agentic RAG C# SDK — Used from a Blazor Server app to call a search interface and an "AskAsync" method that can request a typed/structured response mapped into a JSON schema and deserialized back into a .NET object for rendering (e.g., charts).
  • Progress Agentic RAG REST APIs — Mentioned as available for building custom agents, custom UIs, or complete application architectures.
  • Progress Agentic RAG SDKs for TypeScript/JavaScript and Python — Mentioned as available for more complex scenarios beyond the built-in widget approach.
What you can build
  • Build a RAG pipeline that chunks large documents, embeds content, stores vectors, retrieves semantically similar passages, and grounds LLM answers with citations
  • Ingest unstructured sources (PDFs, Office files, images, video, audio/MP3, chat logs, websites/sitemaps) and query them with natural language
  • Use agentic retrieval to rerank results and extract tags/entities/key texts during ingestion
  • Create an embedded search widget via HTML snippets for quick deployment
  • Build a custom Blazor Server dashboard that queries PDFs and returns both narrative answers and structured data suitable for chart components
Code & CLI: AskAsync (Progress Agentic RAG C# SDK method)Blazor ServerTelerik UI for BlazorHTML widget builder / HTML snippetsprogress.com
AIAgentsDeveloperDeveloper Technologies
Session page ▶ Watch
ODSP926 Pre-recorded From transcript

Build collaborative agents into apps with APIs

Ziv Navoth, Edo Segal, Gillian Sheldon

This session demos Napster's Azure-native Omniagent API for deploying real-time multimodal (video + voice) agents inside applications. It focuses on making these agents cost-effective at scale, easy to provision from the Azure portal, deployable across web/mobile/phone/text channels, and fully monitorable with transcript, tool-call, and memory auditing.

What's new
  • Omniagent API runs at $0.01 per render minute when you bring your own LLM (positioned as ~20x cheaper than alternatives)
  • Omniagent API is Azure Native: provisioned from the Azure portal and billed as a line item on the Azure invoice
  • Browser-side SDK connects over HTTPS and WebRTC via Azure Front Door/load balancing; private endpoint support mentioned
  • Omniagent runtime uses AKS auto-scaled pods plus a rendering pipeline on dedicated Azure VM clusters streaming synchronized video over WebRTC
  • Cross-channel deployment described: web (WebRTC), native apps (WebSocket voice streaming), phone (SIP/VoIP inbound calls), and text messaging
  • Optional cross-channel memory: the API can extract facts/summarize and carry context forward across channels with read/write visibility in monitoring
APIs & SDKs
  • Napster Omniagent API (REST API) · ga — Create/configure agents (persona, knowledge, FAQs, tools), deploy to channels, enable memory, and inspect sessions including transcripts and tool calls.
  • Omniagent browser-side Web SDK — Embeds and renders a real-time video agent in a web app; opens HTTPS + WebRTC connections (described as going through Azure Front Door/load balancing).
What you can build
  • Embed a lifelike real-time video concierge on a pricing page, help center, or onboarding flow in a web app
  • Add a voice-first agent to native mobile/desktop apps by streaming real-time voice via a WebSocket handler
  • Run an after-hours support line where the agent answers inbound SIP/VoIP phone calls on a normal phone number
  • Route the same agent through a text/messaging channel while keeping the same tools and memory
  • Build a field-service assistant that pulls service history, orders parts, and schedules inspections via tool calls
  • Audit and iterate agent behavior using per-session transcripts, tool invocation logs, and memory read/write traces
Code & CLI: Azure portalAzure Front DoorAzure Kubernetes Service (AKS)WebRTCWebSocketSIPVoIPAzure OpenAIAzure PolicyMicrosoft DefenderAzure DDoS Protection
AIAzureAPIAgentsFoundry AgentsDeveloper Technologies
Session page ▶ Watch
ODSP928 Pre-recorded From transcript

Run AI SREs without burning token budgets

Natan Yellin

This session breaks down why AI SRE alert investigations often cost around $2 each, making “run it on every alert” economically hard at enterprise alert volumes. It focuses on where the cost really comes from (input tokens) and practical optimizations—especially LLM-native alert grouping and reuse of prior context—to bring per-alert spend into a viable range.

What's new
  • Typical underlying LLM cost per SRE-style investigation is described as ~$0.50–$5, dominated by input token spend
  • Context/runbooks (memory/skills) can reduce investigation cost by ~20–30% by avoiding repeated environment/tool rediscovery
  • LLM-native alert grouping can reduce spend by avoiding linear re-investigation of duplicate alerts during incidents
  • Reusing a prior context window for the same root cause can reduce cost; additional savings if the context is still in the model provider cache (example given: a five-minute cache hierarchy)
APIs & SDKs
  • Anthropic prompt caching (five-minute cache hierarchy) — Reusing a hot context window to reduce repeated context input cost during reinvestigations.
What you can build
  • Estimate annual LLM spend for running an AI SRE investigation on every alert given alert volume and per-investigation cost
  • Optimize an alert-triage agent by reducing input-token volume and repeated context discovery
  • Add runbooks/memory so an SRE agent doesn’t re-learn how to query the organization’s observability tools each time
  • Group duplicate alerts during outages using LLM-generated grouping rules rather than deterministic matching
  • Reuse investigation context across re-triggered alerts for the same root cause to reduce token costs
  • Run investigations on all alerts and escalate to humans only when the agent detects higher importance
AIObservabilityOutagesPlatform EngineeringReliabilityResiliency
Session page ▶ Watch
ODSP930 Pre-recorded From transcript

Low-latency AI for developer workflows

Speakers from Cerebras and OpenAI discuss how very fast inference changes how developers use coding agents, shifting from occasional prompts to always-on automation. They demo Codex Spark as a lighter, faster Codex variant running on Cerebras Inference, and walk through examples spanning workplace monitoring, OSS maintenance, and rapid interactive UI edits.

What's new
  • Codex Spark is described as a lighter, faster version of Codex running on Cerebras Inference
  • Codex Spark supports defining multi-agent workflows, including a main agent that spawns fast sub-agents
  • Positioning: Spark is "v1" today, with claims that models on Cerebras will get smarter over time
APIs & SDKs
  • Codex Spark — A faster/lighter Codex experience used inside the Codex app, including multi-agent task decomposition and interactive coding.
  • Cerebras Inference — Inference runtime/hardware stack mentioned as what Codex Spark runs on to achieve low latency.
  • Codex — A slower, more capable model referenced as the alternative to Spark for longer tasks.
What you can build
  • Slack monitoring automation that summarizes topics and tracks product launches
  • Multi-agent daily briefing that reads Slack, Google Drive, and Google Meets to infer priorities and responsibilities
  • Daily open-source maintenance job that checks PRs and issues, flags duplicates, and triages pipeline status
  • Automated PR workflow that pulls down changes, reviews code and comments, applies fixes, and pushes updates
  • Interactive UI iteration where the model makes rapid code edits aligned to specific styling and layout instructions
AIAgentsDeveloperGitHub CopilotVS CodeDevTools
Session page ▶ Watch
ODSP933 Pre-recorded From transcript

Agentic infrastructure needs agentic observability

This session argues that traditional observability (logs, traces, dashboards, alerts) was built for humans investigating deterministic systems, and those assumptions break when agents write, operate, and debug software. It outlines why agent workflows produce “reasoning trails” rather than simple event logs, why sampling and status codes (e.g., 200 OK) become unreliable signals, and why telemetry sensitivity and instrumentation velocity force a new observability architecture. The proposed direction is an “agentic” observability layer that reasons over complete telemetry, separates LLM intent from deterministic backend analysis, and raises new governance questions about autonomy and guardrails.

What's new
  • Proposes a shift from human-centric observability to “agentic observability” where the consumer of telemetry is an agent, not a human
  • Advocates an architecture pattern: “move the LLM up; push the analysis down,” with LLMs orchestrating investigation over deterministic analytics close to the data
  • Calls out “BYOC (bring your own cloud)” as a design choice to keep sensitive telemetry inside the customer’s cloud
  • Argues for “zero instrumentation / zero friction” because manual instrumentation cannot keep up with AI-generated services and workflows
What you can build
  • Investigate agent failures by reconstructing the agent’s decision path (documents chosen, tool retries, policy blocks) rather than only infrastructure events
  • Run intent-driven incident investigation (“Why did this fail?”, “What changed?”, “Which customers were impacted?”) with an agent producing answers and next actions instead of dashboards
  • Adapt telemetry collection dynamically for agent workflows (raise fidelity, instrument on the fly) as systems evolve
  • Feed structured production telemetry directly into coding agents and CI/CD systems rather than manually copying screenshots of dashboards into chat tools
  • Design telemetry pipelines that account for nondeterminism where identical inputs may lead to different decisions and outcomes
Code & CLI: MCP
AIObservabilityAgentsAgent Observability
Session page ▶ Watch
ODSP934 Pre-recorded From transcript

Unlock Claude in Microsoft Foundry

Keiji Kanazawa, Caroline Matthews

This session introduces how to use Anthropic Claude models inside Microsoft Foundry to build and run enterprise agents with governance, security, and observability. It covers Claude model selection (Opus/Sonnet/Haiku), demos an MCP-backed cupcake ordering agent, and shows a hosted-agent support/ops workflow with tracing, artifacts, and evaluations in Foundry.

What's new
  • Claude models are available in Microsoft Foundry (Opus, Sonnet, Haiku); the demo uses Claude Sonnet 4.6
  • Foundry Agent Service supports open standards/protocols including MCP and an agent-to-agent protocol, and can run multi-agent workflows
  • Hosted agents in Foundry Agent Service run custom-code agents in a hosted container sandbox with secured/authenticated access to Foundry resources and connected tools
  • Claude Agent SDK (the harness behind Claude Code) is programmable in Python and TypeScript and provides an agentic loop plus built-in tooling (code execution, file system, web search, to-do list, MCP, custom tools)
  • Foundry provides session history, traces/tool-call playback, and artifact storage (e.g., markdown summary, charts) for agent runs, plus monitoring and evaluations
APIs & SDKs
  • Microsoft Foundry Agent Service — Service for building/running AI apps and agents (including hosted agents), connecting to models, data sources (e.g., Foundry IQ), tools/MCPs, and operating with observability/evaluations.
  • Claude Agent SDK — Programmable agent harness (Python/TypeScript) powering Claude Code; provides agent loop, context management, sessions/memory, permissions, lifecycle hooks, sub-agents, error handling, and observability with tools like code execution, file system, web search, to-do list, MCP, and custom tools.
  • Anthropic Foundry client (Foundry SDK) — Client used in the demo to connect code to Claude deployments in Foundry using model + API key + base URL (with an option for keyless deployment mentioned).
  • Model Context Protocol (MCP) — Protocol used to package agent instructions and tools; demo shows using a public MCP server and notes private MCPs via authorization headers.
  • Microsoft 365 Graph — Cited as an example enterprise knowledge/tool source agents can connect to for deep business context.
What you can build
  • Build a code-driven agent that uses an MCP server for instructions + tools (e.g., ordering workflow) and runs against a Claude deployment in Foundry
  • Run long-horizon operational workflows (weekly ops review) that pull from incidents/support tickets/communications, then generate reports, forecasts, and stored artifacts
  • Deploy custom-code agents as hosted agents in Foundry Agent Service for secure execution and authenticated access to models and enterprise tools
  • Trace and audit agent sessions: inspect turns, tool calls, and replay execution steps inside Foundry
  • Set up early and continuous evaluations across quality, risk/safety, and agent/tool-use metrics; run them in Foundry UI and programmatically to detect drift/regressions
Code & CLI: VS CodeGitHub Copilot CLIClaude CodeLangChainLangGraphMicrosoft EntraMicrosoft PurviewMicrosoft Defender
AIAgentsDeveloperMicrosoft FoundryResponsible AIMCP
Session page ▶ Watch
ODSP937 Pre-recorded From transcript

Build realtime multimodal agents with LiveKit and Azure

Jesse Hall

This session walks through building a low-latency, real-time voice agent using LiveKit’s WebRTC-based media infrastructure and Azure models for speech-to-text, LLM, and text-to-speech. It focuses on practical issues like latency, turn detection, interruption handling, and scaling, then demos an end-to-end agent that answers questions about Microsoft Build.

What's new
  • LiveKit provides an open-source, WebRTC-based real-time media layer (voice/video/data) with an Agents SDK for Python and TypeScript
  • LiveKit supports a cascaded voice pipeline (VAD → STT → LLM → TTS) and is model-agnostic, with Azure usable for STT, LLM (via Azure OpenAI), and TTS
  • LiveKit offers an MCP docs server to keep coding agents up to date with LiveKit’s documentation
APIs & SDKs
  • LiveKit Agents SDK (Python) — Implements the orchestration layer for real-time agents; connects WebRTC media to STT/LLM/TTS and custom logic/tools.
  • LiveKit Agents SDK (TypeScript) — TypeScript option for building the same agent logic to run across devices and clients.
  • LiveKit Azure plugin — LiveKit plugin used in the demo to wire Azure STT, Azure-hosted OpenAI LLM, and Azure TTS into the agent.
  • Azure Speech-to-Text (STT) — Transcribes user audio to text in the cascaded pipeline.
  • Azure Text-to-Speech (TTS) — Generates spoken audio for the agent response; demo sets a specific voice in code.
  • Azure OpenAI (LLM via Azure deployment env vars) — LLM used to generate assistant responses from transcribed text in the demo agent.
What you can build
  • Build a real-time voice assistant that streams microphone audio over WebRTC and speaks responses back with low latency
  • Run an agent with a cascaded pipeline (VAD → STT → LLM → TTS) and swap models with minimal code changes
  • Deploy the real-time media layer either self-hosted (open source) or via LiveKit Cloud
  • Connect web (React) front-ends to a named agent session identifier to join the same agent session
Code & CLI: LKAppCreateAgentStarterPython templateReactStarter templateAgent.pyuv syncuv run agent.py download-filesuv run (dev mode)pnpm installpnpm devSilero VAD
AIAzureAgentsDeveloper
Session page ▶ Watch
ODSP940 Pre-recorded From transcript

Create enterprise AI apps at scale with Bolt and Microsoft

Joe Keyes, William Sayer

This session demos how Bolt fits into Microsoft-centric workflows to move from Copilot-driven requirements to governed, production-ready apps. The speakers show using enterprise design systems, a Bolt CLI workflow for seeding approved components, and collaborative app iteration in Bolt with auth, secrets, and a simple server function that calls an OpenAI model.

What's new
  • Copilot can hand off a structured project brief directly to Bolt via a Bolt agent to start building from captured requirements
  • Bolt CLI can bundle and publish an organization’s design system/component library into Bolt for reuse across projects
  • Bolt supports “Plan mode” to review an agent’s implementation plan before executing changes
  • Bolt can add email-based user authentication with optional Google sign-in, plus user management UI
  • Bolt includes secrets management used to store an API key and wire it into a server function
  • Bolt can publish a live site after an inbuilt database security scan reports no issues
APIs & SDKs
  • Bolt CLI — Programmatic interface to bundle/publish design systems and bring approved assets/repos/workflows into Bolt projects.
  • Microsoft Copilot (agent) — Used to turn conversation into a structured brief and to trigger Bolt actions (summarize for Bolt, then build).
  • OpenAI API (GPT-5) — Called from a generated server function to turn trip inputs into an itinerary; API key stored via Bolt Secrets.
What you can build
  • Convert a Copilot conversation into a project brief and send it to Bolt to generate a starter web page/template
  • Iterate on UI changes by tagging the Bolt agent in team conversations to apply edits to the project
  • Publish a team-approved component library/design system into Bolt and generate new pages using those components
  • Add email login and account-based saving to a generated app, with optional Google sign-in
  • Create a server function that calls an external model API and updates UI state (spinner + refreshed modal) while waiting
  • Publish a Bolt-built app to a live site after running the built-in database security scan
Code & CLI: bolt.newVS Codepackage.jsonStorybookprivate NPM registryOpenAI GPT-5
AIAzureAgentsDeveloper
Session page ▶ Watch

Foundry & models

BRK209 Breakout From abstract

Japan Wrap-up Session

Tadashi Okazaki

A Japanese-language recap of the key announcements and technical takeaways from the first two days of Microsoft Build. It is positioned to help Japan-based developers understand Build’s technical direction and identify practical next steps for applying it within products and teams.

What you can build
  • Get a Japanese-language overview of major Build announcements and technical insights
  • Translate Build technical direction into actionable next steps for your product/team
AzureSecurityGitHubWindowsMicrosoft FoundryData
Session page ▶ Watch
BRK241 Breakout From transcript

From prototype to production: build and run agents at scale

Tina Schuchman, Jeff Hollan, Takuto Higuchi

This session walks through an end-to-end lifecycle for building agents locally and moving them into a hosted, enterprise deployment using Foundry Agent Service and Microsoft Agent Framework. The demo focuses on a fiber outage response scenario, covering tool/knowledge grounding via Foundry Toolbox, publishing to Teams/Microsoft 365 Copilot with agent identity, and operating agents with tracing, evaluations, and optimizer-driven iteration.

What's new
  • Microsoft Agent Framework v1.0 is production ready and includes a built-in agent harness for secure code execution
  • Foundry Toolkit for VS Code is generally available
  • Voice Live integration with Foundry Agent Service is generally available for prompt agents, and in public preview for hosted agents
  • Hosted agents in Foundry Agent Service are generally available soon (per-session sandbox isolation, sub-second cold start, zero idle time cost)
  • Routines in Foundry Agent Service are in public preview to schedule/proactively wake agents
  • Rubric for custom evaluation is in public preview; Agent Optimizer in Foundry Agent Service is in private preview; Procedural memory in Foundry Agent Service is in public preview
APIs & SDKs
  • Microsoft Agent Framework · ga — Framework used to orchestrate multi-step/multi-agent workflows; includes a built-in harness for executing shell commands and read/write/execute code in a secured environment.
  • Foundry Toolkit for VS Code · ga — VS Code extension to build/debug Foundry agents in-editor, including access to models plus tracing and evaluation workflows.
  • Foundry Agent Service (hosted agents) · announced — Managed runtime to host and scale agents with per-conversation/per-routine isolated sessions, durable state, file system access, and zero idle time cost.
  • Foundry Toolbox · announced — Central tool management via a single MCP-compatible endpoint, with authentication handling, guardrails (e.g., preventing PII leakage), and optional "Tool Search" to return only relevant tools per task.
  • Routines (Foundry Agent Service) · preview — Scheduling/event mechanism to proactively trigger agents (e.g., hourly heartbeat to check logs/anomalies and alert/dispatch workflows).
  • Agent Optimizer (Foundry Agent Service) · preview — Optimization loop that uses production traces/evals to propose ranked candidate variants by tweaking prompts, skills, tool configuration, and models, with developer-controlled promotion/rollback.
What you can build
  • Prototype an agent locally in VS Code, debug it (F5), and connect it to tools through a single MCP-compatible Toolbox endpoint
  • Ground an operations agent on enterprise sources (e.g., Fabric IQ, Work IQ, Web IQ, Foundry IQ) and add document extraction via Content Understanding for PDFs/contracts
  • Voice-enable an agent via Foundry Agent Service Voice Live for hands-busy field scenarios
  • Run long-running autonomous agents using hosted agents with per-session isolation and durable state/file system persistence
  • Set up proactive monitoring via Routines (e.g., hourly anomaly checks) and incorporate human approval gates with durable state
  • Publish agents into Microsoft Teams / Microsoft 365 Copilot with agent identity (including email address and Teams presence) and autopilot behavior
Code & CLI: GitHub Copilot CLIClaude CodeVisual Studio CodeFoundry Toolkit (VS Code extension)azdazd ai agent eval initazd ai agent optimizeOpenClawHermes agentsDurable Task SchedulerGitHub Copilot SDKClaude Agent SDKaka.ms/build/evals
SecurityDeveloperGitHub CopilotMicrosoft FoundryFoundry AgentsScaling
Session page ▶ Watch
BRK246 Breakout From transcript

Foundry IQ: Fuel agents with enterprise knowledge and agentic retrieval

Pablo Castro, Allison Sparrow

This session walks through Foundry IQ as a context-engineering and retrieval platform for grounding agents in enterprise and external knowledge. It demos creating Knowledge Bases, connecting multiple knowledge sources (files, Blob/OneLake, Work IQ, Fabric IQ, and MCP-based sources), and using built-in agentic retrieval with evaluations and token-efficiency improvements.

What's new
  • Foundry IQ Serverless tier is in public preview: usage-based, scales to zero, and can be created in ~10–20 seconds
  • Knowledge Bases are exposed as MCP servers by default (no extra hosting required), reachable via a /mcp endpoint
  • Foundry IQ integrates with Azure Content Understanding for OCR, layout/table handling, PDF-to-markdown generation, and multimedia extraction/verbalization inputs
  • 2nd-generation agentic retrieval pipeline improvements: dynamic retrieval loop, enhanced semantic ranker, improved answer synthesis, and model-variant adaptation (evals published)
  • Enterprise security: Entra-based identity propagation, document-level ACL enforcement in indexes, and Microsoft Purview sensitivity label support
APIs & SDKs
  • Foundry IQ Retrieval API — Retrieve grounding evidence from a Knowledge Base with agentic planning/iteration, citations, and source metadata.
  • Azure AI Search Search API — Core retrieval layer used by Foundry IQ for lexical, vector, and hybrid search and ranking.
  • MCP endpoint for Knowledge Bases (/mcp) — Use a Knowledge Base as an MCP server so agents (e.g., Copilot) can query it via tools.
  • Azure Content Understanding — Extraction mode for ingestion: OCR, layout/reading order, tables, image handling, and PDF-to-markdown generation.
What you can build
  • Create a Knowledge Base from drag-and-drop files and query it from an agent via MCP
  • Ingest PDFs/Office docs/images from Azure Blob Storage or OneLake with OCR/layout/table extraction and incremental change tracking into indexes
  • Combine unstructured sources (files/Blob) with structured analytics by connecting Fabric IQ data agents inside a single Knowledge Base
  • Add web grounding by using an MCP server as a Knowledge Source (demo uses Web IQ endpoint with a Web Search tool)
  • Enforce document-level permissions by propagating Entra identities and ACL fields into the search index, including Purview sensitivity label handling
  • Switch between layers: use Knowledge Base agentic retrieval for quality vs. hit underlying indexes directly for high-throughput/low-latency query patterns
Code & CLI: aka.ms/build26-brk246aka.ms/foundry/discordhttps://aka.ms/FoundryIQ-evalshttps://contentunderstanding.ai.azure.comgithub.com/Azure-Samples/azure-search-openai-demo-purviewdatasecurity
AIAzureSecurityDeveloperFoundry IQMicrosoft Foundry
Session page ▶ Watch
BRK252 Breakout From slides

From observability to ROI for AI agents on any framework

Vivek Bhadauria, Sebastian Kohlmeier, Filisha Shah

This session outlines how Microsoft Foundry Observability aims to make nondeterministic, multi-agent systems production-ready through tracing, evaluation, monitoring, and optimization. It emphasizes cross-framework OpenTelemetry-based tracing and structured evals, then connects these signals to optimization workflows and ROI measurement in Foundry.

What's new
  • OpenTelemetry-based tracing and evals that extend to LangChain, LangGraph, OpenAI SDK, and Microsoft Agent Framework (not limited to Foundry-hosted agents)
  • Public preview: new evaluation capabilities including multi-turn evaluation, user simulation, traces-to-datasets, and smart filtering for continuous evals
  • Agent optimizer in Foundry Agent Service to search prompt/skill/model configurations to increase quality and reduce cost
  • ROI for Agents in Foundry: business value vs token cost, version comparison and daily trend views; surfaced in the Foundry portal and via API (public preview coming soon)
APIs & SDKs
  • OpenTelemetry (OTel) — Standardized tracing for capturing end-to-end agent steps (prompt → model → tool) across frameworks
  • Azure Monitor — Unified observability integration with Foundry, including dashboards and alerts
  • Application Insights — Integration point mentioned for tracing/observability with Foundry Observability
  • Foundry evaluators — Built-in evaluators spanning quality, RAG/document retrieval, risk & safety, agent/tooling, plus custom and rubric evaluators
  • AI Red Teaming Agent (PyRIT-based) — Red teaming capability listed as part of Foundry Observability evaluation toolset
  • ROI for Agents in Foundry API · announced — API surface to access ROI views (business value vs token cost), including version comparisons and trend views
What you can build
  • Instrument an agent (built in LangChain, LangGraph, OpenAI SDK, or Microsoft Agent Framework) with OTel traces and view tool calls, LLM invocations, and handoffs in a unified trace view
  • Run structured evals against production traces to get consistent quality/safety signals across an agent fleet
  • Generate a context-aware rubric evaluator and test dataset when creating a Foundry agent, then promote evals from dev to production traces
  • Continuously monitor token, latency, cost, error metrics, and production quality/safety scores; trigger Azure Monitor alerts
  • Convert production traces into structured evaluation datasets to expand offline coverage and drive iteration
  • Use Foundry Agent Service optimizer to propose evidence-backed prompt/model/skill configurations for better quality/cost
Code & CLI: ai.azure.comaka.ms/build26-BRK252aka.ms/ai/discordaka.ms/build/evalsVS CodeGitHub Copilot Chat/CLI
ObservabilityMicrosoft FoundryResponsible AI
Session page ▶ Watch
BRK260 Breakout From transcript

Build apps with local AI for unmetered intelligence on every Windows PC

Jordi Janer, Aditi Narvekar, Anastasiya Tarnouskaya, Tucker Burns

This session explains Microsoft Foundry on Windows as a stack for on-device AI across NPU, GPU, and CPU, using three layers: Windows AI APIs (inbox, turnkey), Foundry Local (open-source models), and Windows ML (bring your own model). Demos show speech-to-text, structured JSON extraction with Phi Silica on GPU, video super resolution, local VLM inventory with Qwen via Foundry Local, and web-based sentiment inference via WebNN + Windows ML.

What's new
  • Windows AI APIs expanded beyond NPU to support running many APIs on CPU and GPU
  • New speech recognition API in Windows AI APIs
  • New API to generate structured JSON output with Phi Silica using a JSON schema
  • Aion presented as the successor to Phi Silica and powering Edge Prompt API demos (preview link provided)
  • Foundry Local is now GA
  • Windows ML CLI announced as a new preview tool for model conversion/analysis/optimization/benchmarking with agent skills
APIs & SDKs
  • Windows AI APIs (via WinAppSDK) · ga — Turnkey on-device APIs backed by inbox models for tasks like speech recognition, summaries, rewrites, image description, imaging, video super resolution, and customization features such as LoRA for Phi Silica and structured output.
  • Speech recognition API (Windows AI APIs) — On-device speech-to-text taking microphone input (also supports audio files/streams) and running best on NPU while also working on CPU.
  • Phi Silica prompt / structured output (Windows AI APIs) — Small language model API used to extract order details and return structured JSON according to a provided JSON schema, demonstrated running on GPU.
  • Video Super Resolution API (Windows AI APIs) — On-device video upscaling API integrated in ClipChamp; demo notes it can run on CPU and NPU.
  • Aion (Windows AI APIs / Edge Prompt API) · announced — Successor to Phi Silica; shown powering the Prompt API demo in Edge Canary with experimental flags and described as improving quality, context window, and tokens/sec.
  • Foundry Local SDK · ga — SDK to run pre-optimized open-source models locally with abstraction over model management and hardware acceleration across CPU/GPU/NPU.
  • Foundry Local CLI · ga — CLI to experiment with models and select what fits a scenario, alongside the SDK.
  • Windows ML · ga — Unified on-device inferencing framework for running your own custom/open-source models across CPU/GPU/NPU with ONNX Runtime and vendor execution providers; supports native apps and web apps via WebNN.
  • Windows ML CLI · preview — Preview CLI for model prep: inspect, export/convert to ONNX, analyze operator support, optimize graph, and benchmark/perf; positioned as a unified pipeline with agent skills and integration into tooling like GitHub Copilot.
  • Foundry Toolkit for VS Code — VS Code extension mentioned as a UI-driven way to prep/optimize models (alongside Windows ML CLI).
  • WebNN (via Windows ML) in Chromium browsers · preview — Preview path to get native hardware acceleration (CPU/GPU/NPU) for web apps in Edge/Chrome via experimental flags; demo uses ONNX Runtime Web with WebNN execution provider.
  • ONNX Runtime Web APIs — Browser-side ONNX inferencing APIs used in the WebNN demo; configured with a WebNN context and WebNN execution provider to reach Windows ML acceleration on Windows.
What you can build
  • Drive-through ordering: convert spoken orders to text locally with the speech recognition API
  • Turn unstructured order text into structured JSON (size/modifiers/quantities) using Phi Silica structured output
  • Upscale user videos inside an editor using Video Super Resolution (frame-by-frame pipeline)
  • Inventory intake: classify/describe items from delivery photos using a vision-language model from Foundry Local catalog (Qwen 3.5 VLM demo)
  • Sentiment analysis for product reviews using a custom open-source model optimized with Windows ML CLI and run via Windows ML
  • Run the same ONNX sentiment model in a website using ONNX Runtime Web + WebNN to target CPU and NPU
Code & CLI: aka.ms/TryAionaka.ms/foundrylocalaka.ms/winmlaka.ms/winmlcliaka.ms/foundry-toolkitaka.ms/ai-dev-galleryaka.ms/winappsdkWinMLWinML CatalogWinML InspectWinML AnalyzeWinML OptimizeWinML PerfFoundry Local CLIget ready stateensure ready asynccreate asyncgenerate structured JSON responseget modelmodel.downloadmodel.loadcreate responses clientcreate streamingWebNN create contextExecution provider: WebNNONNX RuntimeONNX Runtime Web
AIAPIDeveloperLocal AIWindowsMicrosoft Foundry
Session page ▶ Watch
BRKSP91 Breakout From transcript

Turn foundation models into production AI on Microsoft Foundry

Vivek Chauhan, Alicia Frame, Jetashree Ravi

This session explains how Fireworks AI integrates with Microsoft (Azure) Foundry to deploy and run open-weight models with workload-specific inference optimization, and how you can bring fine-tuned/custom weights into Foundry. It also outlines Fireworks’ tiered training options (agent-driven, managed workflows, and a training API) and shows how Foundry deployment modes (serverless, PTU, BYOW/custom) map to different production needs. A case study with Harvey discusses benchmarking agent quality in legal workflows and using hybrid “worker + advisor” model routing to balance quality, cost, and latency.

What's new
  • General availability of Fireworks in Microsoft Foundry
  • Fireworks models in Foundry support multiple deployment modes: serverless (PayGo), PTU/Global PTU (provisioned), and BYOW/custom
  • Foundry model catalog includes Fireworks-optimized models identified with an "FW" prefix
  • Custom model deployment flow in Foundry supports uploading your own fine-tuned weights (trained elsewhere, e.g., in Fireworks) and deploying without shared-infra weight limits
  • Fireworks training options presented as three tiers: Training Agent, Managed Training, and Training API
APIs & SDKs
  • Fireworks in Microsoft Foundry · ga — Use Fireworks-optimized open-weight models from the Foundry catalog and deploy via serverless, PTU, or BYOW/custom modes; integrate the deployed model via Foundry APIs into apps/agents.
  • Fireworks Training Agent — Natural-language driven workflow that handles data reformatting, eval writing, model selection, hyperparameter search, training run, and deployment steps.
  • Fireworks Managed Training — UI-driven managed training workflows where you choose method/model, upload formatted data, set hyperparameters, monitor training metrics, and deploy trained models.
  • Fireworks Training API — Lower-level training interface for advanced teams with control over training loop/loss (including custom loss) and access to primitives/recipes for post-training.
  • Azure Agents (via Foundry) — Configure an agent to use a selected Fireworks model (or custom model) and connect tools (web search or developer-defined functions/tools).
What you can build
  • Deploy a state-of-the-art open-weight model from the Foundry catalog via serverless PayGo for quick prototyping
  • Reserve provisioned throughput (PTU/Global PTU) for a known production workload and attach a Foundry deployment endpoint to your application
  • Train/fine-tune a model in Fireworks, download the weights, upload as a Foundry custom model, and deploy using your Azure capacity/credits
  • Tune inference for a specific workload by choosing a deployment “shape” (e.g., speed vs throughput vs precision) and rely on autoscaling for traffic variability
  • Swap the model behind an Azure agent to a Fireworks catalog model or your custom model and add tools (web search or developer-defined functions)
  • Build a hybrid agent system that routes calls between cheaper open-weight “worker” models and heavier “advisor” models for quality/cost/latency trade-offs
Code & CLI: aka.ms/build/evals
AIAPIDeveloperMicrosoft FoundryApp DevelopersAI Toolkit
Session page ▶ Watch
DEM323 Demo From transcript

Under the hood of Microsoft AI models

Dave Citron

Dave Citron (CVP, Microsoft AI) walks through the newly announced Microsoft AI model family and then dives deep on how MAI Thinking 1 was trained. The session focuses on training philosophy (no distillation), data lineage choices, the reinforcement-learning climb, safety RL, and how Microsoft Frontier Tuning is positioned for private, tenant-contained tuning and iteration.

What's new
  • MAI announced 7 models spanning image, transcription, voice, coding, and reasoning, with multiple “Flash” variants positioned for lower cost/latency.
  • Image 2.5 is described as #2 on the “Ella Marina” image-to-image leaderboard; Image 2.5 Flash targets production throughput at about one-third the cost (per session claim).
  • Transcribe 1.5 is claimed as most accurate across 43 languages and up to 5x faster than rival models, and is being integrated across Microsoft products (e.g., Copilot in Teams, GitHub, Dynamics 365).
  • Voice 2 adds fine-grained emotional control and a Flash variant targeting sub-150ms latency for voice agents (per session claim); voice cloning is demonstrated as requiring only a few seconds of source audio.
  • Code 1 Flash is described as the default coding model shipping in GitHub inside VS Code (per session claim).
  • Thinking 1 details: mixture-of-experts, 35B active parameters (~1T total), 256K context, trained “from scratch” without distillation; uses GRPO-based RL and a dedicated safety RL climb.
APIs & SDKs
  • Microsoft Foundry — Where Image 2.5, Voice 2, Transcribe 1.5 are said to be live “today”; Thinking 1 is said to be available to a small set of private preview customers with expansion planned.
  • Microsoft Frontier Tuning · announced — A tuning/training workflow described as running inside a secure tenant using an org’s data and context (M365, Azure Fabric), with deployment via Foundry or Copilot and iterative improvement from real usage.
  • GitHub Copilot in VS Code — Code 1 Flash is described as available and shipping as the default model within GitHub inside VS Code.
What you can build
  • High-fidelity image editing with targeted region edits (e.g., add objects, change lighting) using Image 2.5; high-volume generation with Image 2.5 Flash.
  • Low-latency voice agents using Voice 2 Flash (sub-150ms claim) and expressive speech generation with emotional controls (e.g., warm/urgent/joyful).
  • Voice cloning from a few seconds of audio using Voice 2 (per session claim).
  • Multilingual speech-to-text across 43 languages, designed for noisy environments, accents, domain terminology, and multiple speakers using Transcribe 1.5.
  • Agentic coding tasks at speed using Code 1 Flash in VS Code.
  • Private, tenant-contained tuning of MAI models for domain workflows (example given: generating product quality reports from tasting-panel discussions).
Code & CLI: MAI PlaygroundMicrosoft FoundryMicrosoft.AI (model cards, API documentation, pricing)GitHub CopilotVS CodeBase10OpenRouterFireworks
Microsoft for StartupsMicrosoft FoundryAI Toolkit
Session page ▶ Watch
DEM331 Demo From transcript

Turn APIs, tools, and data into real agent velocity

Chu Lahlou

This demo shows how Azure Content Understanding in Microsoft Foundry turns messy, multimodal enterprise content (PDFs, Office docs, images, audio, video) into structured, agent-ready outputs with grounding and confidence scores. It walks through a fiber-cut incident response app where extracted content is used for diagnosis and dispatch, then shows tighter orchestration via a Content Understanding context provider in Microsoft Agent Framework (including attachment handling and multi-turn caching).

What's new
  • Content Understanding “document search” prebuilt analyzer extracts layout plus embedded elements (tables, figures, selection marks, barcodes/QR codes, signatures) for downstream agent/RAG use
  • Foundry portal includes a Content Understanding Playground with prebuilt analyzers and JSON output that includes offsets/lengths and bounding boxes for traceability/citation
  • Content Understanding supports custom analyzers defined by a schema (field name, type/method, natural-language description), including inferred fields that require reasoning/corroboration
  • A classifier can identify document categories and auto-route documents to prebuilt/custom analyzers for a single-call classify→route→extract pipeline
  • Microsoft Agent Framework integration via a Content Understanding context provider can auto-process attachments before they reach the LLM and reuse cached results across follow-up turns
  • Slide notes: table extraction quality improvements are “coming in July”
APIs & SDKs
  • Azure Content Understanding SDK (Python) — Initialize a client with the Foundry/Azure resource endpoint and credentials; call prebuilt analyzers (e.g., document search) and deploy/run custom analyzers and classifiers for classify+route+extract pipelines.
  • Content Understanding Studio / Playground (Foundry portal) — No-code UI to run prebuilt analyzers (including audio/video) and inspect structured JSON outputs with bounding boxes/offsets for grounding and citations.
  • Microsoft Agent Framework — Use a Content Understanding context provider to detect and process attachments in the agent loop and feed structured outputs back to the conversation; supports multi-turn caching in the demo.
  • Agent Framework Foundry chat client — Chat client used in the demo to run an agent with instructions plus a Content Understanding context provider and multiple attachments.
What you can build
  • Automate incident response by extracting and correlating evidence from multiple attachments (docs, images, audio, video) to diagnose root cause and generate a dispatch plan/email
  • Run multimodal preprocessing (OCR/layout + transcripts + image descriptions) so an LLM can reason over preserved tables/figures and embedded elements
  • Define custom, decision-ready fields (e.g., urgency, budget verdict) via custom schemas and extract/compute them from documents
  • Classify unknown incoming documents and auto-route them to the right analyzer to reduce branching logic in production pipelines
  • Integrate attachment processing into agent conversations using an Agent Framework context provider, avoiding repeated preprocessing on follow-up questions
Code & CLI: aka.ms/build26-DEM331aka.ms/foundry/discordaka.ms/agentsleague/aisf
APIFoundry IQMicrosoft FoundryGovernanceAgent ObservabilityGrounding
Session page ▶ Watch
DEM341 Demo From transcript

Any agent, any cloud: Standardized tracing with Foundry+OpenTelemetry

Nagkumar Arkalgud, Hanchi Wang

This demo shows how Microsoft Foundry Observability uses OpenTelemetry GenAI semantic conventions to provide a unified tracing experience across heterogeneous agents running on different clouds and frameworks. Speakers walk through instrumenting model/tool calls, stitching cross-cloud traces into a single view, and using trace-driven monitoring and evaluation workflows to diagnose failures, latency, and cost spikes.

What's new
  • Foundry Observability can stitch end-to-end, cross-cloud agent executions into a unified trace when agents emit OpenTelemetry spans using GenAI semantic conventions
  • Foundry native agents have Microsoft OpenTelemetry Distro instrumentation built in; external agents can be auto-instrumented with a small initialization snippet
  • Foundry Observability is powered by Azure Monitor and Azure Application Insights, with traces stored in Azure Monitor
  • Foundry supports trace viewing and trace-based evaluation not only for OpenTelemetry GenAI semantic conventions but also OpenInference and OpenLLMetry formats
APIs & SDKs
  • OpenTelemetry Generative AI semantic conventions — Common tracing schema for agent names, model calls, and key events across frameworks so Foundry can correlate and analyze traces consistently
  • Microsoft OpenTelemetry Distro — Unified SDK/distro for instrumenting agent frameworks in multiple languages; supports auto-instrumentation and Azure Monitor export via connection string
  • Azure Monitor — Backplane storage/analysis for Foundry Observability traces; integrates with existing Azure Monitor workflows
  • Azure Application Insights — Underlying telemetry component used by Foundry Observability (via Azure Monitor) for tracing/monitoring
What you can build
  • Instrument an existing agent (model + tool calls) with OpenTelemetry without changing agent logic and view traces in Foundry
  • Register externally hosted agents (e.g., on GCP/AWS) in Foundry and correlate their telemetry using an agent ID
  • Run a multi-agent, multi-cloud orchestrator that routes to specialist agents and see the whole workflow as one trace
  • Debug RAG-style retrieval issues by inspecting tool spans and their metadata (queries and retrieved content) in a trace
  • Monitor live traffic patterns, latency distributions, token usage and estimated cost, and investigate spikes or error-rate changes
  • Run trace-based evaluations and drill directly from an eval failure into the associated trace to diagnose what went wrong
Code & CLI: https://github.com/microsoft/Build26-DEM341-any-agent-any-cloud-standardized-tracing-with-foundry-and-opentelemetryaka.ms/build26-DEM341ai.azure.comaka.ms/ai/discordcurl
ObservabilityMicrosoft FoundryResponsible AITracingOpen Telemetry
Session page ▶ Watch
DEM345 Demo From transcript

From prompt to app: building AI-powered Windows apps

Nikola Metulev, Lei Xu

A demo-heavy walkthrough of building a WinUI desktop app using GitHub Copilot CLI skills and terminal-first Windows dev tooling. The speakers show an end-to-end workflow for running local AI (transcription, LLM summarization, and video frame search) and for preparing/optimizing models to run efficiently on-device via Windows ML and Windows AI APIs.

What's new
  • WinUI GitHub Copilot CLI plugin with WinUI-specific skills (design, workflow, packaging, code review, setup)
  • New WinUI .NET templates that can be run from the CLI as a packaged app (similar to Visual Studio F5, but via command line)
  • New Windows app development CLI: Winapp (packaging/identity and other Windows app dev commands)
  • New tool announced in-session: WinML CLI to streamline exporting/analyzing/optimizing (and optionally quantizing/compiling) models for Windows devices
  • Winapp UI tooling for agents to inspect UI, invoke controls, and take screenshots for automated functional verification
APIs & SDKs
  • GitHub Copilot CLI — Used with plugins/skills to generate and iterate on a WinUI app from the terminal.
  • WinUI — UI framework used to build the sample desktop app.
  • Foundry Local / Microsoft Foundry on Windows — Part of the Windows AI stack used for running a local language model in the sample app.
  • Windows ML — Windows platform capability referenced for running AI workloads locally and preparing models via the Windows ML model kit.
  • Windows AI APIs — Windows platform APIs referenced for integrating on-device AI primitives (e.g., language models) into apps.
  • WinML CLI · announced — CLI toolchain to export models (e.g., from Hugging Face), analyze operator support, generate optimization configs, optimize models, and run perf tests; supports multiple execution providers (CPU/GPU/NPU).
What you can build
  • Build a WinUI desktop app primarily from the terminal using Copilot CLI skills and templates
  • Run fully offline transcription with a local model (Whisper) inside a Windows desktop app
  • Use a local language model (via Foundry Local) to summarize or process media locally/offline
  • Prepare a Hugging Face model for Windows by exporting/converting to ONNX, analyzing graph operators, and applying optimizations via WinML CLI
  • Run local inference on NPU by default on Copilot+ PCs while keeping GPU free for other workloads
  • Implement “search within a video” by sampling keyframes, computing embeddings, and ranking matches against a text query
Code & CLI: copilot plugin listcopilot plugin install winuiskills listdotnet new winuiWinappwinui searchWinMDWinapp UI inspectWinapp UI invokeWinML exportWinML analyze --optim-config <file>.jsonWinML optimizeWinML perf
AIAPIDeveloperLocal AIWindowsMicrosoft Foundry
Session page ▶ Watch
DEMSP383 Demo From transcript

Move AI workflows from test to production on Microsoft Foundry

Vignesh Sridhar

This demo walks through using Fireworks AI’s open-source model inference inside Microsoft Foundry, from initial model discovery and serverless testing to single-tenant provisioned deployments. It shows side-by-side model comparison, saving a chosen model as an agent, running evaluations on an agent harness, and then publishing via a web preview or using generated code snippets and project endpoints.

What's new
  • Fireworks AI is integrated as a model provider in Microsoft Foundry, exposing multi-tenant models and single-tenant provisioned deployments.
  • Foundry workflow shown: deploy an open model, compare outputs across two models, save the chosen model as an agent, run evaluations on the full agent harness, then publish via web preview or call via code snippet/project endpoint.
  • Support for bringing custom fine-tuned weights: register a custom model in Foundry, create a deployment, and route inference via the Fireworks serving stack.
APIs & SDKs
  • Microsoft Foundry model deployments (data zone standard / provisioned throughput) — Deployment options shown for running inference: a multi-tenant serverless endpoint for testing and provisioned throughput options for dedicated/single-tenant production workloads, including a PTU calculator.
  • Foundry Agents (Save as agent / Call agent) — Save a model as an agent, evaluate the agent harness, then publish via web app preview or invoke via generated code snippets using a project endpoint and API key.
  • Foundry evaluations (matrix configurator + judge model) — Run evaluations over a dataset (example: 50 rows) against the entire agent harness with selectable criteria and an LLM judge (example mentioned: 'GPT-4o mini').
What you can build
  • Stand up a serverless endpoint for an open model to run quick experiments/evals before productionizing.
  • Move to a dedicated single-tenant deployment using provisioned throughput and a PTU sizing calculator.
  • A/B compare two open models in the Foundry UI with the same prompt to weigh latency vs response quality/token usage.
  • Create a code review agent and test for issues like SQL injection risks and hard-coded secrets.
  • Evaluate an agent harness (prompt + potential tool calls) against a custom dataset and track metrics (e.g., relevance, coherence, groundedness).
  • Publish an agent to a simple web UI preview or integrate it into external Python workflows via a project endpoint and API key.
Code & CLI: Python code snippets in Foundry 'Call agent' tab (project endpoint + API key)
AIAzureMicrosoft Foundry
Session page ▶ Watch
LAB513 Lab From abstract

Build an AI app with Azure SQL Hyperscale, Fabric, and Foundry

Matt Calder, Someleze Diko

This lab walks through building an AI-powered FAQ assistant using Azure SQL Database vector search with a Retrieval-Augmented Generation (RAG) pattern backed by Azure OpenAI Service. It also covers using GitHub Copilot to speed up T-SQL, mirroring data into Microsoft Fabric (OneLake) for analytics, applying governance with Microsoft Purview, and orchestrating the workflow with Microsoft Foundry Agents.

APIs & SDKs
  • Azure SQL Database vector search — Store and query embeddings in Azure SQL Database to support RAG retrieval for an FAQ assistant.
  • Azure OpenAI Service — Generate answers for an FAQ assistant using RAG with retrieved context from Azure SQL Database.
  • Microsoft Fabric (OneLake) — Mirror data from Azure SQL into OneLake for analytics workflows.
  • Microsoft Purview — Apply governance controls to data used across the app and analytics workflow.
  • Microsoft Foundry Agents — Orchestrate the workflow for the AI assistant and related data steps.
  • GitHub Copilot — Accelerate T-SQL development while building the solution.
What you can build
  • Build an AI-powered FAQ assistant using RAG with Azure SQL Database vector search and Azure OpenAI Service
  • Author and iterate on T-SQL for the app using GitHub Copilot
  • Mirror operational data from Azure SQL into Microsoft Fabric (OneLake) for analytics
  • Apply data governance to the solution using Microsoft Purview
  • Orchestrate an end-to-end AI assistant workflow using Microsoft Foundry Agents
Azure SQL HyperscaleMicrosoft FoundryCP&DData
Session page
LAB540 Lab From slides

Observe, optimize and protect your hosted agents in Microsoft Foundry

Nitya Narasimhan, Filisha Shah

This lab focuses on why agent failures often evade traditional monitoring and how Microsoft Foundry Observability targets those gaps. It covers building context-specific evaluation suites (auto-generated evaluators and test datasets), wiring them into hosted-agent workflows via skills/MCP tooling, and then scaling quality with continuous evaluation, trace-linked analysis, and adaptive red teaming.

What's new
  • Microsoft Foundry Observability positions itself as end-to-end visibility, quality, and control for production AI (evaluate, monitor, trace, govern, optimize).
  • Context-specific evaluation suites can be created with auto-generated evaluators plus test datasets.
  • Evaluation can be wired into developer workflows for hosted agents via skills/MCP tooling.
  • Quality can be scaled using continuous evaluation, trace-linked analysis, and adaptive red teaming.
APIs & SDKs
  • Microsoft Foundry Observability — Capabilities described for evaluating, monitoring, tracing, governing, and optimizing production AI/agents.
  • MCP tooling (for hosted agents) — Tooling referenced as part of wiring evaluation suites into developer workflows via skills/MCP.
  • Agent 365 — Management layer referenced for observing, securing, and governing with Agent ID.
What you can build
  • Set up context-specific evaluation suites for an agent using auto-generated evaluators and test datasets.
  • Continuously evaluate hosted agents and use the results as ongoing quality signals.
  • Debug and optimize an agent in production using trace-linked analysis.
  • Run adaptive red teaming against agents and track outcomes alongside traces/evaluations.
  • Operate a governed agent lifecycle where you build in GitHub and run/optimize in Foundry.
Code & CLI: aka.ms/build26-LAB540ai.azure.comaka.ms/build/foundrydiscordaka.ms/ai/discord
ObservabilityMicrosoft FoundryResponsible AIEvaluations
Session page
OD836 Pre-recorded From transcript

Demo tour of Foundry portal for AI developers

Carlotta Castelluccio​, Nitya Narasimhan

This session walks through building a retail shopping assistant agent in Microsoft Foundry portal, starting from a guided project setup and playground prototyping through model selection, prompt iteration, and grounding with enterprise files. It focuses on portal features that complement a code-first workflow: model catalog exploration, version comparison, tracing, and evaluation to diagnose behavior and regressions before moving toward production monitoring.

What's new
  • Foundry portal guided flow can create a resource group, Foundry resource, Foundry project, and a first agent from the UI
  • New agents default to deploying GPT-4.1 plus a text embedding model deployment ("text embedding three large")
  • Agent playground supports built-in tools including Web search and Code Interpreter (Python sandbox)
  • Traces can be enabled by connecting an Application Insights + Log Analytics workspace to the agent
  • Agent responses can be scored with built-in evaluation metrics spanning quality and safety (e.g., Task Adherence, Intent Resolution, Coherence, Relevance, Under Attack)
  • Model catalog discovery includes leaderboards, trade-off charts, and model comparison to deploy a chosen model into a project; Model Router can automatically pick backend models per prompt complexity
APIs & SDKs
  • Microsoft Foundry portal (ai.azure.com) — Browser UI to create projects/agents, configure models/tools/knowledge, preview apps, and review traces/evaluations.
  • Application Insights — Connected to an agent to collect and inspect traces (inputs/outputs, metadata, tool calls).
  • Log Analytics workspace — Created alongside Application Insights to support logging/trace exploration for the agent.
  • Model Router (Azure Foundry model) — A deployable model endpoint that routes prompts to an appropriate backend model automatically and can be inspected via traces to see which model was chosen.
What you can build
  • Prototype a single-agent assistant entirely in-browser (model + instructions + tools) before writing code
  • Compare agent versions side-by-side with the same prompts to validate prompt/model changes
  • Use web search tool calls for fresh information (e.g., weather) and inspect tool-call traces
  • Ground an agent in enterprise/product data by uploading files to build a vector index and using file search
  • Select a more cost-effective model by using model catalog leaderboards/trade-off charts and deploying it into the project
  • Enable observability by wiring traces to Application Insights and using built-in per-response evaluation scoring
Code & CLI: ai.azure.com
DeveloperMicrosoft FoundryAgent ObservabilityProduction Systems
Session page ▶ Watch
OD851 Pre-recorded From transcript

Expand local AI reach with Windows ML

Maha Bayana, Andrew Leader

This session shows how to run custom or open-source ONNX models locally on Windows using Windows ML, targeting CPU, GPU, and NPU with a unified approach. The demo builds a sentiment-analysis dashboard that runs in the browser via ONNX Runtime Web + WebNN and then reuses the same model in a WinUI 3 app with Windows App SDK ML packages and dynamically acquired execution providers.

What's new
  • Windows ML CLI: new command-line tool for model conversion and optimization tasks
  • Windows ML updated to version 2.0, bringing ONNX Runtime 1.24
  • Windows ML ORT Gen AI library performance updates for faster local LLM inferencing on Windows
  • WebNN updated to use Windows ML on Windows for faster hardware-accelerated inferencing in Edge/Chrome
  • Plugin-based execution providers updated for performance and easier use across runtime versions
APIs & SDKs
  • Windows ML — Run ONNX models locally on Windows across CPU/GPU/NPU; supports Windows 10+ and multiple app languages/deployment types.
  • Windows ML CLI (WinML CLI) · announced — Command-line tool to discover/export supported models and perform model conversion/optimization for Windows ML.
  • ONNX Runtime Web — Run ONNX models in web apps; in the session it uses WebNN behind the scenes for acceleration.
  • WebNN · preview — Web API used (via ONNX Runtime Web) to accelerate model inferencing in Edge/Chrome; described as in developer preview and requiring preview flags.
  • Windows App SDK ML — WinUI 3 app packages that add WinML and ONNX Runtime to a native Windows app.
  • AI Dev Gallery app — App with samples of AI models running locally via Windows ML, including code samples.
  • Microsoft Foundry on Windows — Positioned as the umbrella for local AI solutions including Windows ML, Foundry Local, and Windows AI APIs.
  • Foundry Local — Ready-to-use local AI models that are pre-optimized and installed system-wide (no ML expertise required).
  • Windows AI APIs — Ready-to-use AI models/APIs under Foundry Local; pre-optimized and installed system-wide.
What you can build
  • Convert a PyTorch model to ONNX (via WinML CLI or PyTorch) and run it locally with Windows ML
  • Optimize an ONNX model for specific hardware (GPU/NPU) and still run broadly via CPU fallback
  • Run sentiment analysis entirely on-device in a web app using ONNX Runtime Web + WebNN
  • Switch a web workload from CPU to NPU by changing the WebNN device context
  • Build a WinUI 3 desktop app that uses the same ONNX model and targets a specific execution provider (e.g., QNN on NPU)
  • Create a floating overlay (pop-out chart) in a native Windows app while inferencing on NPU
Code & CLI: WinML Hub (Windows ML CLI command)export (Windows ML CLI command)npm install onnxruntime-webimport ORT from 'onnxruntime-web/experimental'pythonserver.pyORT.InferenceSession.CreateFindAllProviders APIEnsureReadyAsync APITryRegister APIGetEPDevices APIAppendExecutionProvider(s) APIAddSessionConfigEntry API (disable CPU fallback)SetExecutionPolicySetEPPolicyaka.ms/WindowsML
AIAPIDeveloperLocal AIWindowsMicrosoft Foundry
Session page ▶ Watch
ODSP922 Pre-recorded From transcript

Develop a conversational search experience without rebuilding your app

Greg Crist

This demo shows how Elastic Agent Builder can layer an LLM-powered conversational experience onto an existing e-commerce search app, using retrieval from an Elastic-backed product catalog. The speakers connect a hosted model deployed via Microsoft Foundry in Azure, build workflows/tools (including MCP-backed calls), and then integrate the resulting agent into a React + FastAPI application via API.

What's new
  • Elastic Agent Builder is now generally available (previously in technical preview).
  • Elastic Agent Builder can create an Azure connector to use a model deployed in Microsoft Foundry (URI + API key), demonstrated with a Mistral Large deployment.
  • Agent Builder workflows support step-level failure handling with retries and delays, plus logging of workflow outputs.
  • Tools and agents created in Elastic Agent Builder are accessible via API for integration into existing applications.
APIs & SDKs
  • Azure OpenAI — Referenced as a hosted model option to integrate with Elastic Agent Builder for conversational search.
  • Microsoft Foundry (model deployment) — Used to deploy a base model and obtain a target URI and key that are then configured in an Elastic Agent Builder Azure connector.
  • Elastic Agent Builder (Agents API) · ga — Agents built in Agent Builder can be called from external apps via API key; demo includes generating an example Python request to the Trip Planner agent.
  • Elastic ESQL — Used as a tool type for querying user clickstream/affinity inside the agent’s reasoning flow.
  • Elastic Inference Service — Creates vectors from product titles/descriptions to enable semantic/hybrid search over the product catalog.
  • Elastic MCP tool type · preview — Tool type for chaining tools into a complex workflow; described as being in tech preview.
What you can build
  • Add conversational, grounded product Q&A to an existing e-commerce search UI without a full rebuild.
  • Deploy a hosted LLM in Microsoft Foundry and connect it to Elastic via an Azure connector (URI + API key).
  • Build an agent that combines semantic product search, user clickstream affinity, CRM profile lookup, and weather/safety checks.
  • Expose agent capabilities to a web app backend via API key and call it from a FastAPI service.
  • Use workflow retries/delays and logging to make external tool calls more production-ready.
Code & CLI: Visual Studio CodePython (requests library)FastAPIReactElastic Agent Builder documentationGitHub repo for the Wayfinder Supply web app (name referenced; URL not provided in transcript)
AzureObservabilityGitHub CopilotGitHubFoundry IQFoundry Agents
Session page ▶ Watch

GitHub Copilot & developer AI

BRK201 Breakout From slides

Multi-agent patterns in VS Code you won't learn from docs

Pierce Boggan, Kent C. Dodds, Burke Holland, Julia Kasper, Harald Kirschner, Chris Reddington

This breakout focuses on practical patterns for orchestrating multiple agents in VS Code across local, background, and cloud surfaces. It emphasizes how to decompose work among agents (fork vs. delegate) and how to verify quality when many agents are contributing to a codebase.

What you can build
  • Orchestrate parallel agent work across local, background, and cloud surfaces in a VS Code workflow
  • Decompose larger engineering tasks into agent-sized chunks and choose between forking vs. delegating
  • Set up a workflow to verify quality when multiple agents are producing changes simultaneously
Code & CLI: aka.ms/VSCode/Learnaka.ms/VSCode/Liveaka.ms/AwesomeCopilotaka.ms/build/evalsaka.ms/terminallive/day1aka.ms/terminallive/day2aka.ms/VSCode/Livestage
DeveloperGitHub CopilotGitHubVisual Studio CodeVS CodeGitHub Copilot CLI
Session page ▶ Watch
BRK204 Breakout From transcript

What we learned shipping VS Code weekly (without breaking everything)

Pierce Boggan, Josh Spicer, Anna Soracco

The VS Code team explains how moving from monthly to weekly releases increased operational load (issues, PRs, regressions) and forced changes in planning, inner-loop tooling, and engineering automation. They share concrete patterns like PR-based UI verification via a component browser, agent skills for performance regression checks, and AI pipelines that triage issues and turn error telemetry into owner-assigned fix proposals. The focus is on keeping quality and performance high while throughput accelerates.

What's new
  • VS Code shifted from monthly to weekly stable releases (move started around February 2026) and added staged rollouts with the ability to freeze rollouts when problems appear
  • Layered AI issue triage pipeline: filtering (spam/outage/meta, dedup, prompt-injection gating), enrichment (translation, request-more-info, duplicate suggestions), and assignment via ownership analysis using git history
  • Error regression pipeline that buckets telemetry into novel error fingerprints, creates GitHub issues, links blame/commit context, and generates fix proposals and owner suggestions
  • Component Browser to run VS Code UI components outside the full product build, enabling PR-based verification with fixtures/screenshots to catch regressions quickly
  • VSC-Bench: internal offline evaluation harness to decide whether models/harness changes are ready for VS Code using real tasks and metrics (correctness, token cost, effort, latency)
APIs & SDKs
  • Copilot SDK — Used to power parts of the error regression pipeline that creates GitHub issues and generates fix proposals/owner suggestions.
  • Copilot API — Described as an API gateway the team onboards models to before launch and then tunes prompts/experiments against.
  • vscode-errors MCP server — Referenced as part of the error regression pipeline used to produce GitHub issues and fix proposals.
What you can build
  • Move from monthly to weekly shipping by reducing batch size and adding faster post-release regression signals (issues + usage/error telemetry)
  • Automate GitHub issue triage at scale: spam/outage detection, dedup suggestions, translation, and auto-assignment to likely owners
  • Turn production error telemetry into actionable work items: bucket errors, find novel fingerprints, open GitHub issues, attach blame context, propose fixes
  • Add PR-centric UI verification by extracting UI components to run independently and generating fixture-driven screenshots/diffs
  • Encode expert practices into agent skills (e.g., performance checks) to reduce reviewer bottlenecks and keep perf regressions from slipping into weekly releases
  • Use short-lived workstreams with a DRI and weekly goals to keep alignment as throughput increases
Code & CLI: /chat-perfaka.ms/VSCode/TeamKitaka.ms/build/evals
DeveloperGitHub CopilotGitHubVisual Studio CodeGitHub ActionsVS Code
Session page ▶ Watch
BRK207 Breakout From transcript

GitHub Copilot in Visual Studio: Agents That Debug, Profile, and Test

Nik Karpinsky, Mads Kristensen, Anisha Pindoria

This session demos GitHub Copilot agents inside Visual Studio that go beyond code generation: creating tests from bug context, debugging failing tests via the debugger, and profiling hot paths to propose and validate optimizations. The presenters focus on pro-grade workflows (C#/.NET and C++) with governance controls and an emphasis on runtime and performance data-driven fixes. They also outline a roadmap including modernization, agent skills, build-speed improvements, merge conflict resolution, shared Copilot SDK adoption, and expanded model bring-your-own options.

What's new
  • Right-click Test Explorer action: "Debug this test with Copilot" using a debugger-aware agent (breakpoints, expression eval, memory inspection) to root-cause and fix failures
  • Right-click action: "Profile with Copilot" to analyze traces, propose targeted optimizations, re-run tests, and re-profile to validate improvements
  • Visual Studio moving to the GitHub Copilot CLI SDK (rolling out starting next week in Visual Studio 2026 Insiders) so VS/VS Code/CLI share the same SDK base and get features at the same time
  • App modernization agent roadmap: convert ASP.NET Web Forms (including user controls/server controls/components) to Blazor; mention of adding Aspire as part of modernization
  • Agent skills roadmap: Microsoft-authored skills automatically applied based on project type/task, with skills described as markdown files and open-source/community contributed
  • BYOK/model choice roadmap: "starting very soon" use any model in Visual Studio (local or any cloud), with enterprise management controls to restrict allowed models/providers
APIs & SDKs
  • GitHub Copilot CLI SDK · announced — Planned shared SDK base for Visual Studio's Copilot integration, aligned with VS Code and Copilot CLI so features land at the same time across clients.
  • MCP servers (Copilot access in Visual Studio) — Copilot chat can invoke MCP tools/endpoints (e.g., an Azure DevOps/Azure DevOps Services work item tool) with user confirmation and credentials for governed access to external context.
What you can build
  • Generate unit tests from an Azure DevOps bug/work item link (via MCP) to reproduce a crash before fixing code
  • Use a debugger agent to debug a failing test end-to-end (set breakpoints, inspect state) and apply a code fix validated by re-running the test
  • Add profiling to CI test runs to collect traces as test attachments, then open/analyze them in Visual Studio to catch performance regressions
  • Profile a specific unit test and have Copilot identify hot paths from trace data and implement optimizations, then measure before/after by re-profiling
  • Modernize legacy ASP.NET Web Forms applications by converting to Blazor using a modernization agent
Code & CLI: GitHub Copilot CLI SDKVSTest performance collector (NuGet package)MSBuildRoslynVisual Studio 2026 Insiders buildaka.ms/build26/brk207
DeveloperGitHub CopilotGitHubGitHub Copilot CLIVisual StudioDevTools
Session page ▶ Watch
BRK210 Breakout From slides

Future of Developer Productivity: Microsoft’s EngThrive Framework in Practice

Tim Bozarth

This session lays out Microsoft’s EngThrive framework for measuring and improving developer productivity in the AI era using three dimensions: Speed, Ease, and Quality. It emphasizes outcome-based metrics over activity metrics (e.g., avoiding “token maxing”) and walks through how teams can use dashboards and operating rhythms to identify bottlenecks and drive change. Two case studies show how focusing on protected deep-work time and improving onboarding to first pull request can impact throughput and developer experience.

What's new
  • EngThrive framework: measure developer productivity via Speed, Ease, and Quality (plus a “Thriving” satisfaction metric)
  • Core EngThrive metrics set: Idea-to-Customer, Time-to-Nth-PR, Innovation Time, Bad Developer Days, PRs-per-Incident, Incident Mitigation Time, and ES Satisfaction NSAT
  • EngThrive program “North Star”: consistent company-wide developer experience metrics, dashboards, and business processes to drive accountability and change
What you can build
  • Build team dashboards that track EngThrive outcome metrics (e.g., idea-to-customer, innovation time, PRs-per-incident) rather than activity counts
  • Run an EngThrive operating rhythm: pick one shared metric, set clear accountable roles, and review progress bi-weekly grounded in data
  • Implement a “Focus Time” initiative by reducing calendar fragmentation, improving meeting hygiene, and protecting 2+ hour deep-work blocks
  • Use dashboard data to identify and coach outlier teams with low focus time or high toil
  • Improve new-hire ramp by optimizing Time-to-First-PR and Time-to-Nth-PR with checklist updates, PR workflow docs, and training
Code & CLI: aka.ms/build/evalsaka.ms/build/evals (session details page referenced for tutorials, resources and code)
DeveloperGitHubDevTools
Session page ▶ Watch
BRKSP90 Breakout From transcript

Stop routing docstrings to 70B models with on-device AI on Snapdragon

Alberto Martinez, Morris Novello

This session argues that cloud-only inference for IDE coding assistants is structurally inefficient because a large share of requests (docstrings, small edits, lint fixes) do not need 70B+ models. It presents a three-tier routing design (on-device ≤13B, on-prem 14B–34B, cloud 70B+) driven by a fast classifier and an entropy-based fallback, with the goal of reducing cloud token spend and improving latency while keeping more code local.

What's new
  • Reference three-tier inference routing architecture for coding assistants: on-device (≤13B) → on-prem (14B–34B) → cloud (70B+), with escalation based on confidence/entropy thresholds
  • Classifier design using four primary signals (token count, AST depth, cross-file reference count, security keyword flags) plus a fifth signal for fallback (logit entropy on model output)
  • Quantization guidance for code tasks: INT8 weights with INT16 activations (INT8w/INT16a), with cited benchmark impact of <5% quality gap for complexity scores 1–7 (HumanEval/MBPP), and degradation above score 7
  • Starter resources published: GitHub repo, an architecture blueprint link, and a workload profiler link for estimating edge-resolution rate and token savings
APIs & SDKs
  • Foundry Agents — Listed as a session tag; the talk discusses orchestrators and agent routing conceptually but does not describe specific APIs in the supplied material.
  • Foundry Local — Listed as a session tag; the session focuses on local/on-device inference routing but provides no explicit Foundry Local API details in the supplied material.
What you can build
  • Route IDE assistant requests by complexity so docstrings, boilerplate, and small edits run on-device while cross-repo refactors and security audits escalate to larger tiers
  • Build an orchestrator-owned classifier that assigns a complexity score and selects an execution tier, with tunable thresholds per signal
  • Implement a confidence fallback that monitors logit entropy during generation, aborts uncertain runs, and re-routes to a higher tier before returning a result
  • Profile a team’s historical AI request logs to estimate edge-resolvable share and projected cloud token savings
  • Evaluate quantization trade-offs for local code generation (INT8w/INT16a) and set a policy to avoid heavier quantization for complexity scores above 7
Code & CLI: github.com/microsoft/tiered-inference-routingaka.ms/tiered-inference-blueprintaka.ms/inference-workload-profileraka.ms/build-session-feedback
AI.NETDeveloperGitHubLocal AIWindows
Session page ▶ Watch
DEM305 Demo From transcript

GitHub Copilot Anywhere: Remote Control CLIs to Cloud Sandboxes

Ellie Bennett, Denizhan Yigitbas

The session demos three ways to keep GitHub Copilot work moving across devices and environments: remote-controlling local Copilot sessions, running Copilot in an isolated cloud sandbox, and querying your Copilot session history with Chronicle. It shows how sessions can be steered from GitHub Mobile or github.com, how cloud sandboxes persist without the host machine, and how Chronicle can turn session history into actionable guidance (tips, search, standup reports, and custom-instructions improvements).

What's new
  • Cloud sandboxing for GitHub Copilot is introduced in public preview
  • Remote control lets you steer local Copilot sessions from the GitHub mobile app and from github.com
  • Cloud sandboxes give each Copilot session an isolated cloud environment with controllable access to tools, filesystem, and network
  • Cloud sandboxes persist via an implicit snapshot when Copilot becomes idle; compute scales down to 0 and later resumes from the snapshot
  • Chronicle provides a queryable history of your Copilot sessions across clients, accessible via "/chronicle"
APIs & SDKs
  • GitHub Copilot CLI — Run Copilot in the terminal, including remote-control and cloud-sandbox sessions.
  • GitHub Copilot cloud sandboxing · preview — Runs a Copilot session in an isolated cloud environment that can be resumed from snapshots and steered via web/mobile.
  • Copilot Remote Control — Makes a local Copilot session steerable from another device (GitHub Mobile or github.com) while preserving repo permissions.
  • Chronicle — Indexes your Copilot session history across clients to provide tips, search, standup reports, and custom-instructions improvements via "/chronicle".
What you can build
  • Steer a local Copilot CLI session from your phone using the GitHub mobile app via a QR code link
  • Continue a Copilot session from github.com when you step away from your terminal
  • Run Copilot work in a cloud sandbox so the session continues even if the laptop disconnects or shuts down
  • Apply cloud agent policies (firewall rules / allowances) to sandboxed Copilot sessions scoped to a repository
  • Generate a standup report from your Copilot activity using Chronicle
  • Search across prior Copilot sessions and get suggestions to improve your custom instructions via Chronicle
Code & CLI: remote onremote offremote showkeep alive on--cloud/chronicleChronicle tips
DeveloperGitHub CopilotGitHubGitHub ActionsGitHub EnterpriseGitHub Copilot CLI
Session page ▶ Watch
DEM351 Demo From slides

AI Skills Navigator: Accelerate tech skills with personalized learning

Shreenidhi Bindinganavile Ramanuja, Matt Erni

This demo introduces AI Skills Navigator as an agentic learning space for building career skills, positioned for both individuals and organizations. It highlights integration with Copilot and personalized learning formats (short sessions, podcast-style summaries, and team-based learning), plus pointers to get started and related events.

What's new
  • AI Skills Navigator presented as an "agentic learning space" for skill building for individuals and organizations
  • Get started link provided: aka.ms/ASN
  • AI Skills Fest promoted (June 8–12, 2026) with registration link: aka.ms/AISkillsFest
What you can build
  • Personalize technical learning based on preferred format (short sessions or podcast-style summaries)
  • Support continuous learning at scale within an organization
  • Learn alongside your team using a shared learning experience
  • Use Copilot integration to support skill building
Code & CLI: aka.ms/ASNaka.ms/AISkillsFestaka.ms/build/evals
AICopilotPersonalization
Session page ▶ Watch
OD855 Pre-recorded From transcript

Accelerating developer productivity with Windows 365

Roop Kiran Chevuri, Phil Gerity

This session shows how Windows 365 Cloud PCs reduce dev environment setup friction via preconfigured developer images, device-agnostic access through Windows App, and centrally managed provisioning in Intune. It also positions Windows 365 as an execution layer for AI and agents, including Windows 365 for Agents (GA) with MCP tooling and Agent 365 integration to let agents operate Windows apps with enterprise controls.

What's new
  • Windows 365 now supports a Windows 11 developer configuration image (public preview)
  • Windows 365 for Agents is generally available
  • Windows 365 offers up to a 32-core SKU with up to 128 GB RAM (as stated in-session)
  • Windows 365 for Agents provides an MCP tool layer to provision/connect/manage agent Cloud PCs
  • Agent Cloud PC pools can be provisioned and managed in Intune, alongside user Cloud PCs
  • Context-based redirection can enforce drive/clipboard/printer/USB redirection based on device compliance via Conditional Access + Windows 365 settings
APIs & SDKs
  • Windows 365 for Agents MCP tools (Model Context Protocol) · ga — MCP tool layer to let agents provision a Cloud PC, connect to it, interact with it, and manage lifecycle.
  • Agent 365 CLI / A365 CLI — CLI used to list available MCP servers in the tenant and add the Windows 365 computer-use MCP server to an agent manifest.
What you can build
  • Spin up a ready-to-code Windows 11 dev Cloud PC with Visual Studio, Git, GitHub CLI, Python, Node.js, GitHub Copilot, plus WSL Ubuntu preconfigured
  • Use login-time scripts to auto-install project tools (e.g., WinGet, Docker, Postman) and auto-clone a repo
  • Run local language models inside a Cloud PC via Foundry Local and test them in a playground (chat-based validation)
  • Run multi-device dev workflows where a persistent Cloud PC continues work even when the local laptop sleeps, while you monitor/steer remotely
  • Build enterprise agents that operate GUI/legacy Windows apps by giving each agent its own managed Cloud PC (Windows 365 for Agents)
  • Provision pooled agent Cloud PCs in Intune for agents to check out and execute work
Code & CLI: Windows AppVisual StudioVS CodeGitGitHub CLIGitHub CopilotGitHub Copilot CLIWSL (Ubuntu)WinGetDockerPostmanMicrosoft FoundryFoundry LocalAgent 365Agent 365 portalAgent 365 CLI / A365 CLIWindows 365 computer use MCP serverIntuneEntra IDAzure Compute GalleryAzure Network ConnectionMicrosoft Hosted NetworkConditional AccessComfyUIStable Diffusion 1.5Qwen (small model mentioned)
Windows 365GitHub CopilotGitHubWindowsWindows 365 for AgentsVisual Studio
Session page ▶ Watch

Data & databases

BRK223 Breakout From slides

From rows to reasoning: Designing databases for AI apps and agents

Charles Feddersen, Abe Omorogbe, Eric Hudson

This session surveys recent AI-oriented capabilities across Azure Cosmos DB, Azure SQL Database Hyperscale, and Azure HorizonDB (cloud-native PostgreSQL). It emphasizes reducing “glue code” by moving agent/RAG primitives (memory, hybrid search, pipelines, and model calls) closer to operational data, and demonstrates end-to-end patterns with local and Azure architectures.

What's new
  • Azure Cosmos DB: GA features including Global Secondary Index, per-partition automatic failover, partition key change, change feed mode for all versions/deletes, Linux Emulator, MCP Toolkit, and Agent Kit
  • Azure Cosmos DB: Preview features including distributed transactions, Azure Backup, AI assistance in the VS Code extension, semantic reranking, and Agent Memory Toolkit
  • Azure SQL Database Hyperscale: GA integrations in the MSSQL VS Code extension (Copilot Schema Designer integration, Data API Builder with Copilot, SQL Notebooks) plus Microsoft Entra server-level logins and fixed server roles
  • Azure SQL: Preview items including TDE with AES support / AES key support for TDE, MSSQL extension provisioning for Azure SQL Database, GitHub Copilot agent mode in SSMS, and Fabric Apps
  • Azure HorizonDB: Public Preview cloud-native PostgreSQL with built-in AI functions and in-database AI pipelines; zone-resilient auto-scaling storage up to 128TB and <1 ms multi-zone commit latency (as stated on slides)
APIs & SDKs
  • Agent Memory Toolkit for Azure Cosmos DB · preview — A Python SDK and serverless architecture for storing, processing, and retrieving agent memories using Cosmos DB (e.g., summarize threads, extract facts, build user profiles), driven by change feed triggers.
  • MCP Toolkit for Azure Cosmos DB · ga — Toolkit for connecting tools via MCP with Azure Cosmos DB (listed as GA).
  • Agent Kit for Azure Cosmos DB · ga — Agent-oriented kit for Azure Cosmos DB (listed as GA).
  • Data API Builder · ga — Used to expose /api endpoints for the app and /mcp endpoints for agent tools, with a single config in the demo architecture; also referenced as integrated with GitHub Copilot in the MSSQL VS Code extension (GA).
  • SQL MCP server — Referenced as part of Azure SQL’s AI-ready features to enable MCP-style tool access to SQL.
  • Azure HorizonDB AI functions and pipelines · preview — In-database AI model management and functions (extract(), is_true(), generate(), rank(), create_embeddings()) plus durable background-job pipelines via ai.create_pipeline(s) for chunking and embedding with triggers and sinks.
What you can build
  • Implement agent memory in Cosmos DB that auto-summarizes conversations, extracts facts, and builds user profiles using change feed-triggered processing
  • Build a Live Site/on-call assistant that performs hybrid search over incidents + runbooks, inspects live database state (DMVs / deadlock reports), and writes mitigations back into operational tables
  • Run the same Live Site assistant locally (SQL container + local models via Ollama) and in Azure (Hyperscale + APIM + Azure OpenAI + Managed Identity) using the same stored procedure body
  • Create in-database RAG ingestion pipelines in HorizonDB that chunk documents and generate embeddings continuously (e.g., trigger => 'on_change') without external orchestrators
  • Use an append-only SQL ledger (Merkle) pattern to log agent/app actions immutably (AppLog) alongside operational workflows
Code & CLI: aka.ms/build26/BRK223aka.ms/build26cosmosaka.ms/buildsql2026aka.ms/build26horizondb.github/skills/live-site-sql/SKILL.mdCosmosMemoryClientAsyncCosmosMemoryClientSELECT ai.create_pipelines(...)SELECT ai.create_pipeline(...)ai.chunk(...)ai.embed(...)ai.table_source(...)ai.table_sink(...)sp_invokeusp_GenerateMitigationusp_HybridSearchOllamamxbai-embed-largephi4-minitext-embedding-3-smallgpt-5-4-miniaka.ms/sqldbcontainerpreview-signup
Azure SQLAzure Database for PostgreSQLAzure Cosmos DBCP&DDataAzure HorizonDB
Session page ▶ Watch
BRK224 Breakout From transcript

PepsiCo’s blueprint for agentic AI

Krunal Patel, Rishabh Saha, Bob Ward, Govanna Flores

Microsoft and PepsiCo walk through how PepsiCo modernized its Enterprise Data Foundation to support agentic applications, moving from "data for dashboards" to "data for agents." The core example is KAM360, a multi-agent system for key account managers that uses a governed data foundation plus an agentic RAG/knowledge layer to reduce pre-meeting prep time and capture institutional memory.

What's new
  • Azure Cosmos DB investments: Semantic Reranking (preview), Distributed Transactions (preview), Azure Backup (preview), MCP Toolkit (GA), Agent Kit (GA), Agent Memory Toolkit (preview)
  • Azure SQL Database investments: deeper GitHub Copilot integrations via MSSQL extension (GA items include schema designer integration and Data API builder with Copilot); GitHub Copilot agent mode in SSMS (preview)
  • Azure HorizonDB announced as a Postgres-compatible database; public preview noted in the talk
  • Azure Database for PostgreSQL investments: BM25 full text search (preview) and an "Agentic advisor solution accelerator" (GA)
APIs & SDKs
  • Azure SQL Database vector indexing — Used as part of an agentic RAG build path; supports vector search patterns in the data layer.
  • Azure SQL Database semantic search — Used to streamline agentic RAG development patterns over SQL data.
  • Microsoft Foundry — AI platform referenced for model hosting/choice and integration with apps and databases; includes Foundry Local for edge scenarios.
  • Foundry IQ — Used for agentic retrieval (knowledge sources/knowledge base with configurable retrieval instructions, planning via a chat completions model, and reasoning effort controls).
  • Azure Cosmos DB Semantic Reranking · preview — Capability highlighted as a Cosmos DB announcement for improving retrieval quality.
  • Azure Cosmos DB MCP Toolkit · ga — Toolkit called out as a Cosmos DB GA investment.
  • Azure Cosmos DB Agent Kit · ga — Agent-focused kit called out as a Cosmos DB GA investment.
  • Azure SQL Database Microsoft Entra server-level logins and fixed server roles · ga — Server-level identity/authorization capability called out as GA for Azure SQL Database.
  • Databricks Genie — Used in the data analyst agent as the NL-to-SQL heart of the flow (text-to-SQL generation + execution) with configuration over tables/columns and access controls.
  • LangGraph — Used to implement the orchestrator/agent flow graph for the demoed agent system.
  • LangSmith — Used to inspect/visualize agent flows for the demo (LangGraph + Genie).
  • OpenTelemetry — Used for agent observability/monitoring via open telemetry protocols.
What you can build
  • Build a multi-agent assistant for a role-based workflow (e.g., key account management) with an orchestrator plus specialized agents (data analyst, tracking, persona, best practices, debrief).
  • Implement a natural-language-to-SQL agent that enforces per-user data access, generates SQL, executes it, and returns a synthesized answer.
  • Create a compounding-knowledge system: schedule ingestion from enterprise knowledge sources, extract facts with confidence scores, and serve them through a conversational interface.
  • Design an agentic RAG layer with configurable retrieval instructions, planning, and reasoning effort using a managed retrieval service (Foundry IQ).
  • Store agent session memory and workflow artifacts (signals, facts, conversation history) in a database-backed knowledge/fact ledger (Cosmos DB shown).
  • Set up end-to-end observability for agent runs and tool calls using OpenTelemetry.
Code & CLI: aka.ms/build26/BRK224aka.ms/build26cosmosaka.ms/buildsql2026aka.ms/build26horizondbaka.ms/modernizedatabasesaka.ms/build/evals
Azure SQLAzure Database for PostgreSQLAzure Cosmos DBCP&DData
Session page ▶ Watch
BRK225 Breakout From transcript

Data, apps, and agents: the future of app dev with Rayfin

Sachin Patney, Ben Zulauf

Rayfin positions Microsoft Fabric as a managed target for app backends authored in code (and often generated with agents), then deployed via a CLI. The session shows how Rayfin models data, security policies, connectors, and backend logic in TypeScript/YAML, and how templates (including a Power BI-built “Data App”) accelerate analytics-style apps on Fabric semantic models. It also outlines a roadmap from enterprise-internal apps toward broader auth options, more services, and B2B/B2C scenarios.

What's new
  • Rayfin: an SDK + CLI to define an app backend (data, policies, services) in code and deploy it into Microsoft Fabric
  • Rayfin templates available in Fabric UX and via CLI (Blank App, To-do App, Data App), including agent guidance and configuration
  • “Data App” template built with the Power BI team: preconfigured to connect to semantic models and includes charting/visual packages plus agent skills
  • Rayfin connectors: declare connections to data in Fabric OneLake (e.g., databases, warehouses, semantic models) with selective schema import for type-safe use
  • Local development can point at Fabric-provisioned resources; an experimental option exists to run underlying services in local Docker
  • Plan to open-source part of the Rayfin runtime to enable self-hosted deployments
APIs & SDKs
  • Rayfin SDK — TypeScript-based backend authoring with decorators for entities/columns, relationships, and in-code security via roles and policy functions; supports generating and applying migrations when the model changes.
  • Rayfin CLI — Project scaffolding from templates and deployment/provisioning into Fabric (e.g., create a project, then provision and deploy resources with CLI commands).
  • Rayfin connectors — Config-declared connections to existing data in OneLake (including semantic models) with tooling/instructions to pull selected schema into typed classes.
  • Fabric Functions (via Rayfin) — Define backend functions in TypeScript; on deploy, Rayfin packages and deploys them as Fabric functions to run server-side in a sandbox (for notifications/external service calls with credentials).
What you can build
  • Build an internal enterprise app with a Fabric-managed SQL database, Fabric authentication, and policies defined in code
  • Generate a full-stack app with an agent, then deploy it into a Fabric workspace as an app artifact with a child SQL database
  • Create an operational delivery app that logs deliveries (including photos/item condition) and supports customer confirmation
  • Build an analytics application directly on top of a Fabric semantic model, reusing the semantic layer for app experiences
  • Add actionable workflows to analytics apps (e.g., a flag/escalate button that triggers a backend function to notify a team)
  • Standardize internal app creation by publishing organizational templates (with MCP servers/tools, agent instructions, libraries, and sample code)
Code & CLI: github.com/microsoft/rayfinaka.ms/rayfinaka.ms/replitfabricreplit.com/partners/microsoftrayfin.ymlAGENTS.mdRayfin createRayfin up
Microsoft FabricCP&DData
Session page ▶ Watch
BRK229 Breakout From transcript

From Skeptic to Superpower: Real‑World AI Coding Workflows That Scale

Priyanka Sharma, Mario Toffia

Two engineers from Thiink share how they moved from cautious AI experiments to day-to-day coding workflows using Claude-based tooling and GitHub Copilot CLI. The talk focuses on practical failure modes (vendor lockout, cost markups, "drift" in codebases) and the process changes they made—PRDs, architecture constraints, QA gates, and multi-model reviews—to keep agent-driven development maintainable at team scale.

What's new
  • A real-world case of an org-level vendor lockout (Anthropic/Claude) halting AI-dependent workflows, motivating portable, repo-based processes instead of in-app chat memory
  • Thiink's internal "Harness" approach: architecture/scaffolding conventions + immutable specs/ADRs + automated task scheduling and QA gating to reduce LLM code drift
  • Nightly autonomous implementation flow that breaks PRDs into features and dependency-sorted tasks, runs tests/TDD, performs adversarial reviews, and outputs a PR for human merge
  • Multi-model review strategy: using one model for implementation and a different model for QA to catch different failure modes
  • Use of specialized agents/skills (e.g., security auditor, resilience auditor, API expert) invoked during planning and review stages
APIs & SDKs
  • GitHub Copilot CLI — Used in an autonomous "autopilot" flow to orchestrate skills/agents, schedule sub-agents, run QA gates, and output pull requests for review/merge.
  • MCP — Mentioned as something they are writing alongside skills/agents to help automate security/compliance processes for ISO 27000-series-style requirements.
What you can build
  • Turn PRDs into parallelizable engineering tasks using an agent orchestrator with dependency-aware scheduling
  • Run autonomous overnight implementation that produces merge-ready PRs with tests and reviews attached
  • Apply adversarial QA reviews and architecture linting to prevent LLM-driven codebase drift
  • Use a Socratic "grill" step to force clarification of requirements, architecture changes, and security/resilience considerations before implementation
  • Add security and resilience reviews as first-class automated gates for critical-infrastructure software
  • Create business workflows (e.g., RFQ/RFP-like processes) accelerated by LLMs to reduce turnaround from days to minutes
Code & CLI: GitHub Copilot CLICursorClaude (Anthropic)ChatGPTMatt Peacock "grill me" (Socratic method tool; referenced by name)TDDADR
ResiliencyDataWindows APIs
Session page ▶ Watch
DEMSP384 Demo From transcript

Profile and optimize agentic AI on Windows

Freddy Chiu, Vasanth Tovinkere

This demo shows how to profile an agentic AI workflow running locally on Intel-powered Windows PCs by correlating system telemetry (CPU/GPU/NPU and power) with application/framework traces. The speakers walk through finding bottlenecks (e.g., model compilation time, GPU blocking) and improving responsiveness and energy efficiency via offload decisions and model/tool tuning using Intel Unified Telemetry, ITT tracing, OpenVINO, and Windows ML.

What's new
  • Intel “Unified Telemetry” is in preview “starting this week” and provides time-correlated platform telemetry (CPU/GPU/NPU/power) combined with software tracing (via ITT) in a single synchronized time domain
  • OpenVINO runtime is described as “fully instrumented” with ITT domains (e.g., “OV phases”) to enable structured trace breakdowns and querying
  • ITT API can be used to instrument your own app (C/C++/Python APIs mentioned) with near-zero overhead until a collection tool attaches
  • Windows ML CLI is called out as providing operator profiling and ONNX operator compatibility checks
APIs & SDKs
  • Intel Unified Telemetry · preview — Collects time-correlated platform telemetry (CPU/GPU/NPU/power, plus optional ETW) and correlates it with software traces (ITT) for system-to-app analysis.
  • Intel Tracing Technology / ITT API — Open-source tracing/instrumentation API (C/C++/Python mentioned) to add domains/tasks (markers) to applications and correlate with platform telemetry when a collector attaches.
  • OpenVINO — Inference runtime used in the demo; described as instrumented for tracing (e.g., “OV phases”) and used under Windows ML for local inference on GPU/NPU.
  • OpenVINO GenAI — Used to run the local agentic workflow in the demo (LLM plus tool-calling pipeline).
  • Windows ML — Used to build/run a tool that is profiled and correlated with OpenVINO and hardware events; speaker states Windows ML uses OpenVINO underneath for inference.
  • Windows ML CLI — CLI referenced for operator profiling and ONNX operator compatibility.
What you can build
  • Profile an agentic workflow end-to-end and attribute latency/power to specific phases (LLM reasoning, tool calls, summarization) across CPU/GPU/NPU
  • Offload tool execution (e.g., diffusion/stylization) to the NPU to keep the agent responsive while background work runs, improving perceived turn time and power efficiency
  • Instrument a Windows ML-based tool with ITT domains/tasks (e.g., “session creation”, “inference”) and correlate app events with GPU kernel execution and platform counters
  • Identify and reduce model compilation overhead (e.g., by precompiling models) to reach steady-state inference faster
  • Run comparative profiling across device targets (GPU vs NPU) and precisions (e.g., FP16 vs INT8) and generate a latency/energy/peak power table plus recommendations
Code & CLI: ETWITT APIWindows ML CLI
AIAutomationAzureSecurityComputePlatform
Session page ▶ Watch
ODSP916 Pre-recorded From transcript

Design systems for every user, including people and LLMs

Guust Ysebie

This session argues that accessibility is a systems-level requirement for AI reliability, not just usability or compliance, especially for PDFs consumed by both people and LLMs. It explains how PDF rendering primitives (pixels/drawing instructions) lose semantics and how tagged/structured PDFs enable faster, safer, and more accurate extraction than OCR-based pipelines.

What's new
  • Demo comparison: converting a 4-page PDF to Markdown via OCR (Docling) took ~18 seconds versus ~0.075 seconds using embedded PDF structure via iText (~200x faster)
  • OCR-based extraction included unintended content (e.g., watermark text) that could pollute training data and potentially be used for jailbreak attempts
  • Using embedded PDF tags preserved structure (e.g., correct sublists) that OCR missed, reducing hard-to-debug compounding extraction errors
APIs & SDKs
  • Docling — OCR-based PDF conversion used to extract content and convert a PDF into a Markdown file.
  • iText — Java PDF library used to extract embedded text structure/metadata (tagged PDF) and output semantically-structured Markdown faster than OCR.
What you can build
  • Build an LLM data pipeline that converts PDFs into Markdown for downstream model training or extraction workflows
  • Implement PDF text extraction based on embedded structure (tagged PDFs) instead of OCR to improve speed and fidelity
  • Harden document ingestion pipelines by avoiding extraction of non-author-intended artifacts like watermarks
  • Generate accessible PDFs by enabling and validating semantic tags that reflect author intent
Code & CLI: DoclingiTextJava
AIAutomationPlatform EngineeringReliabilityDeveloperData
Session page ▶ Watch

Windows & the edge

DEM346 Demo From transcript

WSL improvements and the new Containers CLI and APIs

Craig Loewen, Pooja Trivedi

Session introduces “WSL containers”: running Linux containers locally on Windows via a new CLI and a NuGet-delivered API for Windows apps. Demos cover basic container workflows, GPU-enabled AI containers, and embedding Linux container execution behind a Windows .exe with per-app isolation and enterprise tooling compatibility.

What's new
  • WSL containers: run Linux containers locally on Windows as a feature of WSL (no separate install required beyond updating WSL)
  • New CLI: WSLC (also aliased as "container") for building/running/listing/attaching to containers
  • New API shipped as a NuGet package (library named WSLCSDK) for Windows apps to create/manage containers
  • Enterprise focus: compatibility called out with tools like Microsoft Defender for Endpoint (MDE) and Intune
  • WSL containers architecture: per-app lightweight utility VM and per-app VHD storage separation
  • Azure Linux 4.0 is available for general use; WSL distro "coming out soon"
APIs & SDKs
  • WSLCSDK (WSL containers API) · preview — Library (delivered via NuGet) that lets Windows applications create and manage Linux containers through WSL.
  • WSLC (CLI) / container (alias) · preview — Command-line tool to run, build, list, and attach to Linux containers running under WSL.
What you can build
  • Run a Debian container locally on Windows and interactively attach/detach
  • Build custom container images from a container file and run them with port mapping to localhost
  • Expose a web service running inside a Linux container to the Windows host via port mapping
  • Run GPU-enabled AI workloads inside a Linux container on Windows (e.g., Jupyter + model fine-tuning) using a GPUs flag
  • Embed a Linux-based engine behind a Windows .exe using the API (demo: Moonray renderer), with automatic VM startup/shutdown
  • Constrain container access to specific Windows folders via volume mounts to limit blast radius
Code & CLI: aka.ms/installwslwsl --updateWSLCcontainer (WSLC alias)wslc ps -awslc attachwslc imageswslc buildrun -it-p (port mapping)-v (volume mount)--gpus allWSLCSDK (NuGet package)Microsoft/WSL
AILinuxWindowsVS CodeWSLLinux Containers
Session page ▶ Watch
KEY01 Keynote From transcript

Microsoft Build opening keynote

Satya Nadella

The keynote lays out Microsoft’s end-to-end AI stack across edge (Windows) and cloud (Azure), emphasizing local “unmetered intelligence” and agent runtimes. It introduces Windows-side local AI expansion (Windows AI/Windows ML, inbox models), new Windows dev experiences, and multiple Azure infrastructure and data services positioned for agentic workloads.

What's new
  • Expanded Windows ML/Windows AI scope to target the full GPU install base for local onboard AI (aka.ms/WindowsAIAPIs)
  • Announced two Windows inbox local models: Aion Instruct (SLM reasoning) and Aion Plan (local agentic loop) (aka.ms/Aion1)
  • Announced Surface Ultra device based on NVIDIA RTX Spark SoC, shipping later this fall
  • Announced Surface RTX Spark Dev Box (waitlist), described as a high-end local AI developer machine, coming in the fall
  • Announced Windows 365 “developer distribution” optimized for developer productivity (aka.ms/Win365developer)
  • Announced Project Solara: a chip-to-cloud platform and reference designs for agent-first devices (aka.ms/ProjectSolara)
  • Announced WSL containers (first-class container support on Windows)
  • Vertical taskbar announced as available in Windows Insider builds
  • Announced preview of Cobalt 200 VMs (ARM-based) for cloud-native and agent workloads (aka.ms/Cobalt200VMs)
  • Announced Horizon DB: fully managed PostgreSQL service on Azure with HA/scale-out features (aka.ms/AzureHorizonDB)
  • Announced GPU acceleration for Fabric Data Warehouse, claiming 7x performance gains (aka.ms/GPUAcceleratedFabricDW)
  • Announced Web IQ: model-agnostic, MCP-native web/news/images/video grounding service for agents (aka.ms/WebIQ)
APIs & SDKs
  • Windows AI APIs (Windows ML/Windows AI) — Local onboard AI across NPUs/GPUs with expanded scope to the full GPU install base.
  • Aion Instruct · announced — Windows inbox local model described as an efficient SLM and “great reasoning model.”
  • Aion Plan · announced — Windows inbox planning model for a local agentic loop with tool access.
  • Windows 365 developer distribution — Cloud Windows endpoint distribution optimized for developer productivity.
  • WSL containers · announced — Native container experience on Windows with first-class support; shown referencing existing container files and leveraging GPU.
  • Winget Configure — Applies a shared Windows/dev configuration file to adjust settings and install dev tools.
  • Cobalt 200 VMs · preview — Next-generation ARM-based Azure CPU VM family designed for cloud-native and agent workloads.
  • Horizon DB · announced — Fully managed PostgreSQL service on Azure positioned for high availability and read-heavy scale-out.
  • Fabric GPU-accelerated Data Warehouse · announced — GPU acceleration for Fabric DW workloads to speed up agent-driven querying/analysis.
  • Web IQ · announced — MCP-native grounding service for agents using fresh web/news/images/video content; model-agnostic and plugs into agent runtimes.
What you can build
  • Build local, onboard Windows AI apps that run across NPUs/GPUs without cloud round-trips
  • Run a local agentic loop on-device (planning + tools) using Aion Plan
  • Use WSL containers for local development with GPU-enabled containers and existing container files
  • Set up a consistent Windows dev machine from a shared configuration using Winget Configure
  • Use an “Intelligent Terminal” with an agent pane (example: GitHub Copilot) to detect errors and suggest fixes while you work
  • Deploy agent-first purpose-built devices via Project Solara and integrate with enterprise sign-in and Azure management
  • Host agent workloads on Azure using Cobalt 200 VMs for ARM-based compute
  • Use managed Postgres (Horizon DB) for high-availability, read-heavy agent memory/storage needs
  • Ground agent responses in fresh web content using Web IQ
Code & CLI: aka.ms/WindowsAIAPIsaka.ms/Aion1aka.ms/Win365developeraka.ms/Maia200aka.ms/Cobalt200VMsaka.ms/ProjectSolaraaka.ms/AzureHorizonDBaka.ms/GPUAcceleratedFabricDWaka.ms/WebIQWinget ConfigureWSL containersMicrosoft EditPowerToys command palletPowerToys "Grab and Move"container images commandGREPStarshipZ Shell (Zsh)HomebrewBTOPGitHub CopilotFleet
AIWindows
Session page ▶ Watch

AI platform & frontier

BRK244 Breakout From transcript

Agent supervision is the new senior engineering skill

swyx (Shawn Wang)

This session argues that as coding agents produce more output, the bottleneck shifts from writing code to supervising agent work with strong specs, constraints, checkpoints, and validation loops. Swyx discusses how "harness engineering" (workflows, tools, and guardrails around models) becomes the practical lever for trust, correctness, and security, including in "dark factory" pipelines with minimal human review.

What's new
  • Speaker claim: OpenAI announced it is merging Codex into ChatGPT (stated as announced the day before the session).
  • Mentioned: OpenAI open-sourced "OpenAI Symphony" as a structured harness/spec approach (described as a repo of Markdown files).
APIs & SDKs
  • Model Context Protocol (MCP) — Cited as part of the modern "harness" around models (alongside skills/workflows) used to shape agent behavior beyond prompting.
  • OpenAI Symphony — Referenced as an open-sourced harness/spec structure using large Markdown prompt/spec files to drive automated agent work and verification around API contracts and module boundaries.
What you can build
  • Design an agent workflow where the human writes a detailed spec and evaluation criteria, and the agent iterates until it passes those checks ("goal loop").
  • Build a multi-layer validation pipeline (spec + strong test suite + online evaluation + feature flags + progressive rollouts) to reduce silent failures when agents ship changes.
  • Constrain agent entropy by focusing supervision on the "narrow waist": API contracts, module surfaces, and types/data structures.
  • Run coding agents in isolated sandboxes that fork the full environment (not just a Git branch) to reduce blast radius and improve safety.
  • Optimize for fast feedback cycles (e.g., aggressively reducing build/compile times) to tighten alignment between humans and agents.
Code & CLI: Claude CodeGitHub Copilot appCursorWindsurfCodexGas Town / Gas City (Steve Yegge)
AzureOSS CI/CD LibrariesVisual Studio
Session page ▶ Watch
BRKSP93 Breakout From abstract

Build AI across client and cloud with AMD ROCm and Microsoft

Anush Elangovan

This session focuses on practical guidance for building, testing, and optimizing AI workloads across client, cloud, and on-prem environments using AMD ROCm as a common software foundation. It highlights portability via integrations with PyTorch and ONNX/MIGraphX to reduce code changes while tuning performance per target platform.

APIs & SDKs
  • AMD ROCm — Common AI software foundation intended to span Radeon, Ryzen AI, and AMD Instinct platforms for building and optimizing AI workloads across environments.
  • PyTorch (ROCm integration) — Integration path to run/port AI workloads with fewer code changes across supported AMD platforms.
  • ONNX/MIGraphX — Tooling/integration mentioned for portability and performance optimization across target platforms.
What you can build
  • Port an existing PyTorch workload to run across client, cloud, and on-prem targets with fewer code changes using ROCm
  • Optimize the same model for different AMD targets (Radeon, Ryzen AI, Instinct) while keeping a common software base
  • Use ONNX with MIGraphX as a portability/optimization layer for deploying AI workloads across environments
AIAPIDeveloperDeveloper TechnologiesDeveloper Frameworks
Session page ▶ Watch
DEM376 Demo From transcript

The story of the Global AI Community that spans every continent

Roelant Dieben, Stephen Simon

This session explains how the volunteer-run Global AI Community grew from its start in 2017 into a global network of local city-based chapters and recurring event formats. The speakers outline what a chapter is, what support the central team provides (templates, platforms, onboarding), and how attendees can join an existing chapter or start a new one.

What's new
  • Global AI Community reports 200,000+ registered members, ~200 chapters worldwide, and 4,600+ events since 2018
  • Agent Camps (formerly Global AI Bootcamps) run as a multi-month seasonal program (roughly February–April) instead of a single month
  • Agent Camps support package includes speaker cards, presentations/workshops, a shared pre-recorded keynote, and sometimes Azure credits
  • Chapters are encouraged to have at least two organizers (co-leads) and run at least one in-person event per quarter
APIs & SDKs
  • Azure credits — Sometimes provided to chapters as support for running Agent Camps
What you can build
  • Find and join a local, city-based Global AI Community chapter via the Global AI Community website
  • Attend local events (in-person, hybrid, or virtual) listed on globalai.community/events
  • Start a new chapter by submitting a form, joining a call with the Global AI Community team, and completing onboarding
  • Run an Agent Camp hands-on workshop event using provided materials (speaker cards, workshop content, keynote)
  • Organize an Agent Con-style larger conference event and collaborate with other chapter leads to source speakers
  • Use Discord to connect with existing organizers for advice before starting a chapter
Code & CLI: globalai.community/eventsDiscord (Global AI Community)
AICommunity
Session page ▶ Watch
OD805 Pre-recorded From transcript

AI Building Blocks for .NET: Add intelligence to your C# apps

A practical tour of .NET “AI building blocks” starting from chat and moving through embeddings, vector search, ingestion pipelines, tool use via MCP, and agents. The session deconstructs a multi-service support-center demo app orchestrated with .NET Aspire, showing how the same abstractions can target cloud models (via Foundry) or local models (Ollama / Foundry Local). It also demonstrates agent patterns in Microsoft Agent Framework, including tool-enabled agents and agent-to-agent (A2A) connections.

What's new
  • Microsoft.Extensions.AI provides a provider-agnostic chat abstraction via IChatClient, enabling easy switching between cloud and local model backends
  • Using Foundry backends with Microsoft.Extensions.AI can support integrated security (Entra ID) instead of API keys
  • First-class C# SDK support for MCP integration with Microsoft.Extensions.AI, enabling tool invocation against MCP servers (demo uses Microsoft Learn MCP server)
  • Microsoft Agent Framework introduces an IAgent abstraction layered on top of a chat client and supports tool-enabled agents (including MCP tools)
  • Agent-to-agent (A2A) is used to connect agents from different stacks (demo references MAF with an NVIDIA NeMo agent) via an agent card endpoint
APIs & SDKs
  • Microsoft.Extensions.AI — Provider-agnostic abstractions for chat (IChatClient), streaming responses, embeddings, and tool/function invocation used across cloud and local backends.
  • Microsoft Agent Framework — Agent abstraction (IAgent) built on a chat client, with support for streaming, tool-enabled agents, and multi-agent/workflow patterns.
  • MCP C# SDK — Client transport and client APIs to connect to MCP servers, list tools, and provide them to an LLM/tool-enabled chat/agent flow.
What you can build
  • Build a Blazor-based support-center app that analyzes incidents, generates images, and provides grounded explanations, orchestrated as multiple services with .NET Aspire
  • Swap LLM backends by changing configuration (e.g., Foundry deployments vs local Ollama models) while keeping the same IChatClient usage
  • Implement local sentiment analysis using an Ollama chat client (Phi-4-mini) with the same chat abstraction used for cloud models
  • Create a simple in-memory vector search over a dataset (movies) using embeddings and cosine similarity, then switch to a persistent vector DB (e.g., ChromaDB mentioned)
  • Build an ingestion pipeline (read → chunk → enrich → embed → write) for markdown content using a semantic similarity chunker, summary enrichment, and a SQLite vector store
  • Connect an app/agent to Microsoft Learn documentation via the Microsoft Learn MCP server (learn.microsoft.com/api/mcp) to answer doc-linked questions
  • Create a minimal agent (name/description/instructions) and stream output token-by-token for improved UX
  • Build a tool-using agent that calls MCP tools and returns documentation links and version info
  • Connect two agents via A2A using an agent card endpoint (/.well-known/agent-card.json) to enable cross-framework agent collaboration
  • Add a text-to-image generation tool (GPT-Image-2) and expose it as an agent tool callable from prompts
Code & CLI: az logindotnet builddotnet runIChatClientIAgentlearn.microsoft.com/api/mcp/.well-known/agent-card.jsonOllamaFoundry LocalLM StudioChromaDBSQLite vector storecosine similarityOllama Monitor
AIDeveloper
Session page ▶ Watch
ODSP902 Pre-recorded From transcript

Build AI-driven UIs in .NET MAUI with design systems

Shriram Sankaran, Vishnu Menon

This session demonstrates an AI-assisted workflow for generating .NET MAUI UI screens while keeping them consistent and production-leaning by grounding the AI in a design system. It contrasts “prompt-only” UI generation (fast but inconsistent) with an approach that adds design tokens and reusable components plus “skills” files to constrain AI decisions and reduce manual rework.

What's new
  • Use a design system (colors, typography, spacing, reusable components, guidelines) to provide UI context that AI otherwise lacks
  • Introduce “skills” files (stored under .agents/skills) that guide an agent with preferred instructions, usage guidance, and troubleshooting references
  • Demo shows AI generating an employee dashboard plus related artifacts (models, design tokens, pages) when prompted with design-system skills and Syncfusion MAUI control skills
APIs & SDKs
  • .NET MAUI (XAML styles) · ga — Uses project resources like Styles.xaml and Colors.xaml as the foundation for cross-platform styling consistency (fonts, colors).
  • Syncfusion .NET MAUI controls — Uses Syncfusion MAUI UI component skills to steer AI toward specific controls and their setup/troubleshooting guidance.
  • Agent “skills” (.agents/skills) — A file-based mechanism (skills.md plus related docs like troubleshooting.md) that the agent reads to constrain UI implementation decisions.
What you can build
  • Generate a .NET MAUI screen (e.g., employee dashboard) that adheres to spacing, typography, and color rules defined in a design system
  • Translate design system definitions into reusable MAUI components and tokens to reduce hard-coded UI values
  • Add control-specific skills (e.g., button) so AI uses preferred UI components and patterns rather than mixing APIs
Code & CLI: .agents/skillsskills.mdtroubleshooting.mdStyles.xamlColors.xamlSyncfusion MAUI button skill ("Syncfusion MAUI button")
AI
Session page ▶ Watch
ODSP911 Pre-recorded From transcript

Build AI-first business apps that turn dashboards into actions

Paul Usher

This session shows how to move a Blazor business app from manual dashboards (filters, sorting, grouping) to AI-assisted intent that directly drives UI actions. Using DevExpress Blazor controls, DevExpress Reporting, and Azure OpenAI via an iChat client, the speaker demos tool calling to operate a live grid, built-in report translation, and a contract review workflow where AI findings are visualized in a report.

What's new
  • DevExpress DxAIChat can be wired to a tool-enabled chat client to invoke approved app methods (function calling) that operate live UI controls like DxGrid
  • DevExpress Report Viewer can provide an in-control AI translation experience (no custom chat UI needed) with configured languages and inline translation in the rendered report
  • Custom workflows can use Azure OpenAI to derive application state (e.g., risky contract clauses) and DevExpress reports can visualize that state via conditional formatting (highlighting/warning tags)
APIs & SDKs
  • DevExpress Blazor (DxGrid, charts, KPI cards) — UI controls used in a Blazor app; grid is programmatically filtered/grouped/sorted/exported based on AI tool calls.
  • DevExpress DxAIChat — Chat control configured with a named chat client service key; can show tool calls and trigger controlled UI actions through a registered tool context.
  • Azure OpenAI (via iChatClient) — Chat completion client used both for tool-calling loops (prompt -> tool invocation -> results back to model) and for direct analysis (contract review).
  • DevExpress Reporting / Report Viewer AI integration (translation) — Program.cs enables reporting AI integration and translation; supports configured languages and inline translation inside the report viewer.
What you can build
  • Let users type natural-language requests that group/filter a live DevExpress grid (e.g., group by customer; filter risky accounts) via tool calling
  • Trigger grid export to Excel from AI intent (AI triggers a controlled export API rather than describing steps)
  • Generate an executive summary of current sales performance by calling an app method (summarize) from the chat experience
  • Translate a DevExpress report inside the report viewer UI using built-in translation tooling and show translated content inline
  • Review a contract by sending full document text to the model, parse clause references, then re-render a report that highlights risky clauses and lists findings
Code & CLI: Visual Studiohome.razorProgram.cs.NET user secretsiChatClientChatClient.GetResponseAsync
AIDeveloperSoftware Development CompanyDevToolsDeveloper Frameworks
Session page ▶ Watch
ODSP929 Pre-recorded From transcript

Build modern .NET apps with Uno Platform, AI, and visual tools

Sam Basu

This session demos building cross-platform .NET apps with Uno Platform from a single C# + XAML codebase targeting mobile, web (WebAssembly), and desktop. It focuses on Uno Platform Studio’s runtime visual design (Hot Design), Hot Reload workflows in Visual Studio/VS Code, and using MCP-based tooling to ground AI agents in docs and validate UI by driving the running app.

What's new
  • Uno Platform Studio includes Hot Design (runtime visual designer) that edits UI while the app is running and stays synced with Hot Reload and IDE code
  • Uno Platform provides two MCP servers: one to ground AI agents in Uno documentation and another to validate and interact with the running app UI (screenshots, visual tree, clicks, text input, keypresses)
APIs & SDKs
  • Uno Platform — Open-source cross-platform .NET stack using a single shared C# and XAML codebase targeting iOS, Android, WebAssembly, Windows, macOS, Linux, and embedded scenarios.
  • Uno Platform Studio — AI and design tooling including Hot Design (runtime visual designer) and a custom AI agent workflow integrated with Hot Reload.
  • Model Context Protocol (MCP) tools for Uno Platform — MCP servers used to ground AI agents with Uno docs and to automate/validate UI by controlling the running app (screenshots, visual tree inspection, click/type/keypress).
  • SkiaSharp — Mentioned as the rendering stack used to achieve consistent rendering and improve runtime performance in Uno apps.
What you can build
  • Scaffold a new cross-platform Uno Platform app in Visual Studio using the template/wizard (platform targets, themes, extensions, features, CI/CD options)
  • Build and run the same app across iOS, Android, WebAssembly, and desktop targets from a single shared C# + XAML project structure
  • Use Hot Design to modify UI at runtime via a visual canvas/toolbox and apply changes through Hot Reload while the app keeps running
  • Use an AI agent (e.g., via IDE chat or terminal workflows) grounded by Uno MCP to search/fetch/summarize Uno docs without leaving the IDE
  • Use Uno App MCP to have an AI agent validate UI by launching the app, taking screenshots, reading the visual tree, and interacting with controls to verify behavior
Code & CLI: platform.unoUno Checkmcp.jsonGitHub CopilotClaude CodeCodexGeminiCursorPlaywrightUno ChefsUno Platform extension (Visual Studio)
AI.NET
Session page ▶ Watch
ODSP932 Pre-recorded From transcript

Ship safer code from your IDE with Aikido

This session demos the Aikido VS Code plugin for shift-left security scanning while you code. It highlights scanning for secrets, code security and quality issues, malware package detection, and in-IDE AI-assisted impact assessment and fixes, plus repo-wide and dependency scans.

What's new
  • Aikido VS Code plugin scans files for secrets, code security issues, IEC issues, and code quality issues during development
  • Pre-commit hook to check for secrets before committing
  • Safe Chain malware package scanner included
  • Aikido MCP runs on created code and executed prompts (positioned as help for “vibe coding”)
  • In-IDE Aikido AI can assess impact, suggest fixes, and apply changes back into the file
  • Workspace-wide scan and dependency scan available inside VS Code
APIs & SDKs
  • Aikido VS Code plugin — IDE extension that surfaces security/quality findings, supports workspace and dependency scans, and offers AI-assisted assessment and fixes.
  • Aikido AI — In-IDE actions to assess issue impact, generate a fix when available, and apply or reject the suggested patch.
  • Safe Chain — Malware package scanner included with the plugin.
  • Aikido MCP — Runs checks on generated code and executed prompts to add security scanning to AI-assisted coding workflows.
What you can build
  • Prevent committing secrets via a pre-commit hook check
  • Review and navigate to specific code findings directly in VS Code
  • Use AI to assess the impact of a reported issue and propose a fix
  • Apply or reject AI-proposed code changes with a diff-style view
  • Run a full workspace scan across a repo to enumerate all files with detected issues
  • Run an open-source dependency scan and identify packages that need updates (e.g., in pom.xml)
Code & CLI: Visual Studio Codepersonal access tokenpre-commit hookpom.xml
AIResiliencySecurity.NETDeveloperVisual Studio Code
Session page ▶ Watch

More sessions

BRK220 Breakout From transcript

Using AI tools to teach old apps new tricks

Nish Anil, Hazem El-Hammamy, Jeff Fritz

This session shows how "agentic modernization" can be used to assess, plan, and execute modernization across large app portfolios, with emphasis on scaling beyond one-repo-at-a-time work. It focuses on GitHub Copilot modernization (developer execution in IDE/CLI) and Azure Copilot (IT-led discovery and planning in Azure), including governance features like rulebooks and a command center.

What's new
  • GitHub Copilot modernization agent is generally available for scaling assessments and upgrades from the CLI across an app portfolio
  • Custom skills for GitHub Copilot modernization are generally available for encoding reusable, org-specific modernization patterns
  • Command Center for portfolio-level tracking/oversight is introduced in Private Preview (self-hostable portal that comes with the modernize CLI)
  • Rulebooks are introduced in Private Preview to encode policies/guardrails that apply to modernization plans, with compliance reporting for traceability
  • Expanded scenario support mentioned: mainframes, Aspire, and ASP.NET Web Forms (noted as available in Private Preview for these scenarios)
  • Azure Copilot (Preview) is positioned as the IT entry point for discovery/inventory, dependency mapping, ROI analysis, and 6R wave planning, with handoff to GitHub Copilot modernization
APIs & SDKs
  • GitHub Copilot modernization agent (CLI) · ga — Runs portfolio-scale assessments, generates migration plans, and automates Java/.NET upgrades; supports local or delegated cloud-agent execution and headless execution for CI/CD.
  • GitHub Copilot modernization custom skills · ga — Org-defined reusable skills (via a centralized skill library/repository) to apply internal libraries/patterns (e.g., Kafka-to-Azure Event Hubs, PII logging handling) during modernization.
  • GitHub Copilot modernization Command Center · preview — Portfolio dashboard to track assess/plan/execute progress, compare assessments and plans, and share status across teams; described as self-hostable and shipped with the modernize CLI.
  • GitHub Copilot modernization Rulebooks · preview — Markdown-authored governance/policy guardrails that influence plan generation and execution guidance (e.g., security boundaries, approved Azure services/SKUs, observability requirements).
  • Azure Copilot · preview — IT-focused modernization planning in Azure portal: discovery/inventory, topology/dependency mapping, ROI analysis, 6R wave planning, and Cloud Adoption Framework aligned landing zones with compliance guardrails.
What you can build
  • Run portfolio-wide code assessments that generate architecture/dependency documentation and consolidated HTML reports for wave planning
  • Automate Java and .NET Framework upgrades end-to-end via the modernization agent CLI
  • Handoff from Azure Migrate discovery to GitHub Copilot modernization by exporting a configuration file and running at-scale code assessment with report upload back to Azure Migrate storage
  • Modernize an ASP.NET Web Forms app to Blazor and then add .NET Aspire scaffolding for orchestration/observability and deploy to Azure Container Apps
  • Apply governance guardrails via Rulebooks so plans consistently include org standards (e.g., auth approach, observability requirements) across different tech stacks
  • Reverse engineer mainframe apps (COBOL/JCL/BMS, DB2/VSAM) into documentation, map data fields to native SQL, then transform into a Java implementation
Code & CLI: aka.ms/ghcp-modernizationaka.ms/ghcp-modernization-preview-signupaka.ms/agentic-modernization/build-blogaka.ms/dotnetday/rsvpAzure MigrateAzure Container AppsAzure Event Hubs.NET AspireOpenTelemetryAzure Key VaultStrutsSpring BootJava 21.NET 10Blazor Server
App ModCP&DReserve
Session page ▶ Watch
BRK221 Breakout From transcript

Idea to production-ready agent in seconds on AI-native runtime

Simon Jakesch, Devanshi Joshi, Gopi Prashanth

This session focuses on what breaks when agent demos hit production—cold starts, unsafe code execution, non-persistent workspaces, and fragile hand-stitched tooling—and maps those issues to runtime requirements. The speakers demo an Azure Container Apps-based setup that runs models on serverless GPUs, hosts agents in isolated sandboxes with persistence/snapshots, and scales bursty workloads. A customer (Auger) explains how they use many agents plus a supply-chain “world model” (AUSCO) to accelerate data integration and decision workflows.

What's new
  • Azure Container Apps Sandboxes introduced in public preview as fast, isolated, stateful compute on demand for running untrusted workloads
  • Azure Container Apps Express positioned as a fast deployment target for web apps (built on top of sandboxes), with “environment-less” operation described in Q&A
  • Azure Container Apps serverless GPU capability highlighted for running custom model containers (e.g., Whisper, Kokoro) with scale-to-zero
APIs & SDKs
  • Azure Container Apps Sandboxes · preview — On-demand isolated sandboxes with persistent workspace, snapshots, resume (disk and optionally memory), network controls, and burst scaling from zero to thousands.
  • Azure Container Apps Express — Fast Container Apps experience for deploying apps (described as best for web apps), built on top of sandboxes.
  • Azure Container Apps serverless GPUs — Run model containers on GPUs with scale-to-zero; demo ran Whisper (speech-to-text) and Kokoro (text-to-speech).
  • Copilot CLI — Used inside sandboxes to let agents create and run code in an isolated environment with inherited credentials from a sandbox group.
What you can build
  • Run LLM-generated code securely in isolated sandboxes instead of a developer laptop (untrusted code execution with guardrails)
  • Give each agent task a per-task isolated workspace that can sleep and resume with disk (and optionally memory) state preserved
  • Snapshot an agent workspace and clone it to reproduce/branch an agent’s environment
  • Autoscale ephemeral sandboxes from zero to thousands for bursty workloads, then scale to zero when idle
  • Host speech-to-text and text-to-speech model containers on serverless GPUs inside Azure Container Apps
  • Provide per-user or per-tenant isolated interactive compute sessions (education labs, multi-tenant platforms)
Code & CLI: aka.ms/aca/build2026-brk221aca/build2026-brk221aka.ms/aca/sandboxesaka.ms/aca/sandboxes/portalaka.ms/aca/expressaka.ms/aca/buildCopilot CLI
App ModCP&DReserve
Session page ▶ Watch
BRK222 Breakout From slides

The honest practitioner's take on agentic AI on Kubernetes

Lachie Evenson

This session argues that agentic AI workloads (stateful, bursty, multi-step, sometimes multi-cluster) benefit from Kubernetes’ composability and operational primitives, but require additional layers for coordinated execution, hardware-aware scheduling, scaling signals, and durable state. It outlines a composable stack on AKS spanning inference (AI Runway + KAITO), training (Ray + Anyscale on Azure), and agent orchestration (skills + MCP + OpenClaw-style reference stacks), then closes with AKS substrate announcements for single-cluster to fleet operations.

What's new
  • Anyscale on Azure (managed Ray) is now in public preview, running in your AKS environment with Azure-native integration and billed through Azure
  • AKS Automatic managed system node pools is generally available
  • Azure Container Linux for AKS nodes is generally available
  • AKS on bare metal is in public preview
  • Fleet Manager for Arc-enabled clusters is generally available
APIs & SDKs
  • AI Runway — K8s-native inference platform with a unified ModelDeployment CRD, UI-driven deployments (including browsing HuggingFace), monitoring/cost estimation, and Gateway API integration.
  • KAITO (Kubernetes AI Toolchain Operator) — Operator suite for LLM inference, fine-tuning, and RAG using CRDs like Workspace/InferenceSet/InferencePool; includes KVCache-aware routing and integrates with Karpenter/NAP and KEDA for provisioning and autoscaling.
  • Anyscale on Azure · preview — Managed Ray offering where the Anyscale Runtime runs inside your AKS environment while an Anyscale-managed control plane provides dev tools, observability, APIs/CLI, and job orchestration.
  • Ray — Distributed compute engine for Python-native workflows across data prep, training, tuning, and serving; positioned as the workload layer on top of AKS for multi-node orchestration and heterogeneous CPU/GPU scheduling.
  • Model Context Protocol (MCP) — Open standard for how agents talk to tools, data, and other agents; used here to expose cluster and Azure operations as agent-callable tools.
  • AKS MCP server — Exposes tools like call_az, call_kubectl, helm, monitoring, and networking to agents via MCP, using Workload Identity for production.
  • Fleet Manager for Arc-enabled clusters · ga — Fleet-level control plane for progressive rollouts, intelligent workload placement, and consistent policy enforcement across cloud/on-prem/edge clusters.
  • Azure Container Linux · ga — Hardened, container-optimized Linux for AKS nodes with reduced package footprint and curated/signed supply chain.
  • AKS Automatic managed system node pools · ga — AKS mode where Microsoft hosts/manages the system node pool for cluster-critical components so teams manage only workload node pools.
  • AKS on bare metal · preview — Runs AKS nodes directly on physical hardware for direct GPU/CPU/NIC/storage access (e.g., NVLink/RDMA) without a hypervisor layer.
What you can build
  • Deploy LLM inference from a HuggingFace model catalog via a UI that generates a ModelDeployment CR and lands on a K8s endpoint
  • Serve LLMs with KAITO using Workspace/InferenceSet/InferencePool CRDs, with KVCache-aware routing and autoscaling on vLLM metrics
  • Autoscale GPU-backed inference with KEDA and provision the right node SKU via Karpenter/NAP based on serving needs
  • Run distributed training, fine-tuning, and reinforcement learning on AKS using Ray, including heterogeneous CPU/GPU coordination and (as stated) fractional GPU allocation
  • Build an operations-focused agent on AKS using MCP tools (Azure and kubectl/helm) plus namespaces/RBAC/service mesh for isolation, permissions, and observability
  • Operate AI across multiple clusters (cloud/on-prem/edge) with fleet-level rollouts, placement, and policy enforcement via Fleet Manager and Arc-enabled clusters
Code & CLI: kubectlhelmKEDAKarpenterGateway APIvLLMSGLangTensorRT-LLMllama.cppHuggingFaceAzure Container Registry (ACR)Entra IDAzure Key Vault
Azure Kubernetes Service (AKS)​​CP&D
Session page ▶ Watch
BRK226 Breakout From transcript

Inside Azure innovations with Mark Russinovich

Mark Russinovich, Darby Kosten

Mark Russinovich tours Azure infrastructure-to-security innovations, focusing on offload-driven server design (Azure Boost), container isolation and migration advances in Azure Container Instances, and AI infrastructure optimizations. The session also covers confidential computing progress (including confidential live migration and Azure Integrated HSM) and closes with an experimental Microsoft Research networking concept (Project Mosaic).

What's new
  • Azure Boost offload card expands storage and networking performance (e.g., remote storage 20 GB/s, remote disks 1M IOPS; networking up to 400 Gb/s) and is deployed across >33% of the Azure fleet; 100% of new SKUs ship with Azure Boost
  • Bare Metal GPU instances shown (demo on an ND144 v6) and described as coming as a general-purpose offering "sometime in the near future"
  • Multipath Reliable Connection (MRC) described as a new Ethernet-based protocol co-developed with OpenAI and partners, shared with the open source community, designed for resilient large-scale GPU training fabrics
  • Guest VM-to-VM RDMA via Azure Boost (MANA) demonstrated with improved inference throughput and reduced time-to-first-token in a prefill/decode split setup
  • First public demo of Azure Container Instances (ACI) container live migration, moving containers between hosts with no observed gap in the tick output
  • Azure Context Cache announced as "coming out in preview now" to remote-cache LLM KV state behind Azure OpenAI endpoints to improve cache hit rate across servers
APIs & SDKs
  • Azure Context Cache · preview — Remote cache for LLM prompt/KV state behind Azure OpenAI endpoints, with cache management/statistics and an associated Context Cache Account backed by storage.
  • Azure Container Instances (ACI) container live migration — Moves running ACI containers/pods between hosts to reduce downtime during host issues/maintenance; shown via early command-line tooling in a public demo.
  • Guest RDMA via Azure Boost / MANA — VM-to-VM RDMA path that bypasses traditional TCP/IP stack and memory copies using the MANA RDMA library/device.
  • Azure Integrated HSM — Server-embedded HSM capability with keys never exposed in VM memory; crypto offload/local cache; standard NCrypt APIs (Windows) and OpenSSL (Linux).
  • Confidential Live Migration — Live migration for confidential VMs using a migration trust domain (MigTD) and policy-controlled migration between approved hosts; shown as not yet in production.
What you can build
  • Run high-throughput AI inference with separated prefill and decode pools and use VM-to-VM RDMA to improve token throughput and time-to-first-token
  • Use Azure Context Cache to increase prompt/KV cache hit rates when requests are distributed across many inference servers
  • Operate ACI workloads with stronger isolation (Hyper-V isolated containers) and plan for reduced downtime via container live migration
  • Build large-scale Ethernet GPU training fabrics with resilience to link/switch failures using MRC-style multipath spraying
  • Perform high-volume signing from VMs using Azure Integrated HSM to keep keys within hardware boundaries while improving signing throughput
Code & CLI: sshlspcinvidia-smivLLM benchmarkF1 Verbs Device Name: MANA 0NCrypt APIsOpenSSL
Session page ▶ Watch
BRK228 Breakout From slides

Modern resiliency from build to recovery through Agentic AI

Rochak Mittal, Adity Agarwal, Shobhit Garg

This session frames resiliency as an agent-first workflow spanning build, operate, troubleshoot, and recovery, aiming to reduce tool and context switching during incidents. It walks through how Azure Copilot, a Resiliency Agent, Azure Advisor (including AI-powered prioritization), Azure MCP Server integrations, and Chaos Studio experiences can help teams start resilient, improve existing workloads, and validate resiliency via drills and recovery planning.

What's new
  • Azure Infrastructure Resiliency Manager is now in Public Preview
  • Azure Chaos Studio Workspaces are now in Public Preview (in Azure Portal June 11); sneak peek at aka.ms/Chaos-Portal
  • Azure Advisor AI-powered prioritization is in Preview
APIs & SDKs
  • Azure Copilot - Resiliency Agent — Azure Copilot domain agent to manage application resiliency, including generating end-to-end IaC templates and guided remediation (e.g., scripts to apply zone redundancy).
  • Azure MCP Server — Connects developer tools (e.g., GitHub Copilot/Cursor) to Azure services such as Azure Advisor recommendations and Azure Backup workflows for data/cyber resiliency checks and configuration.
  • Azure Advisor AI-powered · preview — AI-powered ranking of recommendations by workload criticality/blast radius, progress tracking, and exportable action plans; includes planned AI-ranked resource priority within recommendations.
  • Azure Infrastructure Resiliency Manager · preview — App-centric resiliency experience including recovery plans, recovery readiness checks, and integration points across goals/recommendations, drills, and observability.
  • Azure Chaos Studio Workspaces · preview — Workspace-based chaos experiences to rehearse zone-down scenarios, test AI workloads with injected failures, and replay pre-built real-world outage scenarios.
What you can build
  • Generate zonally resilient IaC templates from Day 1 using the Resiliency Agent in Azure Copilot
  • Scan ARM/Terraform IaC in VS Code/Cursor via GitHub Copilot against Azure Advisor’s recommendation catalog through the Azure MCP server and apply fixes inline
  • Create a Service Group to define an application/workload and evaluate zonal resiliency posture against a defined zonal goal
  • Use the Resiliency Agent to remediate resiliency gaps with guided changes and auto-generated scripts to apply zone redundancy
  • Assess data and cyber resiliency posture via Azure MCP Server and configure vaulted backups using Azure Backup for offsite storage and ransomware recovery/retention needs
  • Run Chaos Studio drills (including zone-down) across services like AKS, SQL, Cosmos, and Storage to validate end-to-end resiliency
Code & CLI: aka.ms/AzureResiliencyaka.ms/AzureChaosStudioaka.ms/Chaos-Portalaka.ms/build/evalsAzure MCP serverAzure MCP server extensionGitHub CopilotVS CodeCursorARM templatesTerraform
ResiliencyAzure CopilotOSS
Session page ▶ Watch
BRK230 Breakout From transcript

Build smarter AI systems in Foundry as models and costs evolve

Yina Arenas, Naomi Moneypenny, Sharmila Chockalingam

This session presents a Foundry playbook for building AI systems that keep improving as model choices, costs, and requirements change. The core shift is to treat evaluation as the product spec, then iterate through model selection, routing, optimization (cost/latency/quality), and observability using Foundry’s model catalog, evaluators, and deployment options.

What's new
  • New Microsoft AI models in Foundry: MAI-Thinking-1, MAI-Image-2.5, MAI-Image-2.5-Flash, MAI-Code-1-Flash, MAI-Transcribe-1.5, MAI-Voice-2, MAI-Voice-2-Flash
  • Claude in Microsoft Foundry running natively on GB300 in Azure
  • Model Router updates: 28 frontier models (including GPT-5.5 and Claude Opus 4.7), Azure Policy support for routing standards, and public preview for fine-tuning the router
  • Rubric Evaluators in Foundry that generate evaluation criteria from an agent definition and support weighted dimensions for aggregate scoring
  • Azure Context Cache for explicit caching (enterprise-owned cache persistence) available via private preview signup
  • Fireworks AI on Foundry announced as general availability for open model inference integrated into Azure
  • Managed Compute in Microsoft Foundry announced for running open models with vLLM, SGLang, and NVIDIA NIM, on Foundry-managed accelerators or bring-your-own Azure VM capacity
APIs & SDKs
  • Foundry Model Router fine-tuning · preview — Customize model router routing logic using your data (and bring fine-tuned models), with Azure Policy support to define/enforce routing standards.
  • Rubric Evaluators (Foundry Evaluations) · announced — Rubric-based evaluators that auto-generate evaluation dimensions from an agent definition and score with weighted dimensions; usable in UI and code.
  • Azure Context Cache · preview — Explicit caching as a purpose-built Azure resource for long-context/multi-turn chats, long-running agents, and cross-region reuse with long TTL.
  • Serverless training API (Foundry) · announced — Serverless RL training with programmatic control over rewards and hyperparameters; produces LoRA adapters without cluster management.
  • Foundry Observability (Tracing/Evaluation/Monitoring) — OpenTelemetry-based tracing with Azure Monitor/App Insights integration, evaluations (built-in + custom + rubric), and production monitoring for token/latency/cost and quality/safety scores.
What you can build
  • Compare and swap models in a single app using Foundry’s model catalog with side-by-side prompt testing and benchmark tradeoff charts
  • Build a compliant enterprise trip-planning agent that decomposes a request into intent routing, receipt extraction, policy reasoning, and itinerary generation
  • Replace a single “one model for everything” prototype with a routed multi-model architecture to reduce cost per task while improving quality
  • Create custom evaluators for domain constraints (e.g., travel-policy compliance) and run them continuously to detect regressions as models/tools change
  • Distill a policy-heavy workload using a teacher model to generate grounded Q&A pairs, then fine-tune a smaller student model for production efficiency
  • Operate an AI system with traces, scheduled evals/red teaming, and Azure Monitor alerts for drift, quality, cost, and latency
Code & CLI: aka.ms/build/BRK230aka.ms/build26-BRK230aka.ms/MAIonFoundryhttps://aka.ms/modelrouterfinetuningaka.ms/RubricEvaluatorshttps://aka.ms/foundry-explicit-caching-signupaka.ms/FireworksAIonFoundryai.azure.comaka.ms/foundry/discordaka.ms/build/evals
Session page ▶ Watch
BRK231 Breakout From transcript

Deploy. Observe. Learn. Reinforcement learning for production agents

Alicia Frame, Omkar More, Long Chen

This session shows how Microsoft Foundry teams use production agent traces to fine-tune smaller models for lower cost/latency, then apply reinforcement fine-tuning when distillation hits a quality ceiling. It walks through evaluation with built-in and custom graders, supervised fine-tuning from traces, reinforcement fine-tuning with tool-enabled rollouts, and a preview of a low-level interactive training API for custom RL recipes.

What's new
  • New: one-click conversion of production agent traces into a fine-tuning dataset (filter/curate and create a training dataset from traces)
  • Preview: interactive (low-level) training API where you bring your environment and reward; the service runs rollouts/scoring/training on a managed Azure GPU cluster
  • Foundry fine-tuning “developer preview” training tier (half cost vs standard tier, runs on low-priority VMs per speakers)
  • Foundry “data zone” SKU introduced at Build for data residency guarantees in the US (for training type selection)
  • Foundry “fine-tuning skill” to drive evaluation and tuning workflows via natural language (as part of GitHub Copilot for Azure skill, and also available standalone per speaker)
APIs & SDKs
  • Microsoft Foundry agent traces -> dataset (Create Dataset) · announced — Converts hosted agent traces into datasets usable for evaluation, supervised fine-tuning, or reinforcement fine-tuning; includes deduplication and PII redaction per demo.
  • Foundry evaluation graders — Out-of-the-box LLM-based graders (e.g., task resolution, intent resolution) plus custom graders written in Python (and discussed as extensible to other languages in low-level flow).
  • Foundry supervised fine-tuning (SFT) — UI wizard and SDK flow to distill a larger “teacher” model into a smaller tuned model using curated traces/datasets; supports checkpoints and continuous fine-tuning.
  • Foundry reinforcement fine-tuning (RFT) — Trains from rollouts scored by a grader; training can invoke real tools during rollouts (demo used tools hosted on a Function App) and exposes metrics like reward and tool-calls-per-rollout.
  • Interactive training API (low-level training primitives) · preview — Low-level primitives (sampling, forward/backward, optimizer step, weight sync, checkpoints) to implement a custom training recipe (shown as a GRPO loop) while Azure manages GPU infrastructure.
  • Fine-tuning skill (GitHub Copilot for Azure skill / standalone skill) · announced — Natural-language driven automation to create graders, run baseline evals, export/filter/dedup traces, and kick off an “autopilot” fine-tuning run to pick models/hyperparameters.
What you can build
  • Distill a production customer-service agent (refund decisions) from a frontier model to a smaller model using captured traces
  • Set up agent evaluations using both built-in graders (task/intent resolution) and a weighted custom Python grader (decision correctness, amount accuracy, format)
  • Create an RFT training dataset from traces that includes user messages + ground truth for grading, without prescribing tool-call trajectories
  • Run reinforcement fine-tuning where the model calls real tools during training (e.g., order details, fulfillment status, policy checks) and iteratively improves reward
  • Use run telemetry (rewards, reasoning-token mean, tool-calls-per-rollout) to detect issues like reward hacking and iterate on graders
  • Implement a custom RL recipe with low-level training primitives (GRPO loop) while offloading GPU work to a managed Azure cluster
Code & CLI: ai.azure.comaka.ms/build26-BRK231aka.ms/ai/discordaka.ms/build/evals
Session page ▶ Watch
BRK232 Breakout From transcript

Post-Training and Deploying Open Source Reasoning Models in Foundry

Vijay Aski, Manoj Bableshwar, Chris Lauren

This session walks through a closed-loop workflow in Microsoft Foundry: deploy an agent, capture production traces, turn traces into datasets, and post-train an open-source reasoning model using SFT and reinforcement fine-tuning driven by evals. The speakers emphasize evaluation as the starting point (the product spec), then show how trained checkpoints can be deployed via Foundry endpoints (including Foundry Managed Compute) and monitored with built-in observability and cost tracking.

What's new
  • Foundry Managed Compute: a new execution path to deploy open/custom models on Foundry-managed accelerators
  • Fireworks AI on Foundry (as presented in the model catalog/deployment flow)
  • Bring Your Own Weights (BYOW): upload/register/import weights (including from Hugging Face) and deploy via the same Foundry endpoint/auth/SDK with integrated evals and observability
  • Bring Your Own Container (BYOC) for custom serving images; BYOC deployments require your own compute capacity
  • New reinforcement learning capabilities in Foundry described as two additions: a code-first path and a low-level API path (private preview mentioned)
APIs & SDKs
  • Foundry evaluators (built-in and custom: prompt-based, code-based, rubric-based) — Define multi-dimensional success criteria (quality, safety/risk, tool-call validity, etc.) and run eval jobs to compare models and gate iterations.
  • Foundry higher-level RFT API (hosted/managed) — Managed reinforcement fine-tuning entry point with shared telemetry, eval harness, artifacts/versioning, and governance.
  • Foundry low-level API ("Tinker API" / GPU primitives; code name "Loom" mentioned) · preview — Lower-level GPU constructs to run custom RL logic from a laptop/CPU client while Foundry manages GPU clusters, images, environment, and networking.
  • Chat completions API (Foundry endpoint snippet shown in deployment view) — Stateless chat-completions style inference against a deployed model endpoint; state must be managed client-side.
  • Responses API (as stated in the agent demo) — Inference mode that can track responses using a previous response handle rather than sending full chat history each time (per the demo description).
What you can build
  • Collect production agent traces in Foundry, inspect tool-call loops and cost per trace, and curate traces into a training dataset
  • Use evals as a contract (correctness, policy compliance, tool call validity, escalation accuracy, safety & privacy) to compare frontier vs open-source models on your own data
  • Post-train an OSS reasoning model with SFT followed by reinforcement fine-tuning (RFT) using rubric/code-graded rewards for verifiable workflows
  • Debug RL training by inspecting rollouts: tool-call order, missed functions, and reward breakdowns per sample
  • Deploy base and fine-tuned models via Foundry Managed Compute or Fireworks, then attach the deployed model to a Foundry agent for tool calling
  • Monitor deployed-model token usage and costs using Foundry metrics/charts and dashboards
Code & CLI: slimeverlTRLRayvLLMSGLangNVIDIA NIMaka.ms/build/BRK232aka.ms/build/evals
Session page ▶ Watch
BRK233 Breakout From transcript

Software defensibility in the era of AI coding

Chip Huyen

Chip Huyen argues that as AI reduces the cost and time of producing software, traditional moats (data, trust/brand, distribution, and expertise encoded into software) weaken because they can be copied or bought. The talk shifts the focus from “how to build” to “what to build” and highlights long-tail opportunities plus new workflow/tooling needs created by AI-in-the-loop development and agentic systems, including safety and reversibility concerns.

What's new
  • No Microsoft Build product/API announcements were made in the transcript; the session is a strategy-focused talk on product moats and AI-era workflows.
APIs & SDKs
  • GitHub API — Referenced as an example of a digital action surface AI agents can call (alongside other internal/external APIs).
What you can build
  • Choose product problems in the “long tail” (big enough to be profitable but not a primary target for frontier labs), such as underserved languages or niche workflows.
  • Design AI coding workflows where the primary artifact is the spec/instructions rather than hand-written code, and adapt review/collaboration accordingly.
  • Build hybrid developer tools combining IDE usability with terminal-level control-plane capabilities (file access, powerful actions) for AI-assisted development.
  • Run coding agents remotely (always-on) and control them from other devices (e.g., mobile), with sandboxing and environment replication.
  • Make software and environments more agent-friendly by shifting effort from GUI-first to API-first design so agents can operate reliably.
  • Engineer systems for reversibility/safety when agents can take irreversible actions (e.g., submitting forms, moving money, or physical robotics actions).
Code & CLI: Claude CodeCodexkillbygpt.comTelegram botGit
Azure CopilotPowerShellAI Toolkit
Session page ▶ Watch
BRK234 Breakout From transcript

Shipping custom models at scale from fine-tuning to inference

Rob Ferguson, Daniel Han, Mark Saroufin

Panel discussion on the practical bottlenecks of post-training (especially RL) and production inference, focusing on memory/perf tradeoffs that turn into real GPU bills. Speakers cover GRPO/RLVR basics, reward design and reward-hacking risks, and system-level performance levers like Torch Compile fusion, CUDA Graphs, and custom GPU kernels.

What's new
  • Fireworks AI described its managed training and inference service as available on Microsoft Azure
  • Unsloth described “memory weight sharing” to share weights between an inference engine and training during RL LoRA runs, aiming to cut memory use by ~50% or more
  • Unsloth described an offloading/standby approach (offload inference weights to RAM between phases) to reduce RL memory usage
  • Panelists asserted most managed-provider inference speedups largely come from op fusion (e.g., Torch Compile) plus CUDA Graphs; kernel work is the remaining “secret sauce”
APIs & SDKs
  • torch.compile (Torch Compile / Torch Inductor) — Fusion compilation to reduce GPU global-memory round trips and improve throughput versus eager execution
  • CUDA Graphs — Technique to reduce GPU launch overhead, especially when shapes are small (e.g., MoE-style workloads)
  • PyTorch — Primary framework context for training/inference performance tradeoffs discussed (eager execution, compilation, kernels)
What you can build
  • Run RL post-training loops (inference-generate + train-update) while controlling memory growth from running separate inference and training engines
  • Apply LoRA instead of full fine-tuning to update a small fraction of weights and support many per-user/per-task customizations
  • Improve GPU inference throughput by prioritizing fused execution (via compilation) and reducing launch overhead (CUDA Graphs)
  • Design RLVR-style pipelines for domains with verifiable rewards (e.g., math-style correctness checks), while guarding against reward hacking
  • Prototype and validate custom GPU kernels (e.g., fused normalization-like kernels) when compiler-level optimizations aren’t enough
Code & CLI: aka.ms/build/evalsUnsloth (Hugging Face)Unsloth (GitHub package)vLLMSGLangllama.cpptorch/_inductor/_config.py
Azure Kubernetes Service (AKS)​​PyTorchPersonalization
Session page ▶ Watch
BRK235 Breakout From transcript

Local models, developer control, and the future of AI runtimes

Michael Chiang, Parth Sareen

Speakers from Ollama walked through why local and hybrid (local + cloud) model execution is returning to mainstream developer workflows, especially for privacy-sensitive and experimentation-heavy agent use cases. They demoed using a single "ollama launch" command to plug open models into existing agent/coding harnesses, and discussed practical constraints like context length, quantization, and unified memory hardware.

What's new
  • Ollama introduced the "ollama launch" command to integrate open models into tools like Claude Code, VS Code, and GitHub Copilot
  • Google DeepMind's Gemma 4 12B Unified Model is available on Ollama (as stated in-session)
  • Ollama Cloud added this year to augment local inference; speakers stated it is optional and has zero data retention and no training on user data
  • Ollama supports MLX-based inference on Apple devices; speakers recommended pulling MLX models from the Ollama model registry for better performance
  • Ollama provides OpenAI and Anthropic API compatibility for developers building apps on open models
APIs & SDKs
  • Ollama OpenAI API compatibility — Build apps against OpenAI-style endpoints while running via Ollama (for open/local/hybrid model execution).
  • Ollama Anthropic API compatibility — Build apps against Anthropic-style endpoints while running via Ollama (for open/local/hybrid model execution).
  • Ollama SDK (Python) — SDK for integrating Ollama into Python applications.
  • Ollama SDK (JavaScript) — SDK for integrating Ollama into JavaScript applications.
  • MLX inference engine (Ollama) — Alternative inference path on Apple devices; speakers referenced support including NVFP4.
What you can build
  • Run a model locally with a single command to chat and iterate quickly without relying on cloud inference
  • Inject open models into GitHub Copilot CLI workflows via "ollama launch copilot" and use it to triage issues and propose fixes from the terminal
  • Use local models for highly private document processing (example shown: categorizing and summarizing a credit card statement PDF) where data never leaves the machine
  • Set up personal agents/harnesses (e.g., OpenClaw, Hermes, Pi) quickly and run them fully locally for privacy
  • Build hybrid routing that chooses between local Ollama and cloud models depending on task difficulty/compute (referenced in published use cases)
Code & CLI: ollama launchollama launch copilotollama launch openclawGitHub Copilot CLIClaude CodeVS CodeCodexCopilot CLIPiOpenClawHermesLangChainMLXllama.cpp
PurviewPurviewAzure DevOpsAgent Observability
Session page ▶ Watch
BRK245 Breakout From transcript

Build the thing that builds the thing

Peter Steinberger

Peter Steinberger shares how he built an ecosystem of small, disposable internal tools to help coding agents ship and maintain OpenClaw faster, with tighter verification loops. The focus is on closing the loop (triage → fix → review → test → visual verification), reducing maintainer workload, and scaling parallel agent work without losing confidence.

What's new
  • ClawSweeper: GitHub Action-triggered Codex workflow to classify, comment on, and close issues/PRs using project rules from vision.md; reruns periodically to auto-close issues fixed on main
  • Discrawl: Discord data crawler used to generate maintainer activity reports and to correlate Discord “what people are screaming about” with GitHub issues/PRs
  • ReleaseBar: dashboard to track project attention signals like days since last release and PR volume
  • Octopool: a shim to reduce GitHub API rate-limit pain by routing read-only public-repo requests through a GitHub App token and mutating requests through the user token
  • Crabbox: cloud “test box” runner that syncs repo changes to a remote machine, runs tests on beefier hardware, and falls back across providers (including AWS and Azure) for reliability
  • Mantis: PR-triggerable flow that spins up Crabboxes to reproduce a bug, records video before/after a fix, and performs visual verification so maintainers can review the video and merge
APIs & SDKs
  • GitHub Actions — Used to start a Codex-in-the-cloud run when an issue or pull request is opened, enabling automated triage/closure and commenting.
  • GitHub API rate limits / GitHub App tokens — Octopool routes read-only public-repository requests via a GitHub App token and uses the user token for mutating requests to avoid running out of personal rate limit.
  • Discord bot access — Discrawl collects Discord channel data via a bot for reports and prioritization signals.
  • Cloudflare — Used as the hosting/edge location for the Octopool shim service.
  • AWS — Crabbox can fall back to AWS when the main compute provider is down.
  • Azure — Crabbox also supports Azure as an additional fallback compute provider.
What you can build
  • Auto-triage and auto-close noisy open-source issues/PRs by applying a project-specific vision.md and leaving an explanatory comment
  • Continuously re-triage backlog by re-running classification weekly to detect issues implicitly fixed by recent merges
  • Generate maintainer health/participation reports by combining GitHub activity with Discord discussion participation
  • Prioritize work by correlating Discord pain points with existing GitHub issues/PRs, then selecting items aligned to a vision document and suitable for autonomous agent execution
  • Run heavy test suites remotely on high-core machines, parallelize across multiple agent sessions, and avoid local machine slowdowns
  • Reproduce cross-platform bugs by spinning up multiple OS boxes in parallel and adding UI access (VNC) for interactive reproduction and automated UI actions (screenshot/click/type)
Code & CLI: vision.mdSKILL.mdSORT.mdClawSweeperDiscrawlReleaseBarOctopoolCrabboxMantisAutoReviewClawpatchCrabfleetClickClock1Passwordrsyncnpm
Microsoft PurviewACASecure App Development
Session page ▶ Watch