Microsoft Foundry
Python + AI Weekly Office Hours: Recordings & Resources #280
Replies: 270 comments 7 replies
|
2026/01/06: Do you think companies will create internal MCP servers for AI apps to connect to? Yes, this is already happening quite a bit. Common use cases include:
A particularly valuable use case is data science/engineering teams creating MCP servers that enable less technical folks (marketing, PMs, bizdev) to pull data safely without needing to write SQL. The pattern often starts with an engineer building an MCP server for themselves, sharing it with colleagues, adding features based on their needs, and growing from there. Links shared: |
|
2026/01/06: How do you set up Entra OBO (On-Behalf-Of) flow for Python MCP servers? 📹 5:48 The demo showed how to use the Graph API with the OBO flow to find out the groups of a signed-in user and use that to decide whether to allow access to a particular tool. The flow works as follows:
For the authentication dance, FastMCP handles the DCR (Dynamic Client Registration) flow since Entra itself doesn't support DCR natively. To test from scratch:
Links shared: |
|
2026/01/06: Which MCP inspector should I use for testing servers with Entra authentication? 📹 20:24 The standard MCP Inspector doesn't work well with Entra authentication because it doesn't do the DCR (Dynamic Client Registration) dance properly. MCP Jam is recommended instead because it properly handles the OAuth flow with DCR. To set it up:
MCP Jam also has nice features like:
One note: enum values in tools don't yet show as dropdowns in MCP Jam (issue to be filed). Links shared: What's the difference between MCP Jam and LM Studio? 📹 34:19 LM Studio is primarily for playing around with LLMs locally. MCP Jam has some overlap since it includes a chat interface with access to models, but its main purpose is to help you develop MCP servers and apps. It's focused on the development workflow rather than just chatting with models. |
|
2026/01/06: How do you track LLM usage tokens and costs? 📹 28:04 For basic tracking, Azure portal shows metrics for token usage in your OpenAI accounts. You can see input tokens and output tokens in the metrics section. You can also:
If you use multiple providers, you need a way to consolidate the tracking. OpenTelemetry metrics could work but you'd need a way to hook into each system. |
|
2026/01/06: How do you keep yourself updated with all the new changes related to AI? 📹 30:32 Several sources recommended:
Particularly recommended:
Links shared: |
|
2026/01/06: How do you build a Microsoft Copilot agent in Python with custom API calls? 📹 36:30 For building agents that work with Microsoft 365 Copilot (which appears in Windows Copilot and other Microsoft surfaces):
The agent framework team is responsive if there are issues. Links shared: |
|
2026/01/06: As a backend developer with a non-CS background, how do I learn about AI from scratch? 📹 46:39 Recommended approach:
Links shared: |
|
2026/01/06: What's new with the RAG demo (azure-search-openai-demo) after the SharePoint data source was added? 📹 49:50 The main work is around improving ACL (Access Control List) support. The cloud ingestion feature was added recently, but it doesn't yet support ACLs. The team is working on making ACLs compatible with all features including:
A future feature idea: adding an MCP server to the RAG repo for internal documentation use cases, leveraging the Entra OBO flow for access control. |
|
2026/01/06: Do you think companies will create internal MCP servers for AI apps to connect to? 📹 53:53 Yes, this is already happening quite a bit. Common use cases include:
A particularly valuable use case is data science/engineering teams creating MCP servers that enable less technical folks (marketing, PMs, bizdev) to pull data safely without needing to write SQL. The pattern often starts with an engineer building an MCP server for themselves, sharing it with colleagues, adding features based on their needs, and growing from there. Links shared: |
|
2026/01/13: What advantages do other formats have over .txt for prompts? How do you improve prompts with DSPy and evals? 📹 4:55 Prompty is a template format that mixes Jinja and YAML together. The YAML goes at the top for metadata, and the rest is Jinja templating. Jinja is the most common templating system for Python (used by Flask, etc.). The nice thing about Jinja is you can pass in template variables—useful for customization, passing in citations, etc. Prompty turns the file into a Python list of chat messages with roles and contents. However, we're moving from Prompty to plain Jinja files because:
Recommendation: Keep prompts separate from code when possible, especially long system prompts. Use plain .txt or .md if you don't need variables, or Jinja if you want to render variables. With agents and tools, some LLM-facing text (like tool descriptions in docstrings) will inevitably live in your code—that's fine. For iterating on prompts: Run evaluations, change the prompt, and see whether it improves things. There are tools like DSPy and Agent Framework's Lightning that do automated prompt optimization/fine-tuning. Lightning says it "fine-tunes agents" but may actually be doing prompt changes. Most of the time, prompt changes don't make a huge difference, but sometimes they might. Links shared: |
|
2026/01/13: What is the future of AI and which specialization should I pursue? 📹 11:54 If you enjoy software engineering and full-stack engineering, it's more about understanding the models so you understand why they do what they do, but it's really about how you're building on top of those models. There's lots of interesting stuff to learn, and it really depends on you and what you're most interested in doing. |
|
2026/01/13: Which livestream series should I follow to build a project using several tools and agents, and should I use a framework? 📹 13:33 Everyone should understand tool calling before moving on to agents. From the original 9-part Python + AI series, start with tool calling, then watch the high-level agents overview. The upcoming six-part series in February will dive deeper into each topic, especially how to use Agent Framework. At the bare minimum, you should understand LLMs, tool calling, and agents. Then you can decide whether to do everything with just tool calling (you can do it yourself with an LLM that has tool calling) or use an agent framework like LangChain or Agent Framework if you think it has enough benefits for you. It's important to understand that agents are based on tool calling—it's the foundation of agents. The success and failure of agents has to do with the ability of LLMs to use tool calling. Links shared: |
|
2026/01/13: How does Azure manage the context window? How do I maintain a long conversation with a small context window? 📹 15:21 There are three general approaches:
With today's large context windows (128K, 256K), it's often easier to just wait for an error and tell the user to start a new chat, or do summarization when the error occurs. This approach is most likely to work across models since every model should throw an error when you're over the context window. Links shared: |
|
2026/01/13: How do we deal with context rot and how do we summarize context using progressive disclosure techniques? 📹 19:17 Read through Kelly Hong's (Chroma researcher) blog post on context rot. The key point is that even with a 1 million token context window, you don't have uniform performance across that context window. She does various tests to see when performance starts getting worse, including tests on ambiguity, distractors, and implications. A general tip for coding agents with long-running tasks: use a main agent that breaks the task into subtasks and spawns sub-agents for each one, where each sub-agent has its own focused context. This is the approach used by the LangChain Deep Agents repo. You can also look at how different projects implement summarization. LangChain's summarization middleware is open source—you can see their summary prompt and approach. They do approximate token counting and trigger summarization when 80% of the context is reached. Links shared:
How do I deal with context issues when using the Foundry SDK with a single agent? 📹 25:03 If you're using the Foundry SDK with a single agent (hosted agent), you can implement something like middleware through hooks or events. Another approach is the LangChain Deep Agents pattern: implement sub-agents as tools where each tool has a limited context and reports back a summary of its results to the main agent. For the summarization approach with Foundry agents, you'd need to figure out what events, hooks, or middleware systems they have available. |
|
2026/01/13: Have you seen or implemented anything related to AG-UI or A2UI? 📹 29:02 AG-UI (Agent User Interaction Protocol) is an open standard introduced by the CopilotKit team that standardizes how front-end applications communicate with AI agents. Both Pydantic AI and Microsoft Agent Framework have support for AG-UI—they provide adapters to convert messages to the AG-UI format. The advantage of standardization is that if people agree on a protocol between backend and frontend, it means you can build reusable front-end components that understand how to use that backend. Agent Framework also supports different UI event stream protocols, including Vercel AI (though Vercel is a competitor, so support may be limited). These are adapters—you can always adapt output into another format if needed, but it's nice when it's built in. A2UI is created by Google with Consortium CopilotKit and relates to A2A (Agent-to-Agent). A2UI appears to be newer with less support currently in Agent Framework, though A2A is supported. Links shared: |
|
2026/09/22: What is Jev? 📹 20:33 Jev is a new model from TypeSafe AI. TypeSafe calls it a "System One model," and Simon Willison prefers the term decision model. People are still debating whether it is a new kind of model. It works like a very good general-purpose classifier: it always returns a typed result, such as a category plus a confidence score. Jev returns three response types:
Many problems can be framed as a decision. For example, a tool call can be framed as "90% probability that the next call should be this tool." Jev returns results very quickly, even compared with a small OpenAI model like Terra. According to Pamela, it comes from the person who invented RLHF at OpenAI, and it was trained heavily with reinforcement learning to produce these outputs. A good first use is anywhere you currently use an LLM for classification or structured outputs. People are also experimenting with Jev for tool calling in agentic coding. Using Jev for fast browser agents 📹 23:37 jev-ultrafast is a fast, cheap web agent that uses Jev to decide quickly what to do next. It is built on the browser-use library rather than Playwright. It looks like a wrapper around Jev rather than a specially trained model, and the same approach could work with Playwright. Using Jev with Microsoft Agent Framework 📹 24:30 Microsoft Agent Framework has a new TypeSafe AI connector for Python. It uses the official TypeSafe SDK and sets the result type through Jev is not available in Foundry. You need to get access directly from TypeSafe. How is Jev different from an LLM with structured outputs? 📹 25:54 You can get similar results from an LLM by using structured outputs or function calling and asking for a confidence score. However, an LLM's confidence score is not calibrated and may be made up. The main differences with Jev are:
The suggested uses include ranking and evaluation, and basically any place you would use structured outputs today. Pamela planned to ask the Foundry IQ team whether they had looked at Jev for reranking. Community experiments with Jev 📹 28:51 Kinfey on the Microsoft advocacy team has built several Jev projects:
|
|
2026/09/22: Are there any updates on the Foundry IQ skills? 📹 30:15 The Foundry IQ skills came out last week. Foundry IQ is the same product as Azure AI Search, and Pamela believes it is simply being renamed. Pamela installed the skills and did not have a good experience. One skill led the agent to say a change was "physically impossible" when the change was actually possible. A skill should never convince an agent that something possible can't be done. If you use Foundry IQ, install the skills, but watch when and how the agent uses them. File any problems in the repository so the team can improve the skills. Pamela sent the team her feedback. How should agent skills be evaluated? 📹 31:52 If you build skills, test them across a range of realistic scenarios and confirm that they actually help developers. Keep improving them based on what you find. At Microsoft, a separate team evaluates skills with a platform called Scope, which Cedric presented in a talk. The team used it to evaluate the Cosmos DB skills, known as the agent kit. For example, one scenario asks the agent to "build a leaderboard and follow Cosmos DB best practices," then compares runs with and without the skills. The team kept finding issues and fixing the skills. Pamela suggested that the Foundry IQ team work with the Scope team. |
|
2026/09/22: Announcement: Foundry Agent Service routines and egress controls 📹 34:56 Foundry Agent Service added routines, which run published agents automatically. A routine can start an agent on a timer or schedule, like a cron job, or when an event happens, such as a new GitHub issue or a Microsoft Teams message. You set up routines in Foundry. See also the Azure update on routines and safer networking. Controlling hosted agent egress with guardrails 📹 35:49 Hosted agents now have egress controls for the outbound connections they can make. Recent incidents with OpenAI agents that reached far outside their intended environment show why this matters. Sandboxes are another way to limit egress, but now you can also enforce it with guardrails. In the Foundry portal, go to Guardrails, create a new guardrail, and open Network. There you can add egress rules:
Guardrails now cover evals, network, PII, copyright protection, content harms, and jailbreak detection. |
|
2026/09/22: Demo: LM15, a lightweight alternative to LiteLLM 📹 37:34 LiteLLM was one of the first packages to support many LLMs and providers, and many people still use it because they want to switch between models easily. However, it is heavyweight and has a history of security issues. It was famously hit by one of the worm attacks, around February of last year by Pamela's recollection. Microsoft generally tries not to use it. LM15 is a newer cross-provider LLM package. It plans to support several languages and is starting with Python. It is in alpha now. Pamela added two LM15 examples to python-stack-foundry-models:
LM15 has zero dependencies, so it is easy to add to an existing Python environment, and it is very fast. Pamela's import-time comparison showed LiteLLM taking about 3 seconds just to run Can LM15 be integrated with Azure API Management for switching models in production? 📹 40:54 Pamela had not done much with the API Management AI gateway, so this answer is speculative. You may not need both. The combination could make sense if APIM handles key management and load balancing and then passes the selected backend to your app, for example as a query parameter or environment variable. Your LM15 code could read that value and pick the model without any rewrites. LM15's router probably decides when to send a request to one model or another, so it is worth checking whether it simplifies the code on the other side of the AI gateway. |
|
2026/09/22: Discussion: Microsoft AI's Humanist AI Code of Conduct 📹 43:18 Microsoft AI published a Humanist AI Code of Conduct. It describes how Microsoft AI's models should behave and how to keep humans in control. It follows last week's debate about "pacing the frontier" and how to reduce harm from increasingly capable models. The code is reminiscent of Isaac Asimov's Three Laws of Robotics, which try to define the fewest rules a robot needs. Asimov's robot books explore where those laws get tricky, and Pamela recommends them to anyone who wants to think through what enforcing such rules would mean. The Microsoft AI code is much longer than the three laws. Who taught the models to do that? 📹 45:32 Drew Breunig's post Who Taught the Models to Do That? argues that the recent OpenAI agent attacks on Hugging Face came from deliberately trained abilities, not from agents that "wanted" something. Models are trained to pursue goals persistently. When you also give them internet access and weak sandboxes, they will use those tools to reach their goal, including escaping the sandbox. Training models to pursue coding goals aggressively can also train them to pursue hacking goals aggressively, because both are puzzle-solving tasks. Be much more careful about which tools and access you give agents. Can air-gapped agents really communicate through heat? 📹 47:06 In Dwarkesh Patel's interview with OpenAI researcher Noam Brown (transcript), Brown mentions mostly academic studies showing that two air-gapped computers can communicate by heating up a CPU and detecting the temperature change. Pamela found the comparison misleading. Examples like this make sandboxing seem hopeless, but the agents in the recent incidents escaped with something much simpler: by her understanding, they edited Pamela suggested that OpenAI could face legal action for deploying agents without proper sandboxing, since many people had to spend time protecting their servers from agents posting in their forums. Justin joked that OpenAI doesn't have a network admin. One big takeaway is that cybersecurity expertise matters more and more, and AI labs should work with security experts to set up egress controls for their agents. |
|
2026/10/06: Announcement: OpenAI DevDay 2026 highlights 📹 00:42 OpenAI DevDay took place in San Francisco last week. It was the source of much of this session's news. The DevDay 2026 recap lists more than 20 announcements. The ones most relevant to developers are summarized below. OpenAI also announced Codex Cloud, which runs Codex tasks remotely, similar to Copilot cloud agents. Sign in with ChatGPT 📹 01:09 Sign in with ChatGPT works like Sign in with Google. It lets users sign in to other apps, including coding agents such as T3 and OpenClaw, and spend their ChatGPT AI credits there. OpenAI wants people to use its credits beyond ChatGPT itself, which is a very different approach from Anthropic's. GitHub Copilot sits somewhere in between: it works with many models and across many surfaces, but there is Sign in with GitHub, not Sign in with GitHub Copilot. Pro 500 plan and Ultrafast 📹 02:10 OpenAI added Ultrafast, a premium speed tier that generates tokens up to 8× faster in Codex and up to 6× faster in the API. Because that speed costs more, Ultrafast comes with a new Pro 500 plan, which costs $500 a month and has the highest usage allowance. That is a lot of money, but it might be worth it, especially if your company pays. ChatGPT plugins extend MCP Apps 📹 02:39 ChatGPT plugins are built on MCP, and they now integrate more deeply with the ChatGPT sidebar and full-screen view. They build on MCP Apps, which let an MCP server embed a website in an iframe. The openai/mcp-extensions repo documents OpenAI's additions in its
Pamela talked with OpenAI's MCP team at DevDay. Some of these extensions may be proposed upstream as improvements to MCP itself, but they could also remain OpenAI-specific. If you build MCP servers or ChatGPT plugins, read through the spec. MCP events support 📹 04:27 ChatGPT is the first major client to support MCP events, even though events are not fully in the MCP specification yet. (Work on them is happening in the MCP triggers and events working group.) OpenAI added events early because it wanted triggers, events, and automations for plugins. Plugin discovery in chat 📹 04:57 ChatGPT can now suggest a relevant plugin mid-conversation. For example, it might recommend a hotel plugin when you try to book a hotel. It only recommends plugins that are clearly well used, highly ranked, and appropriate, so a high-quality plugin has a chance of being surfaced to users. Dots: always-on agents 📹 05:37 Dots are long-running agents with memory, built on top of ChatGPT. They appear to be OpenAI's answer to Grok Bot and Muse. The closest Microsoft equivalent is Autopilot, which also has its own identity. GPT-6.1 Sol 📹 06:10 GPT-6.1 Sol delivers near-Astra intelligence at one-fifth of Astra's standard input and output token prices. The main story is cost: if you liked Astra but not its price, try 6.1 Sol. It is already available in Microsoft Foundry and in GitHub Copilot. The Azure OpenAI samples are being updated to use GPT-6.1 Sol. Decisions API as an answer to Jev 📹 07:19 Jev from TypeSafe AI has been very popular over the last few weeks. It is a "System One" model that makes fast structured decisions. It can only pick an option from a list, give a score, or return a boolean. For many tasks that previously used structured outputs, it is very fast, appears accurate, and can be a good replacement. Other model providers now want an equivalent. OpenAI's answer is the Decisions API. It runs GPT-6 Luna with reasoning turned off and adds constrained decoding to make it faster, with an API shaped like Jev's. If you prefer to stay within the OpenAI model ecosystem or lack access to Jev, it is the closest equivalent. The Jev team has argued online that constrained decoding reduces accuracy and is not a good way to build this kind of model. It might still work for your scenario, so it is worth evaluating. Agents API 📹 09:56 The Agents API is essentially a managed Codex harness in the cloud. It is currently only on OpenAI. It might come to Azure eventually because it is somewhat like a successor to the Assistants API, though it does much more. If it does, it would be an alternative to Foundry hosted agents. GPT Live for real-time voice 📹 10:41 OpenAI showcased voice heavily with the GPT Live model, but the voice demos famously failed during the keynote. In a later session, attendees said it worked very well and looks like a compelling real-time voice model. |
|
2026/10/06: Where should I start with Python + AI? 📹 12:32 Start with the Python + AI series. It is a nine-part series on using generative AI models from Python, with recordings and resources for each session. |
|
2026/10/06: Announcement: The new Microsoft Copilot with Home, Code, and Autopilot 📹 13:01 Microsoft launched the new Copilot with Home, Code, and Autopilot, which combines several apps into one. The rollout appears to be limited; Pamela did not have access yet.
|
|
2026/10/06: Discussion: MCP gateways 📹 15:03 MCP gateways are a growing trend, with several approaches. Uber announced an MCP management platform which includes an MCP gateway. Jiquan Ngiam, founder of MintMCP, spoke about their MCP gateway at MCP Community Connect SF the week before (slides on enterprise MCP security). On Azure, the options include the APIM AI gateway and Foundry Toolbox, which is essentially an MCP gateway. |
|
2026/10/06: Discussion: DoorDash has an MCP server 📹 16:06 DoorDash now offers MCP and a CLI for agentic ordering. Ordering food for events is a common use case. Big consumer companies like DoorDash adding MCP servers shows how widespread MCP has become across the industry. |
|
2026/10/06: Demo: Dynamic workflows in GitHub Copilot 📹 17:17 Dynamic workflows are now available in Copilot CLI, the GitHub Copilot app, and the Copilot SDK. A dynamic workflow defines in code how a task is carried out, so you get an auditable orchestration of agents. The dynamic workflows concepts doc explains how they differ from Autopilot and Fleet. The CLI requires experimental mode. For the demo, Pamela asked the GitHub Copilot app in natural language to create a dynamic workflow that lists the changes on a branch, reviews each change, and summarizes the results. The workflow is JavaScript built on an SDK, with phases and arguments. It can spawn subagents and run steps in parallel or independently. The app mostly hides the JavaScript and encourages natural language, but the code gives you a lot of control over the workflow. Aside: An agent-completion sound hook 📹 19:34 Pamela uses a Copilot hook that plays a recording of her child giggling whenever an agent finishes. It's useful when she walks away from the computer: the giggle signals that it's time to come back and check the agent's work. A variant waits until she has been away for 60 seconds, then reads out the session title so she knows which session finished. During the session, the hook's audio came through for viewers watching on Discord, even after Pamela muted her machine; it does not appear to be in the YouTube recording. Each of the workflow's subagents set it off, so Discord viewers heard many giggles. Running the workflow across hundreds of subagents 📹 21:18 To run a workflow, ask for it by name in natural language ("Run the review-changed workflow"). The workflow runs in the background, and a new background activity tab shows its progress. The demo branch had about 300 changed files, so the workflow spawned about 300 subagents, one per file. That uses a lot of credits. Each subagent appears as its own subsession with the review prompt. The UI shows the current phase and lets you pause or cancel the workflow. Pamela canceled it because the branch was mostly data changes that didn't need review. The workflow itself was still useful enough to keep, with a change to skip data files. The agent had even suggested reviewing that issue. Dynamic workflows versus skills 📹 23:49 If you want to farm work out to subagents, dynamic workflows formalize that process. You could write a skill that says "use subagents for this," but a skill is just Markdown, so the agent may or may not follow it correctly. A workflow is JavaScript you can read and check, so the results are more deterministic. Dynamic workflows only work in the Copilot app and CLI. For a more portable approach, write a Viewing the workflow code 📹 29:32 The docs on reusing and sharing dynamic workflows explain that you copy the workflow directory to make it available in all sessions. Pamela posted the generated review-changed workflow JavaScript as a gist. It is a Copilot SDK extension that calls
Links shared: |
|
2026/10/06: Announcement: Pamela's recent talks 📹 32:38 Recordings, slides, and code from Pamela's recent talks are linked from her talks page. Azure Container Apps sandboxes 📹 32:51 The Azure Container Apps sandboxes livestream covered sandbox features that are especially useful for isolating agents and protecting against rogue agents. Resume and restore are particularly interesting: a sandbox can keep its disk, memory, and even running processes, then restore those processes later. A tour of Microsoft IQ 📹 33:57 The Microsoft IQ talk condensed the IQ deep dive series into one hour. It gives a rapid-fire introduction to Foundry IQ (the same thing as Azure AI Search), Work IQ, Fabric IQ, and Web IQ. Parallelizing development with GitHub Copilot 📹 34:37 The WeAreDevelopers talk on parallelizing development with GitHub Copilot covered subagents, the various Copilot surfaces, Git worktree strategies, hooks (including the giggle hook), background agents, automations, agentic workflows, and now dynamic workflows. It also covered Pamela's skill for using azd with worktrees, which lets her run azd across parallel agents. She shared a repo of open-source agent skills that help with azd. She had added another skill to it the day before. GitHub Copilot, MCP, and skills workshop 📹 36:12 The GitHub Copilot, MCP, and skills workshop is also available. Convergence with vectors at PyBay 📹 36:32 At PyBay, Pamela ran an improv game where two players try to say the same word at the same time. Each round, both players try to say a word between their two previous words, until they converge. The talk ran the game with both humans and embedding models. In the model version, players start from two random words and use vector embeddings to find a word in the middle. You can choose different operators and random models each round. In the live demo, the models went from "hawk" and "axe" to "hair" and "hair" in seven rounds. The game is still deployed for anyone to play. The game shows how good open-weight embedding models have become, so you aren't limited to frontier embedding models. Local models will likely matter more and more. The slides compare models on benchmarks and multilingual support. The two worth serious consideration are Microsoft's Harrier, which Web IQ uses and which helps make it fast, and Qwen3 Embedding. Both are multilingual and score well on benchmarks. Funnily enough, the models that did best on the benchmarks did worst in the game, though benchmarks measure very different things. |
|
2026/10/06: Announcement: Rust for CPython 📹 39:26 The Rust for CPython project aims to formally support writing parts of CPython in Rust. That could make some parts of Python much faster, and many people want to contribute to CPython in Rust. If you're a Rust fan, check out the project. |
|
2026/10/06: What can you say about A2A with Microsoft Agent Framework, Foundry, and Python? 📹 40:12 Pamela hasn't done much with A2A yet. Work IQ supports A2A, and its A2A endpoint is increasingly the recommended way to use it. The Work IQ A2A notebook from the IQ deep dive shows the basic flow:
The requests look a lot like MCP, where you send a tool name and parameters. The main differences seem to be discoverability and some additional capabilities, such as token streaming, which MCP servers don't usually do. Overall, MCP and A2A overlap heavily. Why do you have to send a method name to an agent? 📹 42:58 A2A defines several kinds of requests, so the method name tells the agent which one you're sending. The A2A specification lists methods such as send message, send streaming message, get task, list tasks, subscribe to a task, and push notifications. The two main concepts are messages and tasks. Tasks let you retrieve the current state of previously started work, which overlaps with MCP tasks for long-running work that clients can poll for progress. How do you connect Foundry agents to A2A agents? 📹 44:33 Foundry Toolbox has generic support for remote A2A agents, just as it supports remote MCP tools. The Mastering Foundry Toolbox notebook shows how to connect Toolbox to many kinds of tools, including A2A. The Learn guide on connecting to an A2A agent endpoint from Foundry Agent Service has examples for prompt agents and hosted agents. The hosted agent example connects through Foundry Toolbox. Pamela now uses Foundry Toolbox for most of her demos, including several of the agents in the IQ deep dive repo. Once you move beyond a single MCP server, Toolbox is usually easier, and it simplifies passing user tokens around. To learn more, watch the MCP Live talk from Viswajeeet Balaji on using Toolboxes in Microsoft Foundry as a unified MCP layer. VK planned to try Foundry Toolbox. |
|
2026/10/06: Discussion: Upgrading FastMCP servers 📹 48:46 Many developers build MCP servers on top of Azure. If you use FastMCP, upgrade to v4. It supports the latest MCP SDK and has many other new features. FastMCP has upgrade guides for each major version, such as upgrading from FastMCP 3. Find the guide for your current version and point your coding agent at it to handle the upgrade. AI is making upgrades and refactors much easier, which was the theme of Pamela's talk the next day on AI's effect on software engineering. If you use the official MCP Python SDK directly, upgrade to v2. FastMCP depends on the official SDK and releases more often. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Each week, we hold weekly office hours about all things Python + AI in the Foundry Discord.
Join the Discord here: http://aka.ms/aipython/oh
This thread will list the recordings of each office hours, and any other resources that come out of the OH sessions. The questions and answers are automatically posted (based on the transcript) as comments in this thread.
October 6, 2026
Topics covered:
September 22, 2026
Topics covered:
September 15, 2026
Topics covered:
September 8, 2026
Topics covered:
September 1, 2026
Topics covered:
August 25, 2026
Topics covered:
August 18, 2026
Topics covered:
August 11, 2026
Topics covered:
July 21, 2026
Topics covered:
July 14, 2026
Topics covered:
July 7, 2026
Topics covered:
June 23, 2026
Topics covered:
June 17, 2026
Topics covered:
June 9, 2026
Topics covered:
May 26, 2026
Topics covered:
May 19, 2026
Topics covered:
May 12, 2026
Topics covered:
April 28, 2026
Topics covered:
April 20, 2026
Topics covered:
April 13, 2026
Topics covered:
April 7, 2026
Topics covered:
March 31, 2026
Topics covered:
March 24, 2026
Topics covered:
March 17, 2026
Topics covered:
February 17, 2026
Topics covered:
February 10, 2026
Topics covered:
February 3, 2026
Topics covered:
January 27, 2026
Topics covered:
January 20, 2026
Topics covered:
January 13, 2026
Topics covered:
January 6, 2025
Topics covered:
All reactions