Copilot Studio + SharePoint: Markdown (.md) Files in Doc Libraries Supported as Knowledge Sources?
Hi all, We’ve been doing some deeper testing with Copilot Studio agents grounded in SharePoint knowledge sources, and I’m hoping to clarify whether what we’re seeing is a known limitation or an undocumented gap. Scenario A Copilot Studio agent uses SharePoint document libraries as a knowledge source The library contains Markdown (.md) files that are intentionally used as canonical design references The same .md files: ✅ Work well when uploaded directly to the agent ❌ Are not retrievable or citable when stored in a SharePoint library and added as a SharePoint knowledge source To help with grounding, we created modern SharePoint index pages that: Explain what the markdown collections are (Patterns, ADRs, Guardrails) Link directly to the canonical folders and files Explicitly state that the .md files are the source of truth The agent can: Discover and summarize the index pages correctly Understand that .md artifacts exist and where they live But it cannot: Read the content of the individual .md files Apply a specific pattern or ADR from those files in a design conversation Cite them as sources, even when permissions and search indexing are confirmed What We’ve Checked Permissions (agent user has access) Folder depth (kept shallow) Search results (markdown files appear in SharePoint search) SharePoint indexing status Work IQ enabled Same content works when attached directly to the agent This behavior also seems consistent with what others have reported here: Markdown works when uploaded directly Markdown retrieval degrades when hosted in SharePoint libraries Questions for the Product Team / Community Are Markdown (.md) files in SharePoint document libraries officially supported as Copilot Studio knowledge sources today? If yes, are there specific constraints (file size, rendering, parsing, indexing) that differ from Word/PDF? If no (or “not yet”), is this a known limitation on the roadmap? Is the recommended pattern to: Convert important markdown files into .aspx pages, or Use thin “index / summary” pages and keep markdown canonical until retrieval improves? We’re happy to adapt our information architecture — just trying to align with the intended platform direction rather than work against it. Thanks in advance for any guidance or clarification. This capability is extremely powerful, and clearer expectations here would help a lot of teams make the right design tradeoffs.
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 missingAgent Builder, Copilot Studio, or Azure AI Foundry: How We Decide for Every Client
Every client conversation starts the same way. Someone has seen a demo, attended an Ignite session, or read a press release. They want to build an agent. Then comes the question that derails more projects than any technical challenge: "Which tool should we use?" After deploying agents for clients across industries - insurance, professional services, manufacturing, public sector - we have developed a repeatable framework for answering that question. It is not based on which tool is newest or which has the best marketing. It is based on where projects actually succeed or fail in production. The three tools are not competitors The first mistake most teams make is treating Agent Builder, Copilot Studio, and Azure AI Foundry as a hierarchy - basic, intermediate, advanced. That framing leads to bad decisions. They are not a ladder. They are three distinct tools built for three distinct contexts. The right question is not "which tool is most powerful?" It is "which tool fits this project's constraints?" The framework: 4 questions We evaluate every project against four dimensions before recommending a tool: Who is building it? Where do users live? How complex is the logic? Who owns it after go-live? Agent Builder Copilot Studio Azure AI Foundry Builder profile Maker, no code Developer / power user Pro developer, Python User surface M365 Copilot Chat Teams, web, M365 Copilot Custom app, any surface Logic complexity Simple Q&A, task routing Multi-step flows, connectors Fully custom orchestration Post-go-live ownership Business team IT + Business joint Engineering team Governance M365 Admin Center Power Platform DLP Custom, Azure RBAC When we recommend Agent Builder Agent Builder is the right call when the business team wants to own the agent end-to-end, the use case is bounded, and the users already live inside M365 Copilot Chat. The key advantage is distribution - an Agent Builder agent surfaces natively inside Copilot Chat with zero additional deployment work. No IT ticket, no app registration, no Teams app package. The ceiling is real. Agent Builder does not support complex branching logic, external API calls, or dynamic prompt injection. The moment a client asks "can it also update a record in our CRM?" the answer is usually no. Use it when: The maker owns it, the use case is narrow, and M365 Copilot is already the user's primary surface. When we recommend Copilot Studio Copilot Studio is our default recommendation for the majority of enterprise agent projects. It covers the wide middle ground between no-code simplicity and full-code flexibility - within the Microsoft governance perimeter most enterprise IT teams already control. Power Platform connectors - 1,000+ out-of-the-box connectors means most enterprise data sources are reachable without custom API development M365 Copilot channel - surface a Copilot Studio agent directly inside M365 Copilot Chat, Agent Builder-level distribution with enterprise-grade logic underneath Topic-level governance - fallback behaviors, confidence thresholds, escalation paths configurable without code DLP policy enforcement - the agent operates within the same data loss prevention perimeter as the rest of the Power Platform tenant The most common mistake: under-investing in the knowledge layer. The agent authoring is the easy part. Getting SharePoint content structured, metadata consistent, and documents deduplicated is where most projects hit delays. Budget for it. Use it when: The use case requires connectors, dynamic responses, or M365 Copilot integration - and you want IT to own governance without requiring a developer team. When we recommend Azure AI Foundry Foundry is the right call when you need to bring your own model, build a fully custom orchestration pipeline, or integrate into a surface that has nothing to do with Microsoft 365. In practice, this means one of three scenarios: The client has a model fine-tuned on proprietary data that must be used The agent is embedded inside a custom-built web or mobile application The logic requires Python-level control - complex reasoning chains, multi-agent coordination, custom evaluation loops Foundry projects require a professional developer, take longer, and produce something the business team cannot maintain without engineering support. That is not a reason to avoid it - it is a reason to be honest with the client upfront. Use it when: You need full control of the model, the orchestration, or the surface - and you have a developer team to own it. The question that resolves most debates When a client is torn between Copilot Studio and Foundry, we ask one question: "Who is answering the 2am support call when this breaks in production?" If the answer is a developer, Foundry is viable. If the answer is the IT admin or the business owner, Copilot Studio is the right call. Not because Foundry is unreliable, but because the operational model has to match the tool. More projects fail from ownership mismatch than from technical limitations. What we see go wrong Reaching for Foundry too early. Developers often want full control and reach for Foundry before validating the use case. We have rebuilt several Foundry POCs in Copilot Studio when the production constraints called for it - faster to ship and cheaper to run. Under-scoping Agent Builder. Business teams choose Agent Builder because it looks simple, then hit the ceiling at month two. The re-platform cost is higher than building in Copilot Studio from the start. Ignoring the M365 Copilot channel. Many Copilot Studio projects are deployed as standalone Teams apps when they could surface directly inside M365 Copilot Chat. The distribution advantage is significant and underused. The short version Agent Builder - maker-owned, bounded use case, M365 Copilot surface, fast Copilot Studio - IT + business joint ownership, connectors, production governance, M365 Copilot integration Azure AI Foundry - developer-owned, custom model or surface, full control, higher cost Start with the ownership model. Everything else follows. Elliot Margot - Team Lead Jumpstart, Copilot and Agents at Witivio (Microsoft Partner). Connect on https://www.linkedin.com/in/elliot-margot-52742a156/.From SOP Overload to Simple Answers: Building Q&A Agents With SharePoint Online + Agent Builder
Government teams run on Standard Operating Procedures, manuals, handbooks, review instructions, HR policies, and proposal workflows. They’re essential—and everywhere. But during every Government Prompt‑a‑thon we've run this year, one theme kept repeating: "Our policies are many and finding the right answer quickly is nearly impossible." Turning SOPs into Simple Q&A Agents with M365 Copilot's Agent Builder or SharePoint Agents is possibly one of the fastest wins for public‑sector teams.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?
Giving AI Agent access to move files between folders
Hi Community, I have built a PDF to Excel reconcilliation AI Agent using Microsoft Copilot that reconciles supplier statements against payables data for our organisation. The agent works well. it reads PDF supplier statements and Excel reports from a SharePoint document library, performs the reconciliation, and produces a structured audit-ready report. However, I am hitting a limitation at the final step. Once the reconciliation is complete, I would like the agent to automatically move the processed supplier statement PDF from its current folder to a subfolder called "reconcilled" within the same SharePoint document library. My question is What is the recommended way to give a Copilot AI Agent the ability to move files between SharePoint folders? Any guidance, documentation links, or examples from others who have implemented similar workflows would be greatly appreciated. Thank you!Welcome let's get started
Welcome to the Copilot Studio Community on Microsoft Tech Community! We're thrilled to announce that Copilot Studio now has a dedicated home on the Microsoft Tech Community, and we'd love for you to be part of it from day one. Whether you're just getting started with building Agents in Agent Builder or you are a pro building agents and automations with Copilot Studio, this is your space to: Ask questions and get answers from the community and Microsoft experts Share what you've built — show off your agents, flows, and use cases Stay up to date on the latest features, releases, and best practices Connect with peers across industries who are shaping the future of AI-powered work The community is open to everyone, from first-time explorers to seasoned pros. Every question asked and every insight shared makes this a better resource for all of us. We can't wait to see what you build. Welcome!
