More powerful agents and workflows for autonomous business processes: Introducing a new harness for Copilot Studio
Over the past two months, we’ve been previewing a new capability within Copilot Studio that lets you build agents capable of taking on more complex business processes. Today, we’re excited to share that this capability is now generally available for production use and to introduce its new name: the GitHub Copilot harness in Copilot Studio. Meet the GitHub Copilot harness The GitHub Copilot harness gives Copilot Studio the coding and reasoning capabilities behind our most advanced agent experiences (like Copilot Cowork and the GitHub Copilot coding agent). This means your agents can now handle work that used to be out of reach, including processes that have many steps, many sources, and ambiguous decision points. The new harness is built for complex, long-horizon work using the latest frontier reasoning models like Opus 5, GPT-5.6 Sol, and Fable 5. It can plan, reason through dynamic problems, run an agentic loop, use skills, integrate workflows, connect to tools and agents in other platforms, and produce rich, multi-part outputs. In our own testing with real world business process evals, Copilot Studio shows significant performance and quality gains when using the GitHub Copilot harness. Improvements in multi-tool use, file analysis, code analysis, and knowledge quality mean these agents are more capable of taking on your most complex business processes. To help you build these more capable agents, we’re also delivering new experiences for makers building agents with the GitHub Copilot harness. The agent designer is more intuitive for authoring, putting the most important tools right within reach to make authoring faster, while retaining full agent lifecycle management features. Then, the workflow designer gives a visual canvas to understand and edit workflows, including adding agent nodes and running workflow evals. And soon, natural language authoring will let you describe your business goal and assemble the right combination of agents and workflows through a multi-turn conversation. Agents running on the GitHub Copilot harness use usage-based billing for all work, regardless of Microsoft 365 Copilot licensing. You pay for your agent’s usage based on the models you choose, the organizational context and tools you add, and runtime used. Certain AI-driven maker experiences, like natural language authoring, evaluations, and testing, will also fall under usage-based billing if building with the GitHub Copilot harness. You can learn more about Copilot Studio usage-based billing here. Continued Support for Copilot Chat and Standard harnesses Adding a new harness does not change the ones you already rely on. Different harnesses can be optimized for different outcomes, so rather than relying on a single one-size-fits-all approach, Copilot Studio now lets you choose the harness that best fits your scenario. This means Copilot Studio supports three harnesses today: The Copilot Chat harness, which uses the same harness as Microsoft 365 Copilot Chat and is ideal for customizing Copilot Chat experiences. The Standard harness, which most agents built in Copilot Studio use today and is great for conversational agents with rules-based topics. The new GitHub Copilot harness, which uses the power of GitHub Copilot SDK to automate complex, agentic business processes. We will continue to support the Copilot Chat and Standard harnesses in Copilot Studio for both existing agents and authoring of new agents. Microsoft 365 Copilot licensed users continue to benefit from fair use of Copilot Chat or Standard harness agents included in their Microsoft 365 Copilot license. For all other usage, the Copilot Chat and Standard harnesses will continue to be billed using the existing fixed rate card. Get started today The GitHub Copilot harness is generally available now, and you can start creating these agents directly from the Copilot Studio homepage. We can’t wait to see what you build. Share your thoughts using the feedback control in the top right corner of the product. Your input directly shapes what we build—and how you build—next. Try Copilot Studio today!Looking for ideas: Reducing "Allow" prompts when using SharePoint Knowledge
Hello community members! I'm hoping to get some advice from people who may have come across a similar challenge with their Copilot Studio "SharePoint knowledge retrieval" agents 🤞 Current setup Agent set up in Copilot Studio and published to channels - M365 Copilot and Teams Agent is connected to 4 SharePoint folders (I'm using Method#1 - see below screenshot for reference). This is essential because the documents inside the folders contain both text and image-based content. This is the only method that brings results Users have permissions to access the content in these folders Problem We are currently preparing to roll out this agent but we've hit a user experience issue that is becoming a blocker for moving forward. When a user interacts with the agent for the first time, they are asked to click "Allow" ... 4 times .. one for each of the folder that the agent is connected to This experience feels heavy for users (based on our pilot feedback) and people give up after the first or second time because they think it is not working. In spite of comms and a video about having to repeat this action until done. We want the first time experience to be as smooth as possible to drive adoption. Also, we are going to expand the solution to include more folders soon - so there is also a concern that number of consent prompts could grow further. What I've tried Used Method#2 to connect to SharePoint folders. While this didn't pop up the "Allow" prompts, as indicated earlier, this approach doesn't work because it doesn't return any results from documents as they contain both text and image content. Tried Method#1 to connect to the library (and use instructions to indicate necessary folders) - this didn't work because the method doesn't allow to connect to libraries. Note - I cannot restructure the library and put all the documents into one folder because that's the way the documents have been maintained for a long time & direct links to the folders are being used across the organization via. emails, decks etc. Looking for advice Has anyone found a way to reduce or eliminate these consent prompts? Are there any other recommendations on using SharePoint as a knowledge source that respects user permissions without these consent prompts? Does anyone know why Method#1 and Method#2 have different user experiences where the first one prompts for consent and the second doesn't?
All Copilot Studio Workflow Tools Suddenly Returning HTTP 403 Before Execution
Hello Copilot Studio Community, I am experiencing an authorization issue with multiple workflows connected to an agent built using the Copilot Studio new experience and new Workflows experience. These workflows worked successfully for multiple users yesterday. Today, all workflow tools connected to the agent began returning an immediate HTTP 403 authorization error. I did not intentionally change the agent, workflows, environment, or workflow permissions before the issue started. Error message: You don’t have permission to use this tool. You’re signed in, but access to this resource is blocked. Error details: Authorization - 403 Example error information: Status: Failed Error message: Flow returned HTTP 403 Error code: Http403 Inner error code: NotSpecified Tool duration: Approximately 93 milliseconds Configuration: - Copilot Studio new agent experience - Copilot Studio new Workflows experience - Agent and workflows are in the same Power Platform environment - Workflows use the "When an agent calls the workflow" trigger - Each workflow includes a "Respond to the agent" action - Workflows are saved and published - Agent is saved and published Observed behavior: The problem affects several independent workflows, including: - New-request submission - Current-user identity resolution - Approval decisions - Requester justification - Executive decisions - Fulfillment updates For every affected workflow: - The agent fills the workflow inputs correctly. - The tool call fails almost immediately. - No corresponding run appears in the workflow Activity history. - The workflow trigger is never reached. - No workflow actions execute. Because no workflow run is created, the rejection appears to occur before workflow execution, possibly within the Copilot Studio agent-to-workflow authorization or invocation layer. Troubleshooting already completed: - Confirmed that all workflows are published. - Confirmed that the agent is published. - Tested in a completely new conversation. - Removed an affected workflow tool from the agent. - Saved the agent. - Added the same published workflow back to the agent. - Reconfigured and verified the tool inputs. - Republished the agent. - Confirmed that no workflow Activity run is created. - Confirmed that the issue affects multiple workflows rather than one specific workflow. Removing and re-adding the workflow did not resolve the problem. Questions for the community: 1. Is anyone else currently experiencing HTTP 403 errors when Copilot Studio agents invoke workflows? 2. Is this a known issue or regression in the new Workflows experience? 3. Is there an environment-level or tenant-level permission that controls agent-to-workflow invocation? 4. Could a tenant policy, Conditional Access change, service principal, connection reference, or workflow-sharing configuration cause all workflow tools to fail simultaneously? 5. Where can an administrator find detailed authorization logs when the workflow never creates a run? 6. Has anyone found a workaround for this issue? Any guidance or confirmation from others experiencing the same behavior would be appreciated. I can provide screenshots, complete error details, timestamps, and additional configuration information if needed. Thank you.
Saving a Model Generated File in SharePoint - New Copilot Studio
Hi everyone, I have spent the last two days trying to solve a problem that to me should be a straightforward functionality. I have an agent I made which generates Word file reports. The agent is Cluade Opus 4.8 and it generates the file wonderfully as per my brand guidelines. The document in not a simple content file. Rather these documents can get complex based on the user requirement. Currently the document generates fine and the user gets a popup to download the file. I however need the file to be saved in our share SharePoint library. I created a workflow tool that accepts a file input and then saves it to SharePoint, however when I tried to configure this tool in the agent, the file input parameter was not showing. I then tried to set up a workflow which accepts a url, but the agent cannot seem to access any url or pass it to my workflow. Using a create file tool within the agent and having the agent fill in the file name and content parameters was slow, and the agent was actually attempting to rewrite the file byte-by-byte which lead to the file being re-created and is not scalable for large files. Based on the agent, this is how the file is currently saved: "The file is saved inside my sandboxed container at: /app/created/Sample_Report.docx /app/created/ is a special output directory: any file I place there is automatically packaged by the platform and returned to you as the chat attachment (the Sample_Report.docx chip you see). This is a private, ephemeral location inside my container — it is not a shared network path, and it is not the SharePoint library. Neither you nor the SharePoint tool can reach /app/created/ directly; the platform's attachment mechanism is the only bridge out of it, and as we established, that bridge delivers a direct download rather than a hosted HTTPS URL. So to be precise: the file exists only (a) here in my container at /app/created/Sample_Report.docx, and (b) as the downloadable attachment the platform generated from it. It has not been saved to SharePoint." I need this functionality working as I will have several automations flows around report generation so no human will be available to download the file from within Copilot. Note: I cannot use the old copilot studio as the file generation capabilities are not on par with the new copilot studio experience. The same agent model does not output files, and the create word file node does not output files at the depth and formatting complexity I require. Can anyone please help with a reliable way to get the file save in SharePoint from the New Copilot Studio experience? I'm at my wits end here.Fix: Hyperlinks render as plain text in Copilot app (but work in the test pane in Copilot Studio)
My use case SharePoint knowledge-retrieval agent built in Copilot Studio to answer employee questions from internal policy and guidance documents. These documents, in addition to text content, contain embedded hyperlinks to internal apps and resources (intranet pages, expense app, ticketing tools etc.). It was important for these links to be surfaced in the agent response so employees can directly follow the link - so they needed to be clickable hyperlinks, otherwise the answer was effectively incomplete. Note that I am not using specific topics/actions to create generative answers. I'm relying solely on instructions. The problem Hyperlinks from the source documents appeared as clickable links in Copilot Studio test pane, but when the same agent was published and accessed via the M365 Copilot app, the links were displayed as plain text - not clickable. My original instructions told the agent to include hyperlinks in content & I also verified that the hyperlinks in the source documents were all absolute URLs. 🙌 What changes finally worked Keeping the original "include links" directive and adding a strict formatting rule that requires both Markdown formatting and an HTML <a> tag wrapper, with the URL preserved exactly. The final instruction lines I included: If hyperlinks are contained within the source content and related to the answer, ALWAYS include them in the response. ALWAYS format the link as full Markdown and preserve the URLs exactly within an HTML <a> tag. What was the problem Copilot Studio is a forgiving renderer. M365 Copilot app uses a stricter markdown rendered that can supress hyperlinks that don't come be default in the format it expects. Hence, including an explicit hyperlink formatting in the instructions helps. I hope this helps someone and saves a few hours in troubleshooting the issue 😉
Microsoft AI Agent Creator Associate Certificate
Hello everyone, I have a question about the Microsoft AI Agent Creator Associate certification. I’m passionate about artificial intelligence and Microsoft Copilot Studio. I’m currently taking the training course and working toward earning the Microsoft AI Agent Creator Associate certification. My question is: Will earning this certification improve my chances of getting a job at Microsoft? If anyone in this community has earned this certification or has experience with it, I’d really appreciate your feedback. Has it helped you get hired by Microsoft or one of its partners? Thank you in advance for your advice and insights!Securing data and access in the era of AI with Microsoft Entra and Microsoft Purview
As organizations move from experimenting with AI to deploying it at scale, securing sensitive data, access, and AI usage has become mission critical. In this series, Microsoft experts will show how Microsoft Entra and Microsoft Purview help you: Protect sensitive data across networks, apps, and AI interactions Govern access for users, applications, and AI agents Reduce risk while enabling innovation at scale Whether you're shaping your security strategy or implementing controls, you’ll walk away with the guidance you need to secure data and access to AI as one unified strategy. Now on demand! Secure the age of AI: Redefining trust, data and access Data and identity controls for the browser and network Unlock AI agents without sacrificing security Not able to watch here due to organizational policies? Use a personal account or visit each session page for an option to view on LinkedIn.Unlock AI agents without sacrificing security
AI agents are reaching into mailboxes, files, line-of-business apps, and the open web on behalf of your users—and the business wants more of them, faster. To scale agents safely, your security teams need to be able to verify each agent, govern what it can access, and enforce clear boundaries across every interaction. Learn how Microsoft Entra helps you discover shadow AI agents, govern agent permissions, keep BYOD and endpoint-based agents in scope, and apply Conditional Access to AI prompts and responses. Then see how Microsoft Purview provides visibility into agent activity, strengthens runtime data protection, helps detect agentic risk, and supports auditability across local agents developed on GitHub Copilot CLI, Claude Code, OpenAI Codex, and OpenClaw. Walk away with practical ways to unlock AI agents while keeping access and data protection aligned with your enterprise security needs. How do I participate? Select Add to Calendar to save the date, then click the Attend button to save your spot, receive event reminders, and participate in the Q&A. Not able to attend live? This session will be recorded and available on demand shortly after airing. Don't see Attend or Add to Calendar? Sign in to the Tech Community to join the conversation. If you are unable to watch the session here due to your organizational policies, you can also tune in on LinkedIn. This session is part of Securing data and access in the era of AI with Microsoft Entra and Microsoft Purview. View the full agenda for more insights to help you move from experimenting with AI to deploying it at scale, securing sensitive data, access, and AI usage.
Copilot Studio agent works in M365 Copilot but silent in Teams personal chat (0 Studio sessions)
We are troubleshooting a Copilot Studio agent that works in Microsoft 365 Copilot and Studio test, but does not receive inbound activities from Microsoft Teams personal chat. Environment - Agent: Caflou Asistent v1.0.8 - Channels: Microsoft 365 Copilot + Microsoft Teams (published / synchronized) - Agent Registry: Available - Entra/bot appId: 7e4a53cc-f51c-4772-ad93-e3f1e8060f35 - Maker-provided tool connection works in Studio (example getTasks HTTP 200) What works 1) Microsoft 365 Copilot agent chat / shareLink → agent replies; Studio sessions with channel "Microsoft 365 Copilot" 2) Copilot Studio test pane → agent responds What fails 1) Teams personal chat (desktop AND web): user message visible in "Caflou Asistent" chat, no agent reply 2) Studio Monitor: Teams channel sessions = 0 for probes (only M365 Copilot sessions in last 7 days) 3) Teams Admin Center → Manage apps: 0 results for name "Caflou" and full appId (other apps searchable); UAM banner present while Registry shows Available Classification - Teams inbound activity not reaching Copilot Studio runtime - Not OAuth / not MCP host / not publish alone (M365 path proves runtime alive) - Secondary: Registry Available ≠ TAC Manage apps listing Questions 1) Why would Teams 1:1 never create a Studio conversation while M365 Copilot does? 2) Is missing TAC Manage apps row expected under Unified App Management when Registry shows Available? 3) Best next diagnostic when Monitor shows 0 Teams sessions after confirmed client send? Constraints: no Copilot Studio paid support plan; looking for field experience / known product issues. No secrets posted.CS agent OK in M365 Copilot; Teams chat silent / no Studio session
We are troubleshooting a Copilot Studio agent that works correctly in Microsoft 365 Copilot and in the Copilot Studio test surface, but does not receive inbound activities from Microsoft Teams personal chat. Environment and evidence: - Agent: Copilot Studio agent (custom business assistant) - Copilot Studio agent ID: 88901b10-… (truncated) - Teams/Entra app ID: 7e4a53cc-… (truncated) - Manifest version: 1.0.8 - Channel configuration: Microsoft 365 Copilot + Microsoft Teams - Publish: Succeeded / Channel state: Synchronized - Agent Registry: Available - Authentication: Integrated / Tool credentials: Maker-provided - MCP/custom connector runtime: working (Studio tool test HTTP 200) - Microsoft 365 Copilot routing: working Failure specific to Teams: - Messages in Teams web and desktop appear delivered in the agent personal chat - Agent never replies - Studio monitor has M365 Copilot sessions, but no Teams session for those timestamps - Teams Admin Center Manage apps returns 0 results by name or exact app ID despite Agent Registry Available - Intentionally not republishing / reconnecting OAuth / rewiring connectors because M365 Copilot path proves the same agent+connection works Classification: FAIL — Teams inbound activity is not reaching the Copilot Studio agent. Questions: 1. Anyone seen agents that work in M365 Copilot but receive no personal-chat activities from Teams? 2. Can Agent Registry show Available while TAC Manage apps has no matching row? 3. Known Unified App Management sync issues for Copilot Studio agents? 4. Separate Teams app catalog deployment/approval required when Teams channel shows Synchronized? 5. Which logs prove whether Teams attempted to route the inbound activity? 6. Known manifest / personal scope / app-centric management / conversation-binding issues with this split? Looking for confirmed production experience or documented workaround. Redacted screenshots available; no tokens/secrets.
