ai
1419 TopicsCopilot Extensibility community call - September 2026
๐ The Copilot Extensibility Monthly Community Call is a recurring virtual gathering designed to keep the global developer and maker community consistently connected, informed, and engaged with the latest advancements in Microsoft 365 Copilot, Copilot Cowork, Microsoft Scout, GitHub Copilot, Microsoft IQ, etc. and their extensibility ecosystem. ๐ Monthly Wednesday call is for all community members to see Microsoft PMs, engineering and Cloud Advocates showcasing the art of possible with the Microsoft AI technologies. ๐ On the 9th of September we'll have following agenda: News and updates from Microsoft Community group photo Anthony Shaw - Personal Microsoft IQ Dashboards with the IQ APIs Sรฉbastien Levert - Introducing the Work IQ Dev Tools Kevin Ly - Understanding Copilot credits in Copilot Cowork and Work IQ ๐ & ๐บ Join the Microsoft Teams meeting live at https://aka.ms/community/CopilotExtensibility-call-invite ๐๏ธ Download recurrent invite for this weekly call from https://aka.ms/community/CopilotExtensibility-call-invite ๐ See you in the call! ๐ก Building something cool with Microsoft AI technologies (Copilot, Cowork, Copilot Studio, Microsoft IQ, etc)? We are always looking for presenters - Volunteer for a community call demo at https://aka.ms/community/request/demo ๐ Resources: Previous community call recordings and demos from the Microsoft Community Learning YouTube channel at https://aka.ms/community/youtube Labs and training material about Microsoft 365 Copilot Extensibility - https://aka.ms/copilotdevcamp Microsoft 365 & Power Platform samples from Microsoft and community - https://aka.ms/community/samples Microsoft 365 & Power Platform community details - https://aka.ms/community/home ๐งก Sharing is caring!38Views0likes0CommentsCopilot, Microsoft 365 & Power Platform Community call
๐ก Copilot, Microsoft 365 & Power Platform weekly community call focuses on different use cases and features within the Microsoft 365 and Power Platform - across Microsoft 365 Copilot, Copilot Studio, SharePoint, Power Apps and more. Demos in this call are presented by the community members. ๐ Looking to catch up on the latest news and updates, including cool community demos, this call is for you! ๐ On 3rd of September we'll have following agenda: Latest on SharePoint Framework (SPFx) Latest on Copilot prompt of the week PnPjs CLI for Microsoft 365 Dev Proxy Reusable Controls for SPFx SPFx Toolkit VS Code extension PnP Search Solution Demos this time Ian Tweedie โ Sometimes a Little Code Saves a Hundred-Step Flow Katrina Frolinka โ Custom Copilot Agent for Document Generation in SharePoint Elio Struyf - Supporting WebMCP within an SPFx extension ๐ Download recurrent invite from https://aka.ms/community/m365-powerplat-dev-call-invite ๐ & ๐บ Join the Microsoft Teams meeting live at https://aka.ms/community/m365-powerplat-dev-call-join ๐ก Building something cool for Microsoft 365 or Power Platform (Copilot, SharePoint, Power Apps, etc)? We are always looking for presenters - Volunteer for a community call demo at https://aka.ms/community/request/demo ๐ See you in the call! ๐ Resources: Previous community call recordings and demos from the Microsoft Community Learning YouTube channel at https://aka.ms/community/youtube Microsoft 365 & Power Platform samples from Microsoft and community - https://aka.ms/community/samples Microsoft 365 & Power Platform community details - https://aka.ms/community/home ๐งก Sharing is caring!31Views0likes0CommentsCopilot, Microsoft 365 & Power Platform product updates call
๐กCopilot, Microsoft 365 & Power Platform product updates call concentrates on the different use cases and features within the Microsoft 365 and in Power Platform. Call includes topics like Microsoft 365 Copilot, Copilot Studio, Microsoft Teams, Power Platform, Microsoft Graph, Microsoft Viva, Microsoft Search, Microsoft Lists, SharePoint, Power Automate, Power Apps and more. ๐ Weekly Tuesday call is for all community members to see Microsoft PMs, engineering and Cloud Advocates showcasing the art of possible with Microsoft 365 and Power Platform. ๐ On the 1st of September we'll have following agenda: News and updates from Microsoft Together mode group photo Rรฉmi Dyon - Introduction of GitHub Harness in Copilot Studio Scott Durow โ Learn the new GitHub Copilot Harness in Copilot Studio with Agent Academy Vesa Juvonen โ Surfacing your business apps in Copilot canvas โ AI Project Portfolio Scenario ๐ & ๐บ Join the Microsoft Teams meeting live at https://aka.ms/community/ms-speakers-call-join ๐๏ธ Download recurrent invite for this weekly call from https://aka.ms/community/ms-speakers-call-invite ๐ See you in the call! ๐ก Building something cool for Microsoft 365 or Power Platform (Copilot, SharePoint, Power Apps, etc)? We are always looking for presenters - Volunteer for a community call demo at https://aka.ms/community/request/demo ๐ Resources: Previous community call recordings and demos from the Microsoft Community Learning YouTube channel at https://aka.ms/community/youtube Microsoft 365 & Power Platform samples from Microsoft and community - https://aka.ms/community/samples Microsoft 365 & Power Platform community details - https://aka.ms/community/home ๐งก Sharing is caring!121Views0likes0CommentsLearn how leading partners drive co-sell success with Microsoft Marketplace
Want to create more Marketplace opportunities and strengthen your co-sell motion? Join Reis Barrie, CEO of Carve Partners, for a practical discussion on how leading software companies use Microsoft Marketplace to accelerate growth, engage Microsoft sellers, and create repeatable paths to revenue. You'll learn the fastest path toward transactable offers and Azure IP co-sell eligibility, explore the seller habits that consistently generate Marketplace opportunities, and discover strategies for identifying high-potential accounts and shortening sales cycles. The session will also cover Marketplace signals, funding opportunities, and proven engagement approaches that help partners build momentum sooner. Whether you're responsible for sales, alliances, Marketplace strategy, or go-to-market execution, this session offers actionable insights you can apply immediately. Stay for the live Q&A and bring your questions. Add to your calendar: How leading partners drive co-sell success with Marketplace50Views0likes0CommentsGrow your sales on Marketplace: App Advisor helps you understand improvements to negotiated deals
Want to dive into the details of negotiated deals and how to create them? Head to App Advisor: https://aka.ms/GrowMySales Not all customers buy apps in the same way. Some need negotiated pricing. Others have specific contract or billing requirements. Some want to buy through a trusted channel partner. Microsoft Marketplace already supports these scenarios through negotiated deals. Now, several new capabilities make those motions more flexible, accessible, and scalable. How do I sell more apps and agents? The best way to sell more apps and agents is to expand your sales footprint, not build more. This means making your apps and agents available through private offers, negotiated deals, and selling through channel partners. These types of deals have always given you flexibility, but new releases have improved their functionality. No matter how youโre selling, chances are good that you could grow your sales with at least one type of private offer (each detailed in App Advisor) Sell directly without another party โ to-customer private offer. Bring a channel partner into a direct customer deal โ Multi-party private offers (MPO). Authorize partners to repeatedly resell your offer โ Resale enabled offers (REO). Sell through a customer's Cloud Solution Provider โ CSP private offer. What changed for negotiated deals Over the last two months, Microsoft has improved capabilities and availability of several types of negotiated deals: Request private offer: Customers can now initiate a conversation about customized pricing and terms directly from an eligible Marketplace listing. Partners configure this when publishing an offer and a button appears on the listing for customers to reach out, reducing the gap between discovering an offer and beginning a negotiated sale. Custom contract lengths: Software companies can create eligible private offers with nonstandard contract lengths defined in months, including terms such as 18 months, with support extending up to 10 years for eligible SaaS and Professional Services scenarios. This helps align Marketplace transactions more closely with contracts negotiated with customers. Flexible billing: Eligible private offers can use customized billing schedules rather than forcing the transaction into a standard cadence. Current Microsoft documentation supports up to 70 installments and terms up to 120 months/10 years in supported scenarios. Expanded MPO reach: After expanding into 30 European countries earlier in the year, MPO expanded to Australia, Japan, and South Africa last month, creating more opportunities for software companies and channel partners to collaborate on Marketplace transactions. Expanded REO reach: REO expanded to New Zealand, extending the channel-led resale model into another market. What comes next Interested in expanding your sales footprint with minimal overhead? Follow along in this series as we discuss each type of private offer and advantages of each. To get started today, explore your negotiated selling options with App Advisor: https://aka.ms/GrowMySales125Views4likes0CommentsBeyond Tokens: Rethinking AI Economics with Microsoft Foundry
Beyond Tokens: Rethinking AI Economics with Microsoft Foundry From the cost of intelligence to the value of outcomes Enterprise AI has an accounting problem. Executives expect agentic AI to return roughly 171% on investment, according to one widely cited survey. Yet McKinsey finds only about 39% of organizations can attribute any earnings impact to AI at all. Both numbers can be true at once โ because the gap between them is not a technology gap. It is a measurement gap. For the first few years of generative AI, one number dominated the economics conversation: tokens. How many tokens did a model consume? What was the cost per million tokens? Could a smaller model perform the same task? Those questions mattered when enterprises were experimenting with AI. They are no longer enough as AI moves into production. An enterprise agent doesn't simply consume tokens. It reasons, retrieves context, invokes tools, calls APIs, verifies its work, retries unsuccessful actions and sometimes escalates exceptions to humans. The model call might cost pennies. The business outcome could cost considerably more. Which leads to an increasingly important question: What is the right economic unit for intelligence? From AI experimentation to economic accountability The first wave of enterprise AI was about possibility: Can AI do this? The next wave is about production, as AI becomes embedded in software engineering, customer service, finance, healthcare and supply chains. And production changes the question: Should AI do this and at what cost? Microsoft has moved decisively onto this ground. In August 2026, the Microsoft Foundry team launched its Economics of Agent Optimization series, arguing that "tokens have become the new unit of technology spend" and that AI should be run as a managed investment system. On the latest earnings call, Satya Nadella described Microsoft's objective as "advancing the frontier on the cost-to-outcome curve, ensuring every customer can turn tokens into business results." The discipline is going mainstream too: 98% of FinOps teams now manage AI spend, up from 31% two years ago. Microsoft's series is largely about the numerator of that curve - making every request, agent and dollar more efficient. This article is about the denominator: what an outcome is, what it truly costs, and what it is worth. The evolution of Microsoft Foundry reflects the same shift. At Build 2026, Microsoft expanded the conversation beyond building agents toward tracing behavior, evaluating quality, monitoring production performance, optimizing agents and connecting their operation to ROI. Think of the progression as: Trace โ Evaluate โ Monitor โ Optimize โ ROI This is more than a technology roadmap. It represents a shift from observing AI as technology to managing AI as an economic asset. Tokens became the unit of spend. They were never the unit of value. Consider two AI agents handling the same customer-service workflow. Agent A costs $0.08 per interaction. Agent B costs $0.20. Agent A appears cheaper. But suppose Agent A successfully resolves only 55% of cases, while Agent B resolves 90%. The remainder require retries, additional reasoning or human intervention. Which agent is actually cheaper? The inexpensive interaction may produce the expensive resolution. This illustrates a fundamental problem: We often measure AI where it is consumed rather than where value is created. Tokens are a unit of consumption. Businesses operate in outcomes. A customer-service leader cares about issues resolved. An engineering leader cares about high-quality software reaching production. A finance leader cares about reconciliations completed accurately. The economic denominator needs to move closer to the business. The AI Economic Ladder I think of this evolution as an AI Economic Ladder: Tokens โ Interactions โ Tasks โ Outcomes โ Value Each step moves measurement closer to what the enterprise actually cares about. At the token level: What intelligence did we consume? At the interaction level: What did each AI run cost? At the task level: What did it cost to complete the work? At the outcome level: What did a successful result cost? At the value level: Was the outcome worth creating? An AI system can become more efficient at every technical metric while creating little economic value. Conversely, an expensive AI workflow could be extraordinarily valuable if it prevents revenue leakage, reduces operational risk or accelerates a critical business process. The objective isn't cheaper AI. It is better economics. Not every completed task is a successful outcome There is another complication. If an agent completes a workflow, should we count it as a successful outcome? Not necessarily. A meaningful outcome needs three characteristics: Completed. Quality-gated. Attributable. It must reach its intended end state, meet an explicit standard for quality, accuracy, safety or business acceptability, and be attributable to the agent or workflow that produced it. That gives us a more meaningful measure: Cost per Successful Outcome = Fully Loaded AI Workflow Cost / Completed, Quality-Gated, Attributable Outcomes The denominator becomes real only when named in business language: cost per prior authorization resolved in healthcare, per pull request triaged and tested in engineering, per disputed invoice reconciled in finance operations. If you cannot name the outcome in a sentence the process owner recognizes, you are not ready to measure it. The quality gate matters. With AI, "the system ran successfully" and "the system produced a good outcome" are not the same thing. Microsoft Foundry's tracing and evaluation capabilities become economically important for precisely this reason. Evaluation isn't merely quality control. It helps determine what gets counted as value. What does an AI outcome really cost? The true economic footprint goes far beyond inference: Model + Reasoning + Grounding + Tools + Orchestration + Infrastructure + Retries + Evaluation + Governance + Human Intervention Human intervention is particularly easy to overlook. Every time someone must review, correct, approve or recover an AI-generated outcome, the economics change. The same applies to verification. An agent reaching an acceptable result in three steps has different economics from one requiring fifteen steps and multiple retries. And verification is not a rounding error โ it is the bulk of the bill. McKinsey's 2026 analysis of production agentic workflows found roughly 60% of an agentic task's cost is tied to refining answers โ checking, repairing, re-verifying โ not generating the initial response. Most of what you pay for is not intelligence. It is assurance. This means quality and economics are connected. The quality bar you set influences the cost you pay. The challenge isn't simply minimizing consumption. It is finding the right balance between quality, cost, speed and risk. Cost per outcome is only half the equation Now imagine two agents. Both cost $5 per successful outcome. One saves an employee ten minutes of administrative work. The other prevents $500 in revenue leakage. Their cost efficiency is identical. Their economics clearly aren't. So we need to move another step up the ladder: from Cost per Outcome to Value per Outcome. The question isn't only how cheaply AI can complete the work. It is: How much economic value does this outcome create relative to the intelligence required to produce it? Now the CIO, CFO, CAIO and business leader have a common conversation. Give every outcome an Intelligence Budget Not every problem deserves the smartest model available. Classifying an email may require relatively little intelligence. Resolving a complicated customer complaint may justify more context and reasoning. Assessing the risks in a multimillion-dollar contract may justify sophisticated reasoning, multiple validations and human review. Every business outcome therefore has an economically rational amount of intelligence worth spending on it. Call it an Intelligence Budget. This changes the architecture question from which model should we standardize on, to: What combination of model, reasoning, context, tools and human judgment does this outcome deserve? This is where Microsoft Foundry's model router becomes interesting. Individual requests can be dynamically routed so simpler work doesn't consume the same model resources as complex reasoning. If the Intelligence Budget is the economic principle, intelligent routing is one way of operationalizing it. The future enterprise AI architecture won't be about one model doing everything. It will route intelligence according to the economics, quality and risk of the outcome. Making AI economics observable None of this works without visibility. An AI system can be technically healthy and economically unhealthy โ responsive and error-free while repeatedly choosing inefficient reasoning paths, invoking unnecessary tools or producing outputs requiring expensive human correction. AI economics and AI observability are becoming inseparable. Microsoft Foundry increasingly connects these disciplines. Tracing shows what an agent did. Evaluation determines whether it met required criteria. Observability helps monitor production behavior. Agent optimizer can test improvements across prompts, skills and models. Microsoft's emerging ROI capabilities take the next step by connecting operating costs with measures such as task completion, time saved and cost efficiency. Attribution is the bridge to the finance conversation. Teams place Azure API Management in front of Foundry endpoints as an AI Gateway, stream token telemetry into Application Insights, and use Entra Agent ID to give every agent run a discrete identity that maps cost to its cost center. Microsoft Agent 365 extends the discipline tenant-wide โ spending policies, budget caps and departmental chargeback across Microsoft and third-party agents. Together, they create something enterprises have historically lacked: A feedback loop between how intelligence is consumed and what that intelligence accomplishes. The paradox of cheaper intelligence There is another reason AI economics will become more important as models get cheaper. The Jevons paradox suggests that when technology makes a resource cheaper and more efficient, total consumption can actually increase. AI may experience the same effect. Cheaper intelligence enables more agents, more reasoning and more workflows that were previously uneconomic. So we could see cost per unit of intelligence fall while total intelligence consumed rises. Cheaper AI may therefore produce larger AI bills. That isn't necessarily bad โ provided value grows faster than consumption. The objective isn't minimum AI consumption. It is maximum economic value from AI consumption. From workload economics to portfolio economics As AI scales, economics becomes a capital-allocation question. I see three levels. Workload Economics: Is this AI system running efficiently? Outcome Economics: Is it producing quality outcomes economically? Portfolio Economics: Where should we put our next AI dollar? That final question will become increasingly important. An enterprise with hundreds of AI initiatives shouldn't assume every one deserves continued investment. Some should scale. Some need optimization. Some should be redesigned or consolidated. And some should be stopped. The ability to experiment cheaply created the first explosion of enterprise AI. The discipline to allocate capital intelligently will determine what scales. Who owns AI economics? Once an agent becomes part of how work gets done, its economics cannot remain purely an IT metric. The business understands the value of the outcome. Technology understands the architecture and optimization levers. Finance brings economic discipline and comparability. That suggests a shared model: Business owns the outcome. Technology owns the optimization levers. Finance owns the economic discipline. AI economics ultimately isn't just a technology-cost conversation. It is a business-performance and capital-allocation conversation. From abundant intelligence to intelligent economics We are entering an era where intelligence is becoming an increasingly abundant, programmable and variable-cost resource. Microsoft Foundry and the broader Microsoft AI stack are making it easier to build, evaluate, observe, optimize and govern that intelligence. But abundant intelligence does not guarantee abundant value. Enterprises still need to decide where AI belongs, how much intelligence each problem deserves, what defines a successful outcome, when humans should remain involved and which AI investments deserve more capital. The winners won't necessarily use the cheapest models. They won't consume the fewest tokens. And they won't be the organizations that build the most agents. They will become exceptionally good at moving up the AI Economic Ladder: from consumption, to outcomes, to value. Because the next era of AI won't be won by organizations that buy intelligence most cheaply. It will be won by those that convert intelligence into value most efficiently. Where to start: the first 90 days Define the denominator for your top three agents โ what counts as done, what quality gate applies, who signs off. Instrument attribution โ Azure API Management as an AI Gateway, token telemetry to Application Insights, Entra Agent ID on every run. Wire evaluations into the cost pipeline so only quality-gated outcomes count. Set Intelligence Budgets โ model router per request, agent optimizer against your evaluators, Agent 365 policies as circuit breakers. Stand up a joint monthly review โ business, technology and finance on one dashboard: outcomes delivered, cost per outcome, value per outcome. Frequently asked questions What is Cost per Successful Outcome in enterprise AI? The fully loaded cost of an AI workload divided by outputs that were completed, quality-gated and attributable - for example, cost per prior authorization resolved or per pull request triaged. It turns token metrics into the unit economics of AI-performed work. What is an Intelligence Budget? The economically rational amount of intelligence - model capability, reasoning, context, tools and human review โ worth spending on a given outcome, based on its value and risk. Model router in Microsoft Foundry is one way to operationalize it. Why do AI agents cost more than single model calls? One agent task can involve planning, tool calls, retries and verification - many model calls with compounding context. Research on production agentic workflows attributes roughly 60% of task cost to refining and verifying answers, not generating the first response. Will falling model prices make AI cost management unnecessary? No. By the Jevons paradox, cheaper intelligence expands consumption, so total AI spend typically rises as unit prices fall. The discipline that matters is maximizing value per unit of intelligence. Who should own AI economics? A shared model: the business owns the outcome and its value, technology owns the optimization levers, and finance owns the economic discipline and review cadence. #MicrosoftFoundry #Agent365 #AzureAI #FinOps #AgenticAI #AIAgents #Azure #MicrosoftCostManagement #AIEconomics #Tokens References Microsoft Azure Blog: "The Economics of Agent Optimization: From pilots to measurable returns" (August 12, 2026) Microsoft FY26 Q4 earnings call (Satya Nadella, July 2026) McKinsey โ "Cost versus value: managing agentic AI system performance" (July 2026) FinOps Foundation โ State of FinOps 2026; Microsoft Learn โ Model router for Microsoft Foundry; Agent optimizer; Foundry Control Plane cost optimization126Views0likes0Comments๐ Foundry Toolkit for VS Code โ August 2026 Update
This is the August round-up for the Foundry Toolkit for VS Code. Four releases shipped this month: 1.6.7, 1.6.8, 1.6.9, and 1.6.10. August was about turning agent development into a workflow you can follow end to end โ start from the right path, connect reusable tools and other agents, run with real user isolation, and inspect exactly where the time and tokens went. Have feedback or hit a bug? File an issue on GitHub โ the roadmap moves on what you tell us. Highlights Prompt Agent toolboxes โ attach a centrally managed toolbox, inspect its tools and skills, manage versions and approval policies, and configure nested tools without leaving Agent Builder. 1.6.10 Agent-to-Agent connections (preview) โ connect an Agent2Agent (A2A)-compatible agent from a configured connection, the Foundry account catalog, or a custom HTTPS endpoint. 1.6.10 Agent Inspector Overview โ read a latency waterfall and an ordered timeline of model, reasoning, and tool activity for all runs or one selected run. 1.6.9 User-scoped Hosted Agent sessions โ set a user identity so Responses conversations and session files stay isolated per user. 1.6.8 A clearer Create Agent start โ choose Microsoft Agent Framework, Copilot SDK, LangGraph, Copilot-assisted coding, Agent Builder, or the full sample catalog from one redesigned page. 1.6.9 ๐ค Create Agents โ start on the right path, then stay in context Starting an agent shouldn't begin with choosing the wrong abstraction. The redesigned Create Agent page gives you direct routes to Microsoft Agent Framework, Copilot SDK, and LangGraph samples, Copilot-assisted coding, Agent Builder, and the complete sample catalog. You decide whether you want code, a guided build, or a prompt agent first โ not after scaffolding the wrong project. 1.6.9 Hosted Agent setup is also less brittle. You can choose Skip for now during model setup even when existing deployments fail to load, then wire the model connection later. Administrator-connected Foundry models now appear alongside regular deployments in playgrounds and Hosted Agent creation, so the models your organization already configured are available where you build. 1.6.8 1.6.9 Once an agent is running, identity matters. The Hosted Agent Playground can now set a user identity for Responses conversations, keeping conversation state and session files isolated for each user instead of blending everyone into one test session. And when somebody sends you a Microsoft Foundry portal link, deep links can open that named Hosted Agent's Details or Optimization page directly in VS Code โ not the portal home, not a search screen. 1.6.8 1.6.10 ๐ง Toolboxes and A2A โ connect capabilities once, reuse them An agent with five tools can become five separate configurations, five approval stories, and five places to make the same update. Toolbox changes that shape: it packages centrally managed tools behind one Model Context Protocol (MCP)-compatible endpoint, with shared versioning and policy controls. In August, Prompt Agents gained toolbox workflows inside Agent Builder. Open Add tools to browse toolboxes, or use Add to Prompt Agent from the Toolbox resource list. The attached toolbox appears as a collapsible card where you can inspect tools and skills, switch versions, configure approval policies and nested tools, replace or remove the toolbox, or opt out. You manage the collection โ not a loose pile of one-off connections. 1.6.10 Agent-to-agent composition arrives in the same flow. Agent-to-Agent connections (preview) let you add an A2A-compatible agent from an existing connection, the Foundry account catalog, or a custom HTTPS endpoint. Attach it directly to a Prompt Agent or put it inside a toolbox for reuse across agents and runtimes. Your pipeline can now be agent โ toolbox โ specialist agent โ with the connection managed as a real resource instead of buried in prompt text. 1.6.10 ๐ Agent Inspector โ see the run, not just the answer A final answer can look right while the run behind it is slow, expensive, or calling the wrong tool. Agent Inspector now gives you the sequence and the evidence. The new default Overview tab shows every run or one selected run through two synchronized views: a latency waterfall and an ordered timeline of model, reasoning, and tool activity. Response footers add the model, duration, total tokens, and timestamp; hover over the token total to split input from output. Raw reasoning and reasoning summaries appear in separate collapsible sections when the agent provides them. 1.6.9 Tool inspection goes deeper in 1.6.10. Calls are grouped by response run, with status, call ID, arguments, and results, and each Responses event can show when it reached Agent Inspector. The Overview waterfall and timeline now scroll independently, while long streaming responses and Details views update more smoothly. You can move from "the tool failed" to the exact call and payload without reconstructing the run from chat bubbles. 1.6.10 The conversation itself is easier to drive: press Up or Down to recall and edit earlier requests without losing your unsent draft, or choose Clear Chat to reset the conversation plus Events and Details state. Pending MCP approvals and OAuth consent requests stay pinned above the input, with bulk actions and expandable details, until every decision is resolved. 1.6.7 1.6.9 ๐ฏ Models and resources โ faster to open, steadier when you return Resource pages should remember your work, not reset it. Models and Tools now load the selected tab first and show core rows before fetching the extra details. When you return to Agents, Models, Tools, Knowledge, or Evaluations, the toolkit preserves rows, search, filters, and pagination while refreshing the active view in the background. A manual refresh still gets the latest service state when you ask for it. 1.6.7 The sidebar does less work too. Collapsed My Resources sections load only when you open them, while Search and Recent Agents remain available. Evaluations, Routines, Tools, Skills, and Toolboxes now share consistent loading feedback, and a direct link to Tools or Skills opens the requested tab without loading Toolboxes first. The result isn't a new destination โ it's less waiting on the way there. 1.6.7 1.6.8 Model deployment guidance got one sharp fix as well: quota errors now open the token quota page for your current Foundry project, so the recovery path lands on the project that actually needs capacity. 1.6.10 ๐ป Activity protocol agents โ debugging that matches the agent Activity Protocol agents target Microsoft 365 channels, so local debugging should speak the same language. Newly scaffolded Python projects now open Microsoft 365 Agents Playground inside VS Code for local debugging. You stay in the editor and test the activity-shaped conversation before deployment instead of forcing it through an incompatible playground. 1.6.7 Copilot-assisted creation also follows the current Hosted Agent path: current Foundry project and model setup, a managed Python environment, workspace-root debugging, and the latest local run and deployment flow. When you reuse the selected Foundry project, Copilot no longer asks you to choose its Azure location again. 1.6.10 ๐ชฒ Fixes and polish Agent Inspector โ streamed response and reasoning text stays complete; response text, reasoning, tool calls, and permission decisions keep their original order; replacement turns reject obsolete stream events; and unmatched tool calls or results no longer appear in Details. 1.6.9 1.6.10 Approvals and consent โ human-in-the-loop pauses no longer duplicate tool or approval cards, Clear Chat remains available while a turn waits, and continuation responses retain pending approvals until every request is resolved. 1.6.8 1.6.9 Activity Protocol deployment โ Azure Bot settings are validated before submission, compatible Bots are reused, identity and application ID conflicts get recovery guidance, and successful deployments no longer open an unsupported Agent Playground. 1.6.7 1.6.8 Agent Builder and MCP OAuth โ reopening a Foundry Prompt Agent preserves its selected version and tool configuration, while authorization callbacks complete only the matching connection request. 1.6.8 Accessibility โ screen readers announce Model Catalog actions, collapsible Agent Builder and Model Preference controls, and project and model fields with their labels and state; prompt placeholders also meet minimum contrast requirements. 1.6.10 โ ๏ธ Breaking change and migration GitHub Models has been removed from the Model Catalog, playground, model comparison, Agent Builder, and evaluations following the service's retirement. If a saved workflow or evaluation references GitHub Models, open it and select another available model before running it again. 1.6.7 ๐ Get it and tell us what to build next August connected the whole agent loop: choose the right starting point, reuse governed tools, compose agents through A2A, isolate real users, and inspect the run down to timing, tokens, arguments, and results. Install or update from the Visual Studio Code Marketplace. Read the docs โ Foundry Toolkit for Visual Studio Code and the Microsoft Foundry documentation. Explore samples in the Microsoft Foundry samples repository. Browse the full changelog in WHATS_NEW.md. File issues and feature requests at github.com/microsoft/foundry-toolkit/issues. Join the Microsoft Foundry community on Discord. Try a toolbox with your next Prompt Agent, open the run in Agent Inspector, and tell us where the workflow still slows you down. Happy building. ๐Zonal redundancy in API management Standard v2
APIs are the backbone of modern applications, powering everything from mobile experiences and microservices to AI-driven applications and business-critical integrations. As customers continue to modernize their platforms on Azure, they increasingly expect their API infrastructure to remain available even in the face of datacenter-level disruptions. With zone redundancy in Standard v2, Azure API Management now enables customers to increase resilience against Availability Zone failures while continuing to benefit from the simplicity, performance, and cost efficiency of the v2 platform. Why Zone Redundancy Matters Azure Availability Zones are physically separate locations within an Azure region, each with independent power, cooling, and networking infrastructure. By distributing API Management resources across multiple zones, organizations can reduce the impact of a single datacenter failure and improve service continuity for their APIs. Until now, customers who required built-in zone-level resiliency often needed to evaluate higher-end deployment options. With this enhancement, Standard v2 customers can now deploy API gateways across Availability Zones and benefit from improved reliability while maintaining the streamlined operational model of the v2 platform. Whatโs New Zone Redundancy for Standard v2 extends the platform's resiliency by distributing service capacity across multiple Availability Zones within a supported Azure region. Key benefits include: Higher Availability: API traffic continues to flow even if a single Availability Zone experiences an outage. Built-in Resiliency: Redundancy is provided at the platform layer, reducing the need for customers to design and manage complex intra-region failover solutions. Production-Ready Reliability: Customers can confidently run critical API workloads on Standard v2 with stronger availability guarantees. Operational Simplicity: The service automatically manages capacity distribution, health monitoring, and recovery behavior across zones. Cost-Effective Resilience: Customers gain zone-level protection without requiring an enterprise-tier deployment model. Built on the Modern v2 Platform The v2 platform was designed from the ground up to provide a faster, more reliable, and more scalable API Management experience. Standard v2 already delivers capabilities such as rapid deployment, simplified networking, workspace support, and flexible scaling. Zone Redundancy further strengthens the platform by expanding its reliability story for production workloads. This announcement builds on our broader investment in making Azure API Management more accessible to a wider range of organizations, from digital-native startups to large enterprises modernizing their application estates. Ideal Scenarios Zone Redundancy in Standard v2 is particularly valuable for customers who: Run business-critical APIs that must remain available during datacenter incidents. Consolidate multiple application workloads behind a single API gateway. Expose APIs consumed by mobile, partner, and customer-facing applications. Support AI applications and agent-based architectures that depend on highly available API endpoints. For organizations adopting modern cloud and AI native architectures, this capability helps ensure that API infrastructure remains aligned with broader application resiliency strategies. A Foundation for Reliable AI and API Platforms As AI-powered applications continue to proliferate, APIs increasingly become the critical connection layer between models, agents, business systems, and data platforms. Downtime at the API layer can have a direct impact on application availability, customer experience, and business operations. By bringing zone redundancy to Standard v2, we are making it easier for organizations to build highly resilient API platforms that can serve as the foundation for next-generation AI and digital transformation initiatives. Getting Started Zone Redundancy for Standard v2 can be enabled in supported Azure regions, allowing customers to deploy API Management with built-in protection against Availability Zone failures. We recommend reviewing your application's overall resiliency architecture, including backend redundancy, traffic management, and disaster recovery requirements, to maximize the benefits of zone-resilient API infrastructure. Enable Zone Redundancy in the Azure Portal Getting started with Zone Redundancy in Azure API Management Standard v2 is straightforward and can be configured during service creation. Create a New Standard v2 Instance with Zone Redundancy Sign in to the Azure portal. Select Create a Resource and search for Azure API Management. Choose Standard v2 as the service tier. Select a region that supports Availability Zones. In the Availability Zones section, enable Zone Redundancy. Review and create the service. After deployment, Azure API Management automatically distributes service capacity across multiple Availability Zones within the selected region, helping maintain API availability during a zone-level outage. Looking Ahead This release represents another step in our ongoing investment in the Azure API Management v2 platform. We remain committed to delivering the reliability, scalability, security, and developer experiences that organizations expect from a modern API management service. We are excited to see what our customers build with a more resilient Standard v2 platform and look forward to your feedback as you continue modernizing and scaling your API ecosystems on Azure. Learn more by visiting the Azure API Management documentation and exploring the latest reliability guidance for API Management deployments.AI Skills Navigator is now available in Microsoft Copilot
Start with a question for the Learning Agent in Copilot and get recommendations from AI Skills Navigator, helping you find the right next step whenever you need to learn something new. Matt Erni is Product Manager at Microsoft working across Learning Agent and AI Skills Navigator to bring relevant skilling into the flow of work. Learning new AI skills has never been more important for individuals and organizations alike. But when you need to learn something new, finding the right next step isnโt always straightforward. Letโs say youโre preparing a presentation, building your first agent, securing an AI workload, or even planning your next career step. Youโre right in the middle of a task and realize thereโs a skill you need to learn to do it well. The challenge isn't just finding training. It's finding resources you can trust that are tailored to your role, goals, experience level, and preferred way to learn. Thatโs why we recently introduced Learning Agent in Microsoft Copilot, a personalized AI upskilling experience that helps you build Copilot and AI skills in the flow of work. Learning Agent uses role information, work context, skills signals, and organizational learning sources to bring personalized recommendations directly into Copilot, helping you discover relevant learning opportunities and build skills when and where you need them most. Today, we're extending that experience through a new integration with AI Skills Navigator, our agentic skilling platform. Learning Agent can now also recommend training, skilling experiences, and credentials from AI Skills Navigator directly within Copilot, making it easier to move from a question to the next step in building a skill. Videoclip: Overview of Learning Agent in Microsoft Copilot. If the player doesnโt load, open the video in a new window. Turn work questions into learning opportunities Whether you're trying to solve a problem, build a new skill, or explore your next learning goal, you can start by asking a question in Copilot using natural language. Here are some examples: How can I use Copilot in new ways? What should I learn before building my first agent? Which videos can help me learn about Copilot Cowork? What courses can help me learn how to secure my AI agent? Which Microsoft credential can help me lead AI adoption in my organization? Learning Agent uses your question along with context from you and your organization to surface personalized skilling recommendations and guidance. With the AI Skills Navigator integration, those recommendations can now also include training modules, learning paths, skilling sessions, videos, and Microsoft Credentials. So, no matter what you're trying to accomplish, Learning Agent is there to guide you to the right next step. The recommendations from AI Skills Navigator are clearly labeled, so you can understand the source and choose the next step that works for you. Getting started is simple: open Learning Agent in Microsoft Copilot and ask a question about a skill, topic, or credential you'd like to learn more about. Keep learning without losing your place When Learning Agent recommends a module, learning path, or curated video from AI Skills Navigator, you keep the context that brought you there. You can open the recommendation alongside your Copilot conversation, explore the content, and use features such as AI-generated summaries and podcasts as you go. Progress is automatically saved in AI Skills Navigator, making it easy to pick up where you left off and continue learning over time. There's no separate sign-in required. The full AI Skills Navigator catalog gives you access to interactive learning experiences like skilling sessions or opportunities to earn Microsoft Credentials. The first time you access these experiences, you'll create an AI Skills Navigator profile, unlocking additional personalized learning, progress tracking, and recommendations in the full experience. Whether you start with a quick recommendation or continue into a skilling session or credential, you can keep learning without losing momentum. Learning for individualsโand entire organizations Learning Agent and AI Skills Navigator are designed to support you in skilling at any level while also helping your organization scale learning more effectively. Learning Agent can surface recommendations from organizational knowledge sources, including SharePoint, LinkedIn Learning, learning management systems, third-party content, role-play providers, and now AI Skills Navigator. This helps employees spend less time searching for learning resources and more time building skills. So, whether youโre building AI fluency, preparing for a new role, earning a credential, or developing technical expertise, Learning Agent and AI Skills Navigator help connect everyday questions with the learning opportunities that matter most. At the organizational level, this creates a stronger connection between employee learning, company knowledge, and the skills needed to support business priorities. Availability: Learning Agent is available to organizations and their employees with Microsoft Copilot. Access to connected learning experiences, including some third-party sources, depends on how an organization has configured and licensed those sources. Check with your organization if you're not sure whatโs available to you. Keep building skills over time Learning Agent helps you get started on the right track. AI Skills Navigator helps you go deeper, track progress, and keep building skills over time. Together, they help individuals and organizations connect learning to real work and skilling goals. Get started now. Add Learning Agent to Microsoft Copilot and start asking questions about the skills, topics, and credentials youโd like to learn more about. New to AI Skills Navigator? Read The moment AI skilling stopped being optionalโand started being personal.2.1KViews2likes0CommentsThe AI Trust Gap: We're Auditing Outputs, But Nobody's Watching the Input
Hi all, Manjish here, founder of Pryvasee.AI. I want to open a conversation rather than make a pitch, because I think this is a problem bigger than any one company can solve, and I'd like to hear how others in this community are approaching it. Over the past year, watching enterprises adopt LLMs like ChatGPT, Claude, Gemini, Grok, DeepSeek, etc one pattern kept showing up. Almost every governance conversation started after the prompt was sent. Teams were building dashboards to review AI outputs, running periodic audits, writing acceptable use policies. All useful, but all reactive. Nobody I spoke to had a clear answer to a much simpler question: what actually happens to the sensitive data in that prompt in the moments before it leaves your organisation's control? That gap is why we built Pryvasee.AI differently. Instead of sitting after the model and reviewing what came back, we sit before it. Pryvasee Guard screens prompts, documents, and images for PII, PHI, and PCI and other such sensitive data before anything reaches a model. Pryvasee Thread lets you run the same request across OpenAI, Gemini, Grok, and DeepSeek from one interface, so you're never trusting a single model's answer by default. And the Trust Engine scores every response that comes back for groundedness and hallucination risk, so there's a number behind "does this look right" instead of a gut feeling. We built it natively on Azure (AKS, Azure SQL, Azure SQL Ledger for a tamper evident audit trail) because we think the next wave of AI governance problems won't just be about data leakage. They will be about proving, after the fact, exactly what happened, for a regulator, an auditor, or your own board. Most organisations can't do that today for a single AI interaction, let alone thousands a day across four different model providers. We're early. MVP/Beta since July 2026, live on the Microsoft Commercial Marketplace since late August, and currently working through a handful of enterprise pilots rather than claiming a long customer list. I would rather be upfront about that than oversell it. What I'm genuinely curious about: for those of you building or advising on enterprise AI adoption, is anyone handling the "before the model" problem today, whether with tooling, policy, or something else? And do you think this becomes a bigger issue as more employees start using multiple AI tools side by side, or does it resolve itself as the big model providers add more guardrails natively? Would love to hear how others are thinking about this.