Turn GitHub notifications into code with GitHub Copilot in Microsoft Teams
GitHub can now bring repository updates into a channel, group chat, or private chat. When an update needs action, reply to the notification and @mention GitHub with the task you want GitHub Copilot to carry out. GitHub Copilot uses the issue or pull request linked in the notification and the conversation in the thread to understand the task. It can reproduce a bug, run tests, implement a fix, and prepare a pull request for review. Turn an issue notification into a pull request If the player doesn’t load, open the video in a new window: Open video For a bug report, the workflow starts in the notification thread: A GitHub Issue notification arrives in a Teams channel with a link to the reported bug. You @mention GitHub to investigate the issue and prepare a proposed fix in a pull request. The team reviews the pull request, iterates with GitHub Copilot, tests the proposed changes, and decides whether to merge. Starting from the linked issue and thread lets your team delegate the work to GitHub Copilot without rebuilding the request from scratch. The same workflow can be used to implement a feature, expand test coverage, update documentation, and more. Product and engineering teams at Microsoft are already leveraging the GitHub app in Teams to build products today. Get started Explore the new GitHub app in Microsoft Teams (previously called GitHub Notifications). If you already have GitHub Notifications installed, update the app to the latest version. The legacy GitHub app will be renamed “GitHub (deprecated)” and retired on November 16. Learn more at teams.github.com! Turn the updates your team follows into code your team can review.Copilot, 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 29th of October 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 Ranjith D – Build Power Automate Flows and Power Apps from Copilot Studio - Just by Asking Marc André Schröder-Zhou – Designing Adaptive Cards with AI support in SharePoint David Warner - Using Copilot Notebooks - Instant Agentic Experiences & More 📅 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!Copilot, 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 Copilot, Microsoft 365 and Power Platform. 📅 On the 27th of October we'll have following agenda: News and updates from Microsoft Together mode group photo Joe Komban - Copilot in SharePoint: Using Custom Plugins for Enterprise AI Rabia Williams - Introduction on Copilot prompt sample gallery Paolo Pialorsi - Understanding Copilot Cowork extensibility 📞 & 📺 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!🆕Orchestrate Foundry Prompt and Hosted Agents with Logic Apps Automation
Microsoft Foundry is retiring workflows on December 1, 2026. After that date, the visual workflow designer and running workflows in the Foundry portal won’t be supported. For business process automation that combines deterministic steps with AI reasoning, the Foundry migration guide recommends Azure Logic Apps. Logic Apps is especially well suited to building these processes visually: Foundry agents become steps in a workflow, running alongside built-in actions, APIs, and MCP servers in the same run. Beyond the migration, there’s a broader question many teams face once an agent is working. Most agents start out as interactive, chat-based experiences: a person asks, and the agent responds. Putting that same agent to work in a business process means it has to run autonomously, started by an API call or an event instead of a person, running in the background and at scale. It also has to fit alongside the deterministic steps the process already depends on, such as gathering data before the agent runs and validating and acting on its output afterward. With support for Foundry Prompt Agents and Foundry Hosted Agents, Azure Logic Apps Automation gives you a direct way to do this. Any agent you’ve built in Foundry can become a step in a workflow. It can be started by an API call, a schedule, or an event from one of 1,400+ connectors, run in the background at scale, and sit between the deterministic steps that come before and after it. Before we get to the workflow side, here’s a quick look at the two agent types. If you want the full picture, the Foundry Agent Service overview compares them in detail. What are Foundry Prompt Agents A Prompt Agent is an agent you configure rather than code. You write instructions, pick a model, attach tools, and Foundry runs it. There’s nothing to deploy and no scaling to think about. It can use the Foundry model and tool catalogs, including knowledge sources like Azure AI Search and Foundry IQ. You pay for the tokens and tool calls it uses, with no separate platform charge. If you can write down what the agent should do and which tools it needs, a Prompt Agent will usually do the job, and it’s the quickest way to get something working. The prompt agent quickstart walks through building one. What are Foundry Hosted Agents A Hosted Agent is your own agent code, packaged as a container and run on Microsoft Foundry Agent Service. You can build it with Microsoft Agent Framework, LangGraph, the OpenAI Agents SDK, or your own code. Foundry handles the hosting and scaling. Since it’s your code, you decide how the agent loop works. Each session gets its own isolated sandbox with the CPU and memory you choose, and files and state persist between turns. Each Hosted Agent also gets its own Microsoft Entra agent identity, so you can see and audit what it does like any other identity in your tenant. Hosted Agents use the same models and tools as Prompt Agents. On top of tokens and tool calls, you pay for the compute they use (vCPU and memory hours). You can read more about how Hosted Agents work. A simple way to choose: start with a Prompt Agent. Move to a Hosted Agent when you need custom code or custom orchestration or want to bring your own code and framework. Orchestrate Foundry agents with Logic Apps workflows An agent in Foundry runs when someone or something calls it. Most business processes start somewhere else: an email comes in, a ticket is opened, a file lands in SharePoint, or a schedule fires. They usually end somewhere else too, with a record updated or someone getting a message. Logic Apps covers both ends and everything in between: a trigger to start the agent, deterministic steps around it, and branching, retries, timeouts, and parallel branches for the agent call. The next two sections show what that looks like. Every run shows up in run history, with the inputs, what the agent returned, and what happened next. When something goes wrong, you can see exactly where. The Learn article on automating Foundry agents with workflows covers the setup step by step. Run agents autonomously from any trigger The simplest setup is a trigger, an agent, and an action. Say a support email arrives in Outlook. The workflow sends it to a Prompt Agent that classifies it and drafts a reply, then creates a ticket with the result. This runs every time an email arrives, with no one starting it. Schedules work the same way. A recurrence trigger could call a Hosted Agent every Monday to go through last week’s data and post a summary in Teams. Mix agentic reasoning with deterministic steps Most processes are largely rule-based, with a step or two that needs adaptive reasoning or a decision. In Logic Apps you use an agent for those steps and keep everything else as deterministic steps. Before the agent runs, collect what it needs. Look up the customer in your CRM, pull the contract from SharePoint, or query a database, and pass all of it in. After it runs, check what came back. Validate it against a schema, apply your business rules, and send anything uncertain to a person for approval. Then write the result to the right system with a connector. Use both agent types in one workflow You don’t have to pick one type of agent per process. A workflow can call a Prompt Agent for a quick classification and send only the harder cases to a Hosted Agent for a longer analysis. The workflow passes output from one agent to the next, runs agents in parallel when they don’t depend on each other, and brings the results back together. Each agent stays small, and the end-to-end logic lives in the workflow, where you can see it and change it. How to use Foundry Agents from Workflows Hosted Agent You can create Foundry Hosted Agents directly from your Logic Apps Automation application. Pick your Foundry project and model deployment, and the app takes care of identity, permissions, and readiness checks for you. In a workflow, the Foundry Hosted agent action sends the agent its instructions, task, files, and any workflow actions you’ve added as tools. It returns the agent’s final response and generated files for the next steps to use. For details, see Foundry Hosted Agents for an overview and Create and use a Foundry Hosted Agent for step-by-step setup. https://youtu.be/foN9oPu5lRE Prompt Agent You can call an existing Foundry Prompt Agent from a workflow or create a new one right from the designer . Connect to your Foundry project, then either pick an agent from the list or select Create new agent and give it a name, a model, and instructions. The agent is created and hosted in Foundry. You can also give the agent tools from Logic Apps: actions from 1,400+ connectors, built-in actions, APIs, MCP servers, and other workflows. https://youtu.be/YkM7dHzHjdM Roadmap Today, workflows can invoke Hosted Agents that you create from your Logic Apps Automation app. We’re adding support for selecting an existing Hosted Agent from your Foundry project and invoking it from a workflow. Get Started Read to automate! Start building at auto.azure.com Automation QuickStart Automation Documentation - https://auto.azure.com/docs/
Web IQ: Web Search and Grounding APIs for AI Agents
Web IQ gives AI agents current, citable evidence from across the web. We explain what it is, how its four layers (Bing's web substrate, Harrier embeddings, DiskANN, and structured evidence) work together, and how it pairs with Microsoft IQ to ground agents in web and enterprise context.When Intent Becomes the Interface: Why Applications Are No Longer the Starting Point
For decades, enterprise software has asked people to learn how applications work. Which screen to open. Which fields to complete. Which workflow to trigger. Which report to generate. And which application to visit next. Here is a situation I keep meeting. A sales executive is preparing a renewal proposal. Customer relationships live in CRM. Contract terms sit in SharePoint. Support issues are tracked elsewhere. Revenue data comes from finance. Relevant conversations are scattered across Outlook and Teams. The executive knows what needs to be accomplished. The software requires them to figure out how. But something interesting is happening. We are beginning to separate the intent to accomplish work from the applications traditionally required to perform it. Microsoft's developments across Copilot, Cowork, Code, Copilot Studio and Microsoft IQ suggest that this could become a defining shift in enterprise software. The question is no longer simply how to make applications more intelligent. What if enterprise software started with the work, rather than the application? Enterprise Software Was Built Around Navigation Traditional enterprise applications organize business capabilities into reliable systems. ERP manages transactions. CRM manages customer relationships. HR platforms manage employee processes. These systems aren't going away. Their data models, transaction controls and business rules remain essential. But their user experiences were designed for a world where software needed explicit instructions at almost every step. People became the integration layer. We retrieved information from one system, interpreted it, entered it into another, initiated approvals and followed up when something stalled. APIs and automation improved individual steps. Generative AI introduced conversational interfaces. But the underlying model often remained unchanged. People still needed to know which application to use and how to move the result into the next step. Now the architecture itself is beginning to change. Microsoft Is Bringing Three Capabilities Together One of Microsoft's more consequential recent developments is the convergence of applications, workflows and agents in Copilot Studio. These are fundamentally different capabilities. Applications provide structured experiences for people to view information, make decisions and act. Workflows provide predictable execution for repeatable processes, business rules and integrations. Agents bring reasoning and adaptation when the next step cannot always be predetermined. Not every business process needs an agent. Not every decision should be probabilistic. And not every interaction belongs in a chat window. A purchase approval may require deterministic policy enforcement. Evaluating an unusual supplier proposal may benefit from AI reasoning. A material exception may require human judgment through a purpose-built application. Microsoft Copilot Studio is bringing these capabilities into a more unified development experience, supported by agent orchestration, workflow execution, reusable skills and connected tools. And the audience for this convergence is already enormous: Microsoft noted on a recent earnings call that more than 80% of the Fortune 500 already have active agents built with its low-code tools. This suggests a useful architectural principle: Use reasoning where the path is uncertain. Use workflows where the rules are known. Use applications where human interaction adds value. I have started calling this the Composition Rule. The breakthrough isn't replacing one with another. It is combining them deliberately. From Application-Led to Intent-Led Work Return to our sales executive preparing a renewal proposal. Instead of visiting multiple systems, the executive could begin with a request: Prepare the renewal proposal. Incorporate the latest commercial terms, outstanding support issues and account commitments. Flag anything requiring approval. The system must interpret the request, retrieve authoritative information, apply business rules, assemble the deliverable and recognize where human judgment is necessary. Different Microsoft capabilities can contribute to that experience. Microsoft 365 Copilot Cowork enables delegation of complex, multi-step work across connected productivity experiences. Work IQ provides context from Microsoft 365 collaboration. Fabric IQ contributes business semantics and relationships across enterprise data. Foundry IQ supports reusable enterprise knowledge and retrieval. Together, they form the context layer I explored in The Context Advantage and intent-led work is where that investment begins to pay out. Dynamics 365 and Power Platform connect intelligence to operational records, business processes and actions. Copilot Studio enables agents to use tools and workflows, while applications can provide structured experiences for human review. These are complementary building blocks, not necessarily one automatically integrated execution path. Bringing them together requires deliberate solution architecture, connectors, permissions and orchestration. The executive receives a proposal, supporting evidence and decisions requiring attention. The underlying systems remain important. But navigating them is no longer necessarily the executive's responsibility. In traditional enterprise architecture, applications organize capabilities and users navigate between them. In an intent-led architecture, the desired outcome becomes the organizing principle. Applications, workflows, agents and enterprise services are composed around that intent. The application remains important. But it is no longer necessarily the primary unit of the user experience. When Software Can Be Assembled Another development deserves attention. Microsoft's Copilot Code and Copilot Studio capabilities are making it easier to create software experiences from natural-language requirements. Copilot Managed Runtime provides Microsoft-hosted infrastructure for running and governing supported applications. These capabilities are at different stages of availability, but their direction is significant. Traditionally, an enterprise application begins with a development project: requirements, design, engineering, testing, deployment and maintenance. That remains essential for complex, mission-critical systems. But not every business need justifies a conventional development cycle. A procurement manager may need a focused interface for comparing supplier proposals. A finance team may need a temporary application for reviewing reconciliation exceptions. Increasingly, some experiences can be generated, connected to governed data and shared with colleagues. The distance between recognizing a business need and creating a useful software experience may shrink dramatically. But faster creation also raises important questions. Who owns the generated application? How is it tested? Which identities and permissions does it use? How is it maintained or retired? Microsoft Copilot Managed Runtime, currently in preview, addresses part of this challenge through managed hosting, Microsoft Entra authentication and application governance capabilities. The ability to generate software is becoming easier. The ability to operate that software responsibly remains an engineering discipline. Software creation may become democratized. Software accountability cannot become optional. Reasoning Is Not Execution There is one distinction I find myself drawing on whiteboards more often than any other as AI moves deeper into enterprise processes. Large language models are useful when tasks require interpretation, synthesis and adaptation. But enterprises also depend on predictability. An invoice approval threshold shouldn't change because a model reasons differently. A financial transaction must preserve the integrity of the system recording it. Consider an insurance claim. An agent interprets submitted documentation and identifies missing information. A workflow applies established eligibility rules and routes the claim. A human reviewer examines complex exceptions through an application presenting the relevant evidence. The model contributes interpretation. The workflow contributes repeatability. The application supports human judgment. And the system of record preserves the authoritative transaction. This requires business capabilities to be accessible beyond application screens. APIs, Model Context Protocol (MCP) tools, Power Platform connectors and reusable services become building blocks through which intelligent workflows can operate across systems. Microsoft Copilot Studio supports this direction through workflow triggers, agent handoffs, connected tools and evaluation capabilities. Microsoft Foundry provides complementary capabilities for agent development, evaluation, tracing and operational monitoring. The quality of the experience increasingly depends on how well these capabilities can be composed - not simply on how intelligent the underlying model is. For enterprise architects, this introduces a more useful question than where to deploy another agent: Which parts of this process should be intelligent, which must be deterministic and which require human judgment? That is the Composition Rule at work. A New Architecture, Not Another Generation of Sprawl The counterargument comes up in almost every architecture conversation I am part of. If every employee can generate applications and every department can assemble workflows, enterprises could recreate decades of software fragmentation at unprecedented speed. A hundred individually useful applications don't necessarily create a coherent enterprise architecture. The answer isn't to prevent experimentation. It is to establish reusable foundations. Common identity through Microsoft Entra. Trusted business semantics through Fabric IQ. Approved connectors and MCP tools. Shared engineering standards. Managed execution environments. Clear ownership and lifecycle controls. Microsoft Agent 365 adds an enterprise control plane for discovering, securing and governing agents across supported environments. These capabilities address different parts of the challenge. They do not eliminate the need for enterprise architecture. The more accessible software creation becomes, the more important shared foundations become. Otherwise, we risk making software easier to build while making the enterprise harder to operate. When the Business Need Comes First I don't expect enterprise applications to disappear. Organizations will continue to need ERP, CRM, finance, HR and industry-specific platforms. Systems of record remain indispensable. But the relationship between people and applications is beginning to evolve. Today, enterprise users learn which application performs which function. Tomorrow, more experiences may begin with a desired result, with intelligence coordinating underlying capabilities and presenting the appropriate interface when needed. Sometimes that interface will be a conversation. Sometimes a generated application. Sometimes a familiar enterprise screen. And sometimes a workflow will complete a defined step without another interaction. Microsoft's convergence of Copilot, Copilot Studio, Microsoft IQ, Power Platform and managed execution infrastructure makes this architectural possibility increasingly tangible. We may be moving from a world where people navigate software to accomplish work toward one where software is assembled around the work people need to accomplish. That won't happen overnight. It requires strong architecture, trusted data, explicit execution boundaries and deliberate engineering choices. But it raises a question worth asking before the next enterprise software investment: Are we designing another application people must learn to operate or a capability that understands the work they are trying to accomplish? References Microsoft Copilot Studio Blog: “Build apps, workflows, and agents together” The Official Microsoft Blog: “Introducing the new Copilot with Home, Code and Autopilot” (September 25, 2026) Microsoft Copilot Studio Blog: “Microsoft Copilot Managed Runtime: Enterprise code execution for Microsoft 365” Microsoft 365 Blog: “Powering Frontier Transformation with Copilot and agents” (Copilot Cowork) Microsoft IQ Microsoft Agent 365 Microsoft FY26 Q2 earnings conference call — more than 80% of the Fortune 500 with active agents built using Microsoft's low-code tools Ashok Karania Articles on Microsoft Tech Community — “The Context Advantage”; “When AI Stops Waiting for Instructions”; “Beyond Tokens: Rethinking AI Economics with Microsoft Foundry” Image Credit: OpenAI
