[00:00 · Opening — 10 min block starts] Welcome everyone. Over the next 90 minutes we go from "what is Microsoft Foundry" to a governed agent running in production on Azure, built live from a public repo. Three demos anchor the session: the Foundry Guide agent, an AI Gateway in front of Foundry with Azure API Management, and a menu of short Foundry capability demos — Foundry IQ first. Everything you see is in github.com/frkim/foundry-demo, so you do not need to take notes on code.

Introduce yourself briefly — keep it under a minute; replace the bracketed placeholders before presenting. Set the contract: we only cover the new Foundry model (Foundry resource plus projects), and every feature is labelled GA, Preview or Retiring so nobody leaves with a wrong assumption. Stress that the demos are keyless — managed identity and Entra ID only.

[00:02] Walk the agenda quickly: roughly half concepts, half hands-on. Blocks 4 and 6 are live demos; if anything misbehaves we have a recorded fallback video in the repo. Demo 3 is modular: in the 90-minute format show Foundry IQ plus one or two capabilities the audience cares about; in the extended format run all ten after section 5. Timings are in the speaker notes of every section divider so you can keep pace.

Frame the problem before the product. Most teams we meet have a working prototype but hit walls on sprawl, governance and cost. Agents raise the stakes because they act: they call tools and other agents, so identity and tool-call guardrails become mandatory. Each of these six cards maps to a section later in the session — keep that promise in mind.

One sentence: Foundry is Microsoft's managed platform to build, evaluate and deploy generative AI apps and agents. The name went Azure AI Studio, then Azure AI Foundry, now Microsoft Foundry — the new name shows up across the Ignite 2025 announcements. The renames that matter to engineers: AI Services became Foundry Tools, hubs became a single Foundry resource with projects, Assistants became the Responses API, and the RBAC roles were renamed with the same role IDs, so existing assignments keep working.

These are Microsoft's published figures, each with its date: 70,000 customers and 100 trillion tokens were Build 2025 numbers, before the rename. The catalog line is the live Learn statement — more than 10,000 models from Microsoft, OpenAI, Anthropic, Meta and others. The point is not the size; it's that model choice is now a deployment decision inside one platform.

[00:10 · Section 2 — Platform tour, 15 minutes] We look at the resource model first because every other feature hangs off it: RBAC, networking, deployments and projects. Then models and deployment types, Foundry Tools, the new portal and the developer tooling.

The Foundry resource is a Microsoft.CognitiveServices account of kind AIServices — it's where governance lives: networking, security, model deployments, RBAC. Setting allowProjectManagement to true lets it host child projects; a project is the development boundary for a team — agents, conversations, evaluations, files and traces. Notice there's no hub, no storage account or key vault you must create first. Each project gets its own endpoint, shown at the bottom, and that's the only URL your code needs.

Microsoft is explicit: new agents and model-centric capabilities are only available on Foundry projects, including Agent Service GA. Hub-based projects still exist for prompt flow and managed-compute hosting, but the new portal does not support hubs, standalone Azure OpenAI resources or classic assistants. If you migrate, plan for agent state: threads and messages from the preview agents do not transfer.

This is the entire client bootstrap. AIProjectClient from azure-ai-projects 2.x takes the project endpoint and an Entra credential. From it you get the agents client for creating versioned agents and an OpenAI client already pointed at the Responses API on the v1 route. There is no API key anywhere; locally DefaultAzureCredential uses your az login, in Azure it uses the user-assigned managed identity.

The catalog is broad: OpenAI's GPT-5.x generations, Anthropic's Claude families as GA via the Azure Marketplace, and open-weight models like DeepSeek, Llama, Cohere and Mistral. Model Router lets one deployment pick a model per request; Foundry Local brings the same API to devices. For the demo we use gpt-5.4-mini for the agent and gpt-5.4-nano as the fast comparison model. Always re-check the live catalog — names and versions move quickly.

Deployment type is a residency and economics decision, not a model decision. Global Standard is the default: newest models, lowest price, widest availability. Use Data Zone types when data must stay in the EU, US or APAC zone, provisioned throughput when you need predictable latency at volume, and Batch for large offline jobs at roughly half the cost. Our demo uses Global Standard for both deployments in Sweden Central.

Foundry Tools is the new name for Azure AI Services — the Learn page is literally titled "What are Foundry Tools?". Speech, Language, Translator, Document Intelligence, Content Understanding, Vision, Content Safety and Azure AI Search all sit here. Practically, they share the Foundry resource's identity and RBAC model, so an agent can use them without new credentials. Our video pipeline, for example, uses Speech with the same keyless pattern.

The new portal at ai.azure.com shows Foundry projects only — hubs and classic assistants are not supported there. This table is Microsoft's own GA-readiness snapshot for portal features; note agents core and publishing to Microsoft 365 Copilot and Teams are GA, while agent guardrails, monitoring and the AI Gateway pane are still preview. My recommendation: explore in the portal, but version your agents and infrastructure in code — which is exactly what the demo does.

Developers live in the editor, so Foundry meets them there. The Foundry Toolkit for VS Code is the renamed AI Toolkit. For GitHub Copilot, the Microsoft Foundry skill gives the agent reusable know-how for deployments, agents, evaluation and optimization; the two plugin commands also wire up the Azure and Foundry MCP servers. The DevPack bundles all of this with azd so a new team gets a consistent setup in minutes.

[00:25 · Section 3 — Agents, 15 minutes] This is the heart of the platform. We cover the runtime, the agent types, the tools agents can use, knowledge and memory, and the open-source framework for code-first agents. We finish with the exact Python you'll see running in Demo 1.

Two GA stories exist — don't mix them. The classic, Assistants-based Agent Service went GA at Build 2025 and is now deprecated, retiring March 31, 2027. The next-generation Agent Service, built on the Responses API and wire-compatible with OpenAI agents, went GA on March 16, 2026, together with evaluations. Agents are versioned, conversations are server-side, and you call everything with the standard OpenAI client.

Prompt agents are the default: declarative, no infrastructure, and they're what Demo 1 uses. Hosted agents run your own code in a managed container and accept many frameworks; they reached general availability this autumn. The low-code Workflows feature is the one to avoid for new work — Microsoft retires it on December 1, 2026 and points you to Agent Framework for orchestration. Connected agents are replaced by the A2A tool.

Here's the mental model. Your app uses a plain OpenAI client against the Responses API and references the agent by name. The agent is a versioned bundle of instructions, a model deployment, tools, knowledge and — in preview — memory. Guardrails sit around inputs and tool traffic, and everything emits OpenTelemetry traces into Application Insights, which we'll use in Demo 1.

The left column is everything that's GA today: function calling, code interpreter, file search, Bing grounding, Azure AI Search, OpenAPI, Azure Functions, MCP, outbound A2A and Toolbox. On the right, the preview tools — useful to explore, but call them out explicitly in any production design review. Our demo deliberately sticks to GA tools: the Microsoft Learn MCP server and Code Interpreter.

MCP is the standard way to give agents tools; Foundry supports remote MCP servers as GA, with optional approval round-trips for sensitive calls. A2A version 1.0 lets agents call other agents across platforms; exposing your own agent as an A2A endpoint is still preview. Toolbox lets a platform team curate tools once and publish them behind one MCP endpoint — that's how you stop every team from wiring its own connectors.

Foundry IQ is the dedicated knowledge layer: query planning, parallel hybrid search, reranking and cited synthesis on top of Azure AI Search. It reached GA at Build 2026; Fabric IQ, Work IQ and the serverless tier remain preview. For your code it's just another MCP tool on the agent — the same pattern as the Microsoft Learn server in our demo.

Memory gives agents continuity across sessions with three types: user profile, chat summary and the newer procedural memory. The pipeline extracts, consolidates with an LLM to remove duplicates, then retrieves at run time. Microsoft reported a 7 to 14 point success-rate gain on Tau-bench from procedural memory. It is preview — and memories are personal data, so design retention and deletion from day one.

Agent Framework is the open-source engine that unifies Semantic Kernel's enterprise foundations with AutoGen's orchestration. It hit 1.0 on April 3, 2026; the Python package is at 1.20 today. Use it when you need code-first multi-agent orchestration — it's Microsoft's stated replacement for the retiring Foundry workflows. It speaks MCP and A2A natively and deploys as a Foundry hosted agent, so you don't trade governance for flexibility.

This is the real startup code from the demo, trimmed. One AIProjectClient, one MCPTool pointing at the Microsoft Learn MCP server, and create_version with a PromptAgentDefinition. Each call creates a new immutable version of foundry-guide, which is what you evaluate and roll back. Note require_approval never is fine here because the Learn server is read-only; use always for tools with side effects.

Invocation is the standard OpenAI Responses call. We create a server-side conversation, then reference the agent by name in extra_body. The response contains the final text plus typed output items, including MCP calls — that's how the demo UI shows tool-call chips. For the model-compare tab we call the same client with a model deployment name instead of an agent reference.

Building the agent is half the job; adoption is the other half. Publishing to Microsoft 365 Copilot and Teams is GA and largely automated from the portal. You choose individual or organization scope; organization scope goes through admin approval in the tenant. The same agent version can simultaneously serve your own web app, which is what we'll show next.

[00:40 · Section 4 — Demo 1, 15 minutes] Switch to the browser with the Foundry Guide app already open, plus the Foundry portal and Application Insights in separate tabs. Fallback: the recorded walkthrough in docs/video/foundry-demo.mp4 if the network or the region misbehaves.

Here's the app. Four tabs: agent chat with tool-call chips, model compare between mini and nano, a run history table, and an About page with live configuration. There are zero keys anywhere: the container uses a user-assigned managed identity to call Foundry. Everything ships in a single container — FastAPI serves both the API and the built Vue SPA.

Walk the numbers. One: the browser loads the SPA and calls the FastAPI backend, both in one container app. Two: the backend gets an Entra token from its user-assigned managed identity and calls the Foundry project — agent chat goes to foundry-guide, compare calls go straight to the two deployments. Three: the agent calls the Microsoft Learn MCP server and Code Interpreter. Four: everything is traced into Application Insights with OpenTelemetry.

Follow the checklist; it maps one-to-one to the runbook in docs/session. Start with About to prove the configuration is live, then chat, then compare, then history, then jump to the portal and App Insights to show the same run from the platform side. If anything fails, switch to the recorded video and keep talking over it — the story doesn't change.

This is the request path for a single chat turn. The UI posts to the API, the API authenticates with the managed identity, creates or reuses a Foundry conversation, and runs the agent through the Responses API. The API returns text, the conversation id, the tool calls, token usage and latency, which feed the chips and the history table. Readiness is tied to the agent existing, so a broken deployment never receives traffic.

[00:55 · Section 5 — Observability and governance, 10 minutes] The demo worked; now how do we know it's good, safe and compliant — and keep it that way? This section is mostly preview features, so be precise about status.

Observability in Foundry is OpenTelemetry end to end. Connect Application Insights and server-side agent traces are captured automatically with 90-day retention. On the client, the demo calls configure_azure_monitor and adds OpenAI and agent instrumentation, so each model call, agent run and tool call is a span. Both tracing and the agent monitoring dashboard are preview today — fine for dev, call it out for production sign-off.

Evaluations are GA: run them on datasets or on agent runs, and compare versions before promoting. Continuous evaluation is preview and keeps scoring live traffic. The AI Red Teaming Agent builds on Microsoft's open-source PyRIT and reports an attack success rate; check its current status for your region before relying on it. The agentic risk categories — prohibited actions, data leakage and task adherence — are available in a handful of regions, including Sweden Central where our demo runs.

Guardrails are GA for models and user input; guardrails on tool calls and tool responses — the agent-specific part — are still preview. Prompt Shields, task adherence and custom filtering are GA; spotlighting, which tags lower-trust content to blunt indirect prompt injection, is preview. For agents, assume the tool response is hostile: combine Foundry guardrails, gateway content safety and human approval for tools with side effects.

Governance is where Foundry plugs into the rest of the Microsoft security stack. Control Plane is the central governance surface and can register external A2A agents. Entra Agent ID gives agents real identities with lifecycle and audit; Defender adds threat protection for agents in preview; Purview brings audit, DSPM for AI and eDiscovery through a single toggle. Flag the licensing change: agent discovery and posture in Defender moved to the Microsoft Agent 365 license on July 1, 2026.

[Demo 3 — extended track. In the 90-minute format, run 3.1 Foundry IQ plus one or two demos that match the audience, and present the other slides in 30 seconds each.] Every demo runs on demo-* agents in the same project, never on the app's foundry-guide agent. Steps, code and fallbacks are in docs/session/demo-runbook.md, Demo 3.

Ten independent demos, each with its own fallback. Foundry IQ is the one I always show — knowledge is what turns a clever model into a useful agent. The rest you can pick by audience: platform teams like Toolbox, observability and guardrails; developers like LangGraph and human-in-the-loop.

Portal: Build, Knowledge, open zava-kb and its sources; then Agents, demo-iq, Connect to your knowledge base, and ask the Zava Plus question in the playground. Point at the single MCP tool call, the sub-queries and the citations. Contrast with File search: per-agent files versus a shared, permission-aware knowledge base. Status: the knowledge base object is GA; connecting it to agents and most source types are preview.

MCP gives agents tools, A2A lets agents call agents — Foundry or not. Show the A2A tool call in the run details, then the three-bullet summary. Optional: Operate, Overview, Register asset — external A2A and HTTP agents can be governed by Foundry Control Plane.

Three prompts of increasing difficulty; read the model column — small prompts land on small models. Never promise which model wins; comment on what the output shows. Routing is a cost lever as much as a quality lever: pair it with evaluations.

Guardrails are controls: risk times intervention point times action. Assigned to demo-guarded only — never to the app's agent. With tools and knowledge, the attack surface is the tool response. Defense in depth: tool-response scanning, approvals for side effects, and content safety at the gateway.

Platform teams publish the toolbox, product teams consume one endpoint; change a tool or a skill, bump the version, no agent redeploy. Show it in Build, Tools or in the Foundry Toolkit for VS Code, attach it to demo-toolbox-agent and ask for a cost estimate: 4.80 dollars a day, 144 for 30 days.

Autonomy is a trigger plus an identity plus durable state. Show the background call returning queued immediately, the routine and its run history, then the hosted agent with azd ai agent show. Routines are exposed through the beta client in the SDK — check their status on Learn before calling them GA.

Tracing tells you what happened once; continuous observability tells you every hour whether the agent is still healthy — including quality, scored on sampled live traffic. The evaluation rule is project.evaluation_rules.create_or_update with a ContinuousEvaluationRuleAction; the project's managed identity needs Foundry User.

Same OpenAI-compatible evals API, Foundry's evaluator catalog. Show the T-1 run and its per-row explanations, then Prompt Optimizer on demo-iq, then the Agent Optimizer candidates with the starred winner. Close with CI: the microsoft/ai-agent-evals GitHub Action (preview) gates a release on statistically significant changes.

No framework lock-in: the LangGraph agent and the Deep Agent run on the same Foundry deployment, keyless, and their spans land in the same Application Insights as the Foundry agents. LangChain, LangGraph and Deep Agents are third-party open source; langchain-azure-ai is Microsoft's integration package.

Approve the irreversible, automate the rest. Show the MCP approval request on the Responses API first, then the refund that waits for a human. Resume days later: workflow.run(checkpoint_id=..., responses=...). Deep Agents offer the same with interrupt_on and a LangGraph checkpointer.

[01:05 · Section 6 — AI Gateway, 10 minutes including Demo 2] Foundry governs what happens inside a project; the AI Gateway governs traffic across teams, regions and providers. We'll look at the policies, the architecture, then run the frkim/apim-demo client against a live gateway.

A gateway turns AI consumption into a managed API product. Each team gets a token budget, traffic fails over across regions, and finance gets token metrics with dimensions for chargeback. Safety is enforced centrally, caching reduces cost, and the same gateway governs MCP tools. None of this requires changes in the app beyond pointing it at the gateway URL.

These are the exact policy names to search for in the APIM docs. llm-token-limit enforces rate and quota; llm-emit-token-metric sends token counts to Application Insights. Semantic caching uses a lookup and a store policy and needs an embeddings deployment plus Azure Managed Redis with RediSearch. Load balancing and failover are backend features — pools plus circuit breakers — rather than policies, and MCP server support is GA across the classic and v2 tiers.

Consumers on the left call one gateway URL. Requests flow through the token limit, content safety and the semantic cache, then a backend pool spreads load across Foundry projects in Sweden Central and France Central with circuit breakers. Token metrics land in Application Insights for dashboards and chargeback. The same gateway exposes an MCP server built from a REST API — tools get the same auth, limits and logging as models. This is exactly the frkim/apim-demo topology.

This is what a token-aware inbound section looks like. APIM authenticates to Foundry with its own managed identity, routes to the backend pool, enforces a per-subscription token rate and monthly quota, checks content safety and emits token metrics with two dimensions. Order matters: reject early, before you spend tokens. The full, deployable versions are in the apim-demo repo's policies folder.

MCP support in API Management is GA: export a REST API as an MCP server or proxy an existing one, over streamable HTTP. Today it exposes tools only. From Foundry, the AI Gateway pane and MCP tool governance are preview: you can create a Basic v2 gateway or attach an existing v2 instance. The message: treat tools exactly like models — authenticated, rate-limited and logged in one place.

Switch to the terminal. The apim-demo repo deploys APIM Basic v2, two Foundry projects and all the policies with plain Bicep; the client runs each scenario. Run "load-balance" to show requests alternating regions, "token-limit" to trigger a 429, "content-safety" for a 403, and "metrics" to show token counts in App Insights. For self-study, point people to the Azure-Samples AI-Gateway labs listed here — each is a notebook with Bicep and policies.

[01:15 · Section 7 — Deploy and DevOps, 5 minutes] Everything in Demo 1 was deployed from the repo by a GitHub Actions workflow — no portal clicks. We'll look at the essential Bicep, the pipeline and the identity model.

This is the heart of the infrastructure: an account of kind AIServices with allowProjectManagement set to true, which is what makes it a Foundry resource that can host projects. disableLocalAuth true removes keys entirely; every caller must use Entra ID, which is why the custom subdomain is required. The project is a child resource; its endpoint becomes FOUNDRY_PROJECT_ENDPOINT for the app through a Bicep output.

Deployments are a child array of the account; batchSize 1 serializes them because concurrent deployments on one account fail. The role assignment gives the app's managed identity the Foundry User role scoped to the Foundry resource only — least privilege, no subscription-wide roles. Look up the role ID from the official Foundry RBAC page or az role definition list rather than copying a GUID from a slide.

CI validates everything on each pull request: Python lint, types and tests, the Vue build, Bicep lint and a what-if against the subscription. Deploy logs in with an OIDC federated credential, runs the subscription-scope Bicep, builds the image with ACR Tasks tagged with the commit SHA, redeploys the container app and smoke-tests the readiness endpoint, which only returns 200 when the agent version exists. Even this deck is built by a workflow and published to GitHub Pages.

This table is the entire access model. The app identity gets Foundry User on the account and AcrPull on the registry; presenters get Foundry User plus Speech User for the video pipeline; APIM uses its own identity in Demo 2. Foundry User is the renamed Azure AI User role with the same ID, so nothing breaks after the rename. The same code runs locally and in Azure — DefaultAzureCredential just picks a different identity.

[01:20 · Section 8 — Roadmap and Q&A, 10 minutes] Keep the roadmap to about three minutes and leave at least five minutes for questions. The goal of this block is a short list of dated actions people can take back to their teams.

Read the timeline left to right: Agent Framework announced in October 2025, the Microsoft Foundry name at Ignite, Agent Service GA on the Responses API in March, Agent Framework 1.0 in April, Foundry IQ GA at Build, and hosted agents GA this autumn. The two red dates are the ones to act on: Foundry workflows retire on December 1, 2026 — move to Agent Framework — and classic Assistants-based agents retire on March 31, 2027. Anything else you may have read about broader classic retirement dates isn't confirmed by Microsoft documentation; check the official what's-new pages.

Leave the room with eight concrete actions. The first is easy: clone and deploy the demo repo — it takes one workflow run. The time-bound ones are the retirements: workflows by December 1, 2026 and classic Assistants-based agents by March 31, 2027. The rest are hygiene: keyless auth, tracing, evaluation gates and a gateway for shared capacity.

Everything on this slide is linked from the repo README, so people can just grab the repo URL. The Learn pages are the source of truth for status labels — they change faster than any deck, including this one. If you only open one link, open github.com/frkim/foundry-demo.

[01:25 · Q&A] Open the floor. Good prompts if it's quiet: "How do I migrate an Assistants-based agent?", "When should I use hosted agents instead of prompt agents?", "Where does the AI Gateway sit versus Foundry guardrails?" Use docs/session/qa-prep.md for prepared answers. Close by thanking the audience and pointing once more at the repo URL.