Did AI Bring Microsoft Down?
Question for Microsoft Engineering: Was Agentic AI Involved in the November 12–13, 2026 Microsoft 365 Outage? The recent widespread Microsoft 365 outage appears to have involved server health-check failures, infrastructure configuration issues and cascading service disruptions. I have a question that I believe deserves a clear technical answer from Microsoft's engineering team. Given the increasing deployment of AI-assisted and agentic systems across cloud infrastructure, automated monitoring, configuration management and incident response: Can Microsoft confirm whether any autonomous AI agent initiated, authorised or materially contributed to the configuration changes preceding this incident? Were AI-driven systems involved in the server health-check mechanisms that resulted in multiple servers being taken offline? Did any autonomous AI-driven recovery or remediation processes contribute to the cascading failure or complicate Microsoft's recovery efforts? Does Microsoft maintain sufficiently detailed audit trails to distinguish between human-authorised changes, conventional automation and autonomous AI-initiated actions? I am not suggesting that AI was necessarily responsible. However, given the growing operational autonomy of AI systems, I believe this is a legitimate question that deserves a transparent answer. Can Microsoft Engineering explicitly confirm whether agentic AI was involved at any stage in the incident, including its initiation, escalation or recovery? I would welcome a technically detailed response rather than a general statement that the incident resulted from a configuration error.
Architecting Multi-Agent Systems in Copilot Studio: Orchestration, Delegation, and Handoffs
Executive Summary As enterprise conversational AI matures, organizations quickly run into the "Monolithic Agent Dilemma": a single bot tasked with answering IT questions, navigating HR benefits, generating financial forecasts, and resetting passwords quickly becomes unmanageable. Maintenance turns brittle, topic trigger collisions skyrocket, and system prompts balloon beyond effective context windows. The industry solution is Multi-Agent Architecture—decoupling monolithic agents into specialized, bounded worker agents governed by an intelligent supervisor agent. In this article, we break down how to architect, build, and deploy an enterprise-grade multi-agent ecosystem using Microsoft Copilot Studio, complete with orchestration patterns, state-passing best practices, and graceful human-in-the-loop (HITL) escalations. 1. The Architectural Shift: Monolith vs. Multi-Agent In traditional chatbot design, all logic resides in a single container. In a multi-agent system, agents mimic a real-world enterprise organizational chart with a Front-Door Supervisor Agent, specialized Worker Agents (IT, HR, Finance), and human escalation queues. Why Multi-Agent Wins for Enterprise: Separation of Concerns: HR teams maintain HR topics and knowledge; IT teams maintain infrastructure playbooks without cross-team deployment collisions. Isolated Context Windows: Worker agents only receive instructions and data relevant to their domain, reducing hallucination risks. Granular Security and DLP: IT agents can access privileged admin connectors, while HR agents operate under zero-trust privacy boundaries. Independent Versioning and ALM: Teams deploy updates to their specific agent solution without redeploying the entire company bot. 2. Core Architectural Roles: The Supervisor & Worker Agents The Supervisor Agent (The Front-Door Concierge) Acts as the primary endpoint interacting with end users across Microsoft Teams, web portals, or M365 Copilot. Greeting and persona consistency. Ambiguity clarification and intent routing. Shared state and session tracking. Handoff management and post-execution response synthesis. Worker Agents (Domain Specialists) Focused task-solvers that execute deterministic workflows or specialized generative actions: Identity and Access Agent: Handles Entra ID group requests, MFA resets, and licensing checks. Travel and Expense Agent: Inspects corporate travel policy, checks receipts, and posts expense reports. Knowledge Agent: Connects to specific Graph connectors and Azure AI Search indexes with targeted grounding. 3. Communication & Delegation Patterns Pattern 1: Direct Sub-Agent Invocation (Agent-as-a-Tool) How it Works: The supervisor agent registers worker agents as callable tools or custom actions via OpenAPI or Power Automate. Best Used For: Fast, single-turn tasks where worker agents return structured data to the supervisor. Pattern 2: Bot-to-Bot Protocol / Skills How it Works: The supervisor connects to worker agents registered as Bot Framework Skills using Direct Line or App Registrations. Best Used For: Long-running multi-turn dialogs where the worker temporarily takes over the conversation canvas. Pattern 3: Event-Driven Orchestration via Dataverse How it Works: Tasks are logged to an audit table in Dataverse; background agents pick up requests asynchronously and notify the user via Adaptive Cards. Best Used For: Asynchronous workflows requiring multi-approver sign-off or external job completion. 4. State & Context Passing: Avoiding the "Amnesia Problem" The biggest challenge in multi-agent handoffs is loss of context. If a user reports a specific VPN error code, transferring them to the IT Agent with a blank state causes the bot to ask the user to repeat themselves. Solution: Context Packet Schema When transferring between the Supervisor and Worker Agent, serialize and pass a structured JSON Context Payload: json { "sessionId": "conv-98421-m365", "initiator": { "userId": "user_aad_guid_12345", "upn": "email address removed for privacy reasons", "department": "Engineering", "locale": "en-US" }, "intent": { "domain": "IT_Support", "subCategory": "VPN_Diagnostics", "confidence": 0.94 }, "extractedEntities": { "errorCode": "800", "clientOs": "Windows 11 Enterprise", "initialQuery": "My VPN is failing with error 800, can you help me fix it?" } } Implementing in Copilot Studio: In the Supervisor Agent, capture global variables (such as Global.UserContext and Global.ExtractedProblem). When calling the Worker Action or Skill, map these global variables into the worker's Input Arguments. In the Worker Agent, configure the topic to check incoming arguments: if errorCode is already populated, skip intake questions and begin diagnostics immediately. 5. Designing Graceful Fallbacks & Human-in-the-Loop (HITL) Multi-agent systems require a fault-tolerant escalation pipeline when automated resolution confidence falls below threshold. Best Practices for Human Escalation: Warm Handoffs Only: Never dump a cold transfer. Always attach the transcript, attempted diagnostic steps, and error codes. Microsoft Teams Shared Channels: For internal support, dispatch escalation Adaptive Cards into a private Support Teams channel where engineers can claim the ticket with one click. Omnichannel for Customer Service: Utilize Copilot Studio's native integration with Dynamics 365 Omnichannel to pass live chats with full routing rules. 6. Security, DLP, and Governance Guardrails Data Loss Prevention (DLP) Isolation: Assign worker agents to dedicated Power Platform environments based on their data classification tier. General environments handle read-only FAQ and public knowledge; high-privilege environments handle Active Directory changes and ERP transactions. Prompt Injection Resilience: The Supervisor agent must sanitize freeform inputs before passing them into sub-agent prompts. Audit Trails: Log every agent-to-agent delegation event in Dataverse with execution timestamps, latency, and token consumption metrics. 7. Implementation Checklist Audit Your Current Bot: Identify topics with high trigger overlap and cluster them by business domain. Define the Supervisor Contract: Standardize a JSON schema for user identity, intent, and parameter passing. Build Your First Worker Agent: Start with a high-volume, bounded domain like IT Service Desk or Password Management. Implement Tool Calling: Register the worker agent as a callable action inside your front-door supervisor. Test Edge Cases: Validate that multi-turn dialogs maintain context and unknown intents gracefully route back to human triage. Join the Discussion Have you implemented multi-agent architectures in your tenant? How are you handling state transfer and DLP across specialized bots? Share your thoughts and architectural questions in the comments below!
You don't have access to talk to this bot, contact the owner. copilot studio
I created a copilot studio agent and then embedded it inside a code app. It works fine but i am facing the below error. You don't have access to talk to this bot, contact the owner. copilot studio I have provided Microsoft based authentication and am an owner so will have access to the bot. Yet facing the above issue. Is there something i am missing
New workflow designer accessing environment variables
Hi, I really enjoy using the new workflow designer. I've a triggered workflow (Email arrives) that I added into a solution. I'd like to use environment variables from within the workflow. The variables and the workflow are in the same solution. Unfortunatly the environment variables are not visible like they were in the old designer. How can I access them ? Thanks in advance
Using Dynamics 365 ERP MCP Server from a Standalone Copilot Studio Environment
We have a Copilot Studio environment that is not connected to Dataverse and is not linked to any Dynamics 365 Finance & Operations environment. We would like to use the Dynamics 365 ERP MCP Server from an agent in this Copilot Studio environment to retrieve data from F&O. Is this configuration supported? If so: What connection and authentication setup is required between Copilot Studio and the Dynamics 365 ERP MCP Server? Does the Copilot Studio environment need to be linked to the target F&O environment or Dataverse environment? Can the ERP MCP Server connect directly to F&O independently of the Copilot Studio environment? How is user authentication handled when the agent invokes MCP tools? Does the MCP connection use the authenticated user's F&O permissions, a service principal, or the connection owner's credentials? Are there any prerequisites, limitations, or recommended architectures for using the ERP MCP Server from a standalone Copilot Studio environment?
Custom Agent can’t read scanned PDF/Image received from Flows
I'm trying to build a Flow in Copilot Studio that triggers when a PDF/image is uploaded to SharePoint/OneDrive, passes it to a Custom Agent, which is able to extract text from the PDF/image to generate a standardized filename. The Custom Agent works well standalone (drag-and-dropping scanned PDF/image directly into the Copilot chat box works fine!) But passing the file to the Custom Agent via Flow fails. What I tried Approach A (Base64): Used Get file content, converted it to Base64 via base64(...), and sent a JSON payload (fileName, mimeType, documentBase64) to the Agent. Approach B (SharePoint Link): Used Create share link and passed the file's webUrl to the Agent instead of raw file content The issues Issue with Base64: The Agent receives the payload, but fails on scanned/image-based PDFs, replying: "The uploaded file content is a base64 stream for a PDF and contains no extractable text... requires manual verification." Issue with SharePoint Link: The Agent can't open/read the link, replying: "Since I cannot read SharePoint content directly from just the path, please upload the PDF file here." (even after added a SharePoint MCP tool for the Agent). Questions How can I pass a scanned PDF/Image via Flow so the Custom Agent can read & extract the text (just like it does on direct chat upload)? Thanks for any help!What is the best file format for an AI agent knowledge base?
This is a best practice sharing the best format for an agent and show you why you should convert your PPT, PDF, WORD into a TXT markdown. I had an issue with my agent, time taken to answer was too long, and usually we spend a lot of time asking: What is the best prompt? Why is my agent slow? Why does retrieval sometimes work and sometimes fail? How can I improve answer quality? But I realised I was asking another question much less often: What is actually the best file format for the knowledge base? PDF? Raw text? Markdown? Pre-chunked text? Semantic sections? Context-enriched text? And more importantly: How much does the format alone affect agent performance? I tried to find a quantified benchmark answering this specific question, with the same agent, same source knowledge and same questions, but different knowledge representations. I couldn't find one that really answered what I wanted to measure. So I decided to run the experiment myself on a real case. My first exploratory tests were already surprising: depending on the representation, the agent could be significantly faster and more accurate, despite working from the exact same source information. So I decided to push the test further. My objective I want to identify, without assumptions and based on actual evaluation data, how a long document should be prepared for an LLM knowledge base so that the agent can retrieve, understand, ground and answer from it as reliably as possible. I focused on five dimensions: Answer quality Retrieval reliability Source grounding / citations Execution time Robustness across single-turn and multi-turn questions The broader question I'm trying to answer is: How should we structure knowledge so that an LLM can retrieve and use it as reliably as possible? The test case I deliberately chose a document that isn't particularly friendly for RAG: a 46-page European regulation, https://eur-lex.europa.eu/eli/reg/2011/1169/oj?locale=fr, on the provision of food information to consumers. The information is distributed across articles, definitions, exceptions, annexes, tables, numerical thresholds and cross-references. That makes it useful for testing retrieval: answering correctly often requires finding a very specific piece of information while preserving enough context to understand how it applies. I used the native PDF as the baseline and created 6 additional knowledge-base representations of the same document: Raw TXT Markdown Chunk-ready TXT RAG-oriented units Semantic TXT Contextual TXT One rule: same knowledge, same agent, same instructions, same questions. Only the knowledge representation changes. The benchmark I used two evaluation sets: 42 single-turn questions testing broad coverage of the document: direct facts, thresholds, exceptions, annexes, lists and cross-references. 5 multi-turn conversations containing 13 questions, to see what happens when a user asks a question and then follows up with things like: "And in this case?" "What are the exceptions?" "And for dietary fibre?" This gave me: 47 evaluated test cases / 55 actual questions per format Across all 7 formats: 329 evaluated conversations 385 user questions executed First results Metric Native PDF Best structured representation Overall pass rate 66.0% 85.1% - Contextual TXT Best single-turn score 69.0% 88.1% - Chunk-ready TXT Multi-turn benchmark 40% 80% - Contextual TXT Multi-turn execution time 14m24 5m54 Total benchmark time 44m31 24m49 The quality gap was already substantial: 66.0% → 85.1% That's +19.1 percentage points while keeping the underlying knowledge unchanged. I also saw a major difference in execution time. On the multi-turn test: 14m24 → 5m54 That's approximately 2.4× faster. Across the complete benchmark: 44m31 → 24m49 Around 44% less execution time. These timings represent the complete agent evaluation pipeline, so they shouldn't be interpreted as pure LLM inference latency. But the difference under identical test conditions is large enough that I want to understand it better. Findings There wasn't one format dominating every benchmark. Chunk-ready TXT scored highest on independent questions: 88.1%, while Contextual TXT performed better across multi-turn conversations and finished with the highest overall score. That may suggest that the way we optimise a document for isolated retrieval isn't exactly the same as the way we should prepare it for conversational retrieval. In the contextual version, I tried to make every section understandable when retrieved independently by keeping useful information around it: Source references Section context Retrieval cues Relevant cross-references For regulatory documents, this seems particularly important. A numerical value retrieved alone can be meaningless without knowing which rule it belongs to, under which conditions it applies, and whether another article contains an exception. Where I am now This remains an exploratory benchmark: One document One domain One agent setup One evaluation framework One run per configuration There are plenty of things I still want to test: repeated runs, retrieval-level evaluation, token consumption, larger knowledge bases, other document types, chunk sizes, overlap, contextual headers, and more. But these first results already convinced me that the preparation of the knowledge base deserves much more attention when evaluating an agent. We often spend hours refining instructions while the same information may behave very differently depending on how it reaches the retrieval layer. Next step I'll share the prompts, knowledge-base formats and evaluation methodology on GitHub so the experiment can be reproduced and challenged. I'll keep enriching the repository as I test new formats, improve the evaluation set and add new results. If people here have ideas, edge cases or formats worth testing, I'd genuinely like to include some of them in the next iteration. What would you test next?Copilot Studio Agent Shows Usage Limit Error Despite Low Credit Usage
a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; } Hi everyone, We are experiencing an issue with a Copilot Studio agent and would appreciate any guidance from the community. Scenario: The agent works correctly in the Copilot Studio test environment and responds as expected. However, after integrating the same agent into our web application, users receive the following error: "This agent is currently unavailable. It has reached its usage limit. Please try again later." Additional Information: In Copilot Studio Usage Monitoring, we can only see approximately 4 credits consumed. Based on the reported consumption, we would not expect a usage limit to have been reached. The issue occurs only when accessing the agent through the web application. The Copilot Studio test interface continues to work normally. Questions: Has anyone experienced a similar issue? Could this be related to licensing, capacity allocation, authentication, or channel configuration? Is there any difference in credit consumption or capacity enforcement between the Copilot Studio test environment and embedded web channels? Are there additional monitoring locations where we can verify the actual credit usage and capacity status? Any insights or recommendations would be greatly appreciated.Update: Root Cause Identified
Hi everyone, I would like to share the root cause and solution in case someone else encounters the same issue. The Problem I created several agent flows directly in Power Automate using: https://make.powerautomate.com The flows were configured correctly: The flow starts with When an agent calls the flow The flow ends with Respond to the agent The flow and agent are in the same environment The flow is included in a solution The flow is published and fully functional The flows could be added to an agent and executed successfully. However, unlike flows created directly from Copilot Studio, they did not appear in the Global Tools directory. What I Investigated I verified: Trigger configuration Respond to the agent action Environment consistency Solution membership Publish all customizations Asynchronous response settings Synchronization delays between Power Automate and Copilot Studio None of these were the root cause. Root Cause The issue was related to the workflow Plan. I discovered that: Flows created directly in Power Automate were assigned: Plan = The user running the flow Flows created directly in Copilot Studio were assigned: Plan = Copilot Studio Although the Power Automate flow was fully functional and could be used by the agent, it was not visible in the Global Tools directory. Solution After changing the workflow Plan to: Plan = Copilot Studio the flow immediately appeared in the Global Tools directory. Configuration Location The setting can be found in the workflow properties under: Primary owner → Plan Important Note Based on my testing, changing the Plan to Copilot Studio appears to be a one-way operation and may not be reversible. It may be a good idea to export or save the flow before making the change. Acknowledgements Special thanks to sohnash for reproducing the scenario and providing troubleshooting suggestions, and to Patty_Velasquez for sharing similar observations that helped confirm the behavior. Hopefully this helps others who encounter the same issue. Best regards, Adhonaï KOUKA
