Microsoft Copilot Studio Knowledge Tuning - Simply Explained

Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. Why your copilot agent can sound sure and still be wrong. Your copilot studio agent can sound completely sure of itself and still be wrong. It happens because the agent answers from the wrong place, either its own general knowledge or a document you never meant it to use. For a beginner, that is genuinely confusing because you did everything you were told and still got an answer you can't trust. Knowledge tuning is the set of choices that fixes this, and none of them require code. Welcome to the M365 FM podcast, where we explore the people, ideas, and technologies shaping the future of work. And today we are making copilot studio knowledge simple. By the end, you'll know the one setting that decides whether your agent is allowed to guess and the quiet mistakes that make it ignore your files. What knowledge actually means in Copilot Studio. The word knowledge hides in plain sight, so it's worth slowing down for a moment. When you build an agent in Copilot Studio, you're really putting three things together. There's the language model that writes the sentences, the topics, and tools that let it take action, and the knowledge it can look things up in. The model is the engine, and knowledge is everything you connect. So the sentences are based on your content instead of the model's memory. Microsoft has a name for this and they call it grounding. The idea is simple because the evidence the agent retrieves controls the answer it gives. If the retrieved evidence is your refund policy, the agent answers from your refund policy. If there's no evidence at all, the model falls back on whatever it absorbed during training. That's when it invents something that sounds reasonable and is completely wrong. Picture a small example. You set up an agent for your team and connect the HR handbook. Someone asks how many days of parental leave they get. The agent finds the page, reads the relevant paragraph, and answers with the number and a link. Now imagine you never connected the handbook. The same question still gets a fluent, confident answer because the model has read plenty about parental leave in general. That answer has nothing to do with your company, and nobody would know it was wrong unless they checked. The part that trips up beginners is a simple mix up. You are not training the bot, and you're not changing the model's brain or teaching it like a pet. You're handing it a library and a library card, then trusting it to find the right shelf. That distinction matters because it tells you where to spend your effort. You don't need to feed it thousands of examples, and you do need the right books with a clear sign on the door. There's more good news, and it's what lets a beginner win here. A brand new agent already ships with a place to put that knowledge. Copilot studio creates a system topic called conversational boosting, and inside it sits a generative answers node. That node is what turns a question into a search and then into a plain language reply. Add your knowledge at the agent level and it flows into that node automatically, which means you can have a useful agent working without writing a single topic by hand. The sources you can plug in and how the agent searches them. The list of sources is longer than most people expect. You can point an agent at a public website, upload documents, connect a SharePoint site, pull from Dataverse, or reach enterprise data through Microsoft's connectors. There's also Azure AI search for very large collections and a category Microsoft calls Unstructured Data, which covers OneDrive files and folders, SharePoint folders, and knowledge bases from systems like Salesforce, ServiceNow, confluence, and Zendesk. When you use one of those connectors, your organization's content is indexed by Microsoft Search first, and the agent searches that index. For a beginner, the sound advice is to start small. If your team already keeps its answers in a SharePoint site, connect that. If you have a handful of well written PDFs, upload those instead. You don't need to connect everything on day one because connecting more sources is not automatically better. Every source you add is another shelf the agent has to search, and a crowded library can actually make answers. Worse, how the agent searches those sources depends on a mode you might never have noticed. Classic orchestration treats knowledge as a fallback, so it only searches after your author. Topics fail to match, and it caps how many sources it will look at, for example, up to four SharePoint URLs and four website URLs. Generative orchestration is the default for new agents, and it flips that around. The agent reads the description of each source, decides which ones are relevant, and searches them directly. It also raises the limits to twenty five SharePoint URLs, twenty five websites, and effectively unlimited Dataverse sources. Dataverse works a little differently from the others because it uses a retrieval technique that combines search with generation. Rather than matching a single page, it finds the rows and tables that fit the question, and then it lets the model summarize them. That makes it a natural fit when the answers already sit inside a business app, a safety net is built into all of this, and that check is what lets you sleep at night. The agent only surfaces content that the person asking is allowed to see. Those permission checks happen live against the original source. So if someone in marketing asks about a finance topic, the agent won't hand them a document they have no right to open. You inherit the permissions you already set, and that's a good thing. How your files turn into an answer. Follow a single document with me from the moment you upload it to the moment it answers a question. Because this is where the work actually happens. When you upload files, Copilot studio stores them in Dataverse. The system then breaks each file into small pieces, turns those pieces into something called vector embeddings, and builds a semantic index over them. A vector embedding is just a way of turning meaning into numbers, so the computer can measure how close two ideas sit to each other. When someone asks a question, the agent doesn't reread the whole library. It converts the question into the same kind of numbers, finds the chunks whose meaning lands closest to the question, and hands those chunks to the model. The model then writes a clean answer from them. That's why the quality of your writing matters so much. Clear headings and plain sentences create cleaner chunks, and cleaner chunks get matched more often. Think about a long policy document with no headings and page after page of dense paragraphs. The system still cuts it into chunks, but those chunks mix several ideas together so the search gets fuzzy. Rewrite the same document with short sections and descriptive headings, and each chunk holds one clear idea. The agent now retrieves the exact paragraph a person needs, and the answer gets sharper without any change to the technology. SharePoint deserves its own warning because it gives you two doors and they behave differently. The first door copies your files into Dataverse and searches a vector index built from them. It's great for high quality semantic search, and it supports SharePoint lists. The trade off is that it consumes Dataverse storage and only refreshes every four to six hours. The second door connects straight to SharePoint and queries it live, which means no storage cost and no delay. It also supports things like sensitivity labels and filters by author or modified date. Both doors stay current on their own because a scheduled job keeps the content fresh and removes anything you deleted from the source. You just can't press a button to force a refresh, so plan around that. If your team updates a policy on Monday morning and expects the agent to know it by Monday afternoon, the copy in option will let you down while the live connector keeps up. The one setting that decides whether your agent is allowed to guess this is the setting I promised you at the start, and it has a plain name. It's called allow ungrounded responses. When it's on, your agent is free to answer from the model's general knowledge, even when no knowledge source and no tool was used. When it's off, the agent blocks any answer that didn't come from a source or a tool, and it only lets an answer through when that answer includes a citation pointing back to where it came from. For most beginners, off is the right starting point. You built this agent to answer from your content, so letting it quietly switch to guesswork defeats the whole point. There's a catch you should know about, and it's an honest one. Turning this setting off doesn't guarantee the agent never uses general knowledge because the model can still blend its own knowledge with what it retrieved. Because models sometimes forget to include a citation, a genuinely correct answer can get withheld, and the agent will act as if it found nothing. Asking the same question again often works, which feels strange until you remember how these models behave. The fix is to make citations more reliable in your agent's instructions. Ask it to always cite the source document for every statement. Then avoid instructions that. Fight against that, like forcing a rigid format such as respond only in Json, because those can strip out the very citation mark as the agent needs. Keep your instructions short and let the model breathe. This one switch does more for trust than almost anything else you'll touch. It's the difference between an agent that tells you what it knows and where it learned it, and an agent that simply sounds confident. How to tune knowledge in practice. All of that becomes a routine you can actually follow. Step one is to choose the smallest, cleanest set of sources that answers the questions real people ask. A tight, well-written set beats a giant pile every time, because every extra source sauce is another chance for the agent to grab the wrong one. Step two is the one almost everyone skips, right? A specific name and a clear description for every sauce. Generative orchestration picks sauces by reading those descriptions so the description is doing real work. Microsoft's own example of what not to do is a sauce called answer question, with the description that it answers questions that tells the agent almost nothing. A better version says exactly which topics the sauce covers and just as useful what it doesn't cover. Step three is the decision you already met, grounded only or allowed to guess, plus a short instruction to cite sources. Step four is where the tuning actually happens and it's testing. Open the test your agent panel and ask the awkward questions. A real user would ask, if you want a shortcut, pull the last twenty questions from your support inbox and run those test one sauce at a time by turning the others off so you can tell which sauce is actually carrying the answer. If an answer looks wrong, that isolation is how you find the culprit. Step five is a small but powerful flag. If a sauce goes through a strict review and you trust it completely, you can mark it as an official sauce and the agent can use it directly. Just know that this flag and generative orchestration don't work well together, so you'd have to turn orchestration off to use it while you test. Expect a few real limits. The agent has trouble with questions that need calculations or comparisons, and it can misread words like best or latest. If it can't answer, it asks you to rephrase, and after two tries, it hands the conversation to a person. That's not a failure because that's the system. Admitting it doesn't know where it quietly goes wrong. Knowledge problems are usually invisible until someone asks the wrong question. The ones that catch beginners most often are worth knowing before you hit them. The first is the agent answering from general knowledge, while you assume it's using your files. That almost always traces back to allow ungrounded responses being left on. And it's the reason a confident answer can be flat wrong. Then there's the description problem, which makes the agent pick the wrong source or the wrong topic entirely. If two of your topics sound alike, the agent may pick one almost at random. So make the descriptions distinct and say what each one excludes. Another source of trouble is a source that never finished preparing. Every source has a status and only sources marked ready can be used. A source can sit in progress while it's still indexing or land in unknown because Dataverse search is switched off. The authentication is set wrong, or a data policy blocks it. It can also show an error when the file type isn't supported. The file is too big, the source limit is reached, the original file was deleted, or the file is encrypted or carries a sensitivity label. Timing is a trap too. If you use the copy and SharePoint option, your content syncs on a four to six hour cycle, and assuming otherwise, will make you think the agent is broken when it's just behind. The last one is easy to miss because it appears in a single place inside Microsoft Teams. A response shows at most twenty citations and long titles and snippets get shortened if you customize the answer yourself instead of letting the agent render it, the citations don't come back automatically, and you have to build that part on your own. The limits you cannot design around some limits are not bugs, and you can't tune them away, so it's better to know them upfront. The biggest one is that these answers aren't deterministic. Ask the exact same question twice and you can get two different answers. The agent folds the earlier conversation into how it reads the new question. Microsoft compares it to asking a local for directions twice. The second time they give you a slightly different route because they assume their first answer must not have landed. Then there are the hard numbers. A single agent can hold up to five hundred knowledge objects, which can be files, folders, articles, or websites. It can only use five different sources at a time. So SharePoint, Dataverse, and OneDrive might already fill your slots. A single uploaded file tops out at five hundred and twelve megabytes, and one agent can include as many as five hundred files. Once you pass twenty five knowledge sources, an internal model starts filtering them, though uploaded files don't count toward that number. There's also a cost angle worth knowing if you turn on semantic search for tenant graph grounding, it improves retrieval quality for SharePoint content. The catch is that it costs extra credits and needs a Microsoft three. Sixty five Co-Pilot license in the same tenant. If you don't have one, leave it off. One last wall exists for the advanced crowd. Generative orchestration. Can't use custom data or Bing custom Search directly if you need those. They have to live inside a specific generative answers node instead. None of these limits should scare you because they simply tell you where to aim your effort. How this fits into Microsoft three hundred sixty five and Azure. It helps to see where all of this sits. Because Copilot Studio doesn't live alone. It's part of the power Platform family alongside Power Apps and Power Automate, and it connects outward into Microsoft three hundred sixty five and Azure. That means the knowledge you tune here can reach the same content people already use in teams, SharePoint, and OneDrive without you copying anything by hand. Microsoft three hundred sixty five has a bigger idea layered on top of grounding, and it's called copilot tuning. It goes further than connecting sources because it actually fine tunes a model on your organization's content. The agent then picks up your terminology, your tone, and your quality standards. You build these tuned agents from templates without code for tasks like writing documents, summarizing them, answering expert questions, validating a document against policy, and editing writing style. The clean way to hold the difference in your head is this grounding changes what the model can look up, and tuning changes how the model behaves. One gives the agent better facts and the other gives it better habits. Copilot tuning is still an early access preview with limited availability, so treat it as where things are heading rather than something you can switch on. Today. Azure shows up when your content is large or already lives there. You can add Azure AI search as a knowledge source, point it at a vector index and let it search enormous collections with something called a semantic ranker. It can also sit behind private endpoints. If you need the extra security for a first agent, that's more than you need. But it's good to know the road keeps going. The short recap your turn and the sign off time to bring it together. Knowledge is simply what your agent is allowed to answer from, and grounding is the promise that the answer comes from your content. The two things that move the needle most are clear descriptions and the ungrounded responses. Setting and the habit that saves you is testing one source at a time. The limits are real, but they're manageable once you know them. So here's my question for you. If you built an agent this week, which single document would you connect first and why that one? If this made the topic feel less intimidating, subscribe to M365 FM to master the tools and the mindset shaping the future of work.