Common Mistakes and Troubleshooting
Copilot Studio makes it fast to get a first agent running, which is great, but that same speed means it's easy to publish something before you've worked through a few issues that reliably show up. Here's what to watch for.
Instructions that describe a personality instead of a policy
It's common to spend a lot of effort on how an agent should sound (friendly, professional, concise) and much less on the actual decision rules it needs to follow. Tone matters, but if your instructions don't clearly define what the agent should and shouldn't do in specific situations, the orchestrator is left guessing. Write instructions the way you'd write a policy for a new team member, not just a style guide for how they should talk.
No knowledge source, or the wrong one
If an agent's answers feel vague or made up, check the knowledge source before you touch the instructions. An agent with no connected knowledge source, or one connected to the wrong document, can only answer from general knowledge, which is rarely accurate enough for anything specific to your organization. This is one of the fastest fixes available and often gets overlooked in favor of more complicated prompt engineering.
Tool descriptions that don't say when to use the tool
The orchestrator decides which tool to call based on its description. A tool labeled just "submit request" doesn't tell the orchestrator much if there are multiple request types the agent could plausibly submit. Describe not just what a tool does, but specifically when it should be used, including what makes it different from any similar tool the agent also has access to.
Leaving everything to generative orchestration
Generative orchestration is powerful, but it's a mistake to assume it should handle every conversation path, including the ones with real consequences. If there's a flow you can't afford to have go slightly off-script (anything involving compliance, legal language, or financial commitments) build it as a topic with a fixed structure instead of trusting the model to improvise it correctly every time.
Testing only the scenario you designed the agent around
It's natural to test with the exact question you had in mind when you built the agent, confirm it works, and call it done. The problems show up with the questions you didn't anticipate: a question slightly outside the agent's intended scope, a request that combines two different topics, or a question phrased in a way you didn't expect. Test deliberately with a few of these before publishing, including at least one question the agent genuinely shouldn't be able to answer, to confirm it declines gracefully instead of guessing.
Publishing to the wrong channel, or too many channels at once
An agent that works well in a test chat doesn't automatically work well once it's live in Teams, on a website, and inside Microsoft 365 Copilot simultaneously. Different channels come with different user expectations and different conversational contexts. Start with the single channel where your intended users actually are, confirm it performs well there, and expand deliberately rather than publishing everywhere at once and hoping for the best.
Ignoring the analytics pane after launch
Once an agent is published, it's easy to consider the project finished. The analytics pane is where you'll actually learn whether it's working: which questions it struggled with, where conversations got abandoned, which knowledge source or tool got picked incorrectly. Skipping this means you only find out about problems when a frustrated user complains, instead of catching the pattern early.
Adding a second agent before the first one is solid
Agent-to-agent communication is a genuinely useful way to scale beyond a single agent, but it multiplies whatever issues your first agent already has. If your first agent's instructions are vague or its tool descriptions are ambiguous, connecting a second agent to it just means those problems now show up in two places instead of one. Get the first agent reliably right before you build a system around it.
Where to go from here
If an issue doesn't fit neatly into any of the categories above, it's worth revisiting Core Concepts and checking each of the four building blocks (instructions, knowledge, tools, topics) individually. Most persistent problems trace back to one of these four not being set up the way you assumed.