Two requests arrive a minute apart. "What is our home-office reimbursement limit?" calls for one fact from a policy. "I need to renew my work laptop" calls for a conversation that gathers a known set of details in the right order.
Copilot Studio handles those jobs with different components. Knowledge supports open questions. A topic runs a conversation whose path you can define in advance. You'll build both, then decide where each new requirement belongs so facts, behavior rules, and conversation logic don't drift across the agent.
Is it knowledge, instructions, or a topic?
Most grounding errors start with a sound requirement stored in the wrong place. Copilot Studio has three components for these requirements, and each owns a different kind of decision.
- Knowledge contains maintained facts such as policies, limits, dates, and procedures. The agent retrieves them when it answers open questions.
- Instructions define behavior. They say which sources carry authority, whether the agent may guess, how it handles a conflict, and what it says when no answer is available.
- Topics define conversation paths you can plan in advance, including their questions and branches.
The test is quick:
A fact that must stay current lives in knowledge, in exactly one place, because two copies drift apart. A rule about behavior is an instruction. A predictable sequence is a topic. Get the placement right and each piece has one owner you can update. Get it wrong and you'll chase a stale number through three files.
Owners establish source authority
When two documents disagree, an agent needs a rule for which one wins, and the wrong rule is "the newest." A later effective date tells you when something applies. Authority is a different question. The newer file might be a draft, a future policy, or an obsolete copy someone forgot to delete. Authority comes from ownership: the content owner designates one canonical document per subject, and everything else is labeled or removed.
Write instructions that name authority explicitly: which document is authoritative for which subject, and why a later date alone doesn't grant authority. Then handle the case that trips up most agents: two authoritative sources that conflict with no precedence rule. The safe behavior is disclosure. The agent should report both values and their sources and decline to pick. Choosing one and hiding the conflict is the wrong move. A visible conflict is a problem someone can resolve. A hidden one becomes a wrong answer with a confident tone.
Grounding needs a controlled test
A single passing question proves almost nothing. Test the boundary from four angles: a supported question the source answers, an unsupported question it doesn't, a paraphrase of the supported question, and, when you can set it up, a deliberate conflict between two authoritative sources. Paraphrases matter because equivalent questions should yield equivalent facts. If reordering the words changes the answer, the grounding is fragile.
Grade every run on five criteria: the facts are consistent across phrasings, the correct source and section are used, exact values are preserved, no unsupported detail is added, and uncertainty is disclosed rather than papered over. A response fails if any one criterion fails, even when the prose is excellent.
When something is wrong, resist the urge to blame the model. Diagnose the earliest failing boundary: is the fact missing or unclear in the source, does retrieval fail to reach it, does generation change it, do sources conflict, or does a user receive something they shouldn't? That last one, permission, is part of grounding quality. Practitioners regularly find agents answering worse than plain SharePoint search, and the fix is almost always at one specific boundary. Blaming "the agent" as a whole rarely helps.
Topics collect data through branches
When a request follows a predictable shape, a topic beats a grounded answer: you decide the questions and branches in advance. Start with trigger phrases: examples of how someone might open the topic, said in whatever words feel natural to them. The best triggers pair the object with the outcome: "I need to replace my broken work laptop" clearly signals a replacement request, while "my laptop is broken" could just as easily mean troubleshooting.
That ambiguity is why near-miss testing matters. Before you trust a topic, feed it phrases that shouldn't start it, such as "how do I connect my laptop to a monitor?" or "where is my existing order?", and confirm it stays out of the way. A topic that grabs troubleshooting questions is worse than no topic.
Inside the topic, order the questions so every value a later step needs is collected first. Use a structured choice for anything that controls routing, like new-versus-replacement, because a branch needs predictable values to compare. Use free text for descriptive answers that don't steer the conversation. Capture each answer in a variable, and keep a small worksheet mapping your logical names to whatever the editor stores them as. Those stored names shift between builds, and the worksheet saves you from guessing later.
Branch state determines topic correctness
The defect that ships most often is a confirmation message that references a variable the current path never collected. Picture a topic that asks for an asset tag only on the replacement path, then ends every path with one shared confirmation that lists the asset tag. On the new-equipment path, that value doesn't exist, so the confirmation is broken by design.
The fix is to track branch state explicitly. Collect every variable both branches need before the condition that splits them, and collect branch-specific values only on the paths that use them. Then give each path its own confirmation that references only what that path has.
Read the table as an invariant: every value a confirmation displays must show "yes" in that row. If it doesn't, split the confirmation instead of padding a path with a question it doesn't need. This bookkeeping is tedious, but skip it and a topic ships a blank value in front of a user.
