Copilot Studio: Single message spanning two topics returns two responses, each mixing correct and default-orchestration answers

Question

Scenario

We're building an AI assistant using Copilot Studio, combining custom topics, live API data as knowledge sources, and generative AI orchestration.

When a single user message spans two topics (e.g., "What is Topic A's status, and what's available under Topic B?"), the agent always returns two separate messages. Each message answers both parts, but one part is correct (from the right topic) and the other part comes from default orchestration instead. Which part is correct swaps between the two messages: the first message gets Topic A right and Topic B wrong; the second gets Topic B right and Topic A wrong.

Result

Instead of one combined, fully correct response, the user receives two separate messages, each half-correct and half-generated by default orchestration.

Environment

Copilot Studio agent using standard generative AI orchestration, with multiple custom topics each backed by their own connector actions and generative answer logic.

Troubleshooting efforts

Confirmed each topic independently produces a correct answer when tested in isolation with a single-topic question. The issue only appears when a message spans two topics at once.

Question

Is there a way to combine both topics' correct answers into one response instead of two? Why does default orchestration attempt to answer both parts of the question even when a dedicated topic already handles each one correctly? Can default orchestration be suppressed when a topic has already handled part of the question?

Answer 1

Yes. The supported pattern is to have each topic return structured outputs that explicitly report what it already answered, and let the orchestration layer compose the final response from those outputs instead of having each topic write overlapping user-facing answers.

Why this happens:

1. In generative orchestration, multiple components can participate in one turn.
2. If a topic answers part of the request but doesn’t clearly report that completion through outputs such as an answered-state flag and returned values, later orchestration can treat that part as still unanswered.
3. The orchestration layer can proactively use knowledge along with topics and tools, so it may try to answer both parts of a multi-part request unless each component reports exactly what it handled.
4. This is especially common when context only contains plain text and not the fact that a topic already showed an answer to the user.

What to do:

1. Change each topic so it returns outputs, not just message-node text.
   • Return the actual result as an output variable.
   • Return an answered output that is true when that topic already handled its part.
2. Update each topic description so the orchestration layer knows when not to answer again. The documented pattern is:

      This topic handles account balance requests. 
      If its answered output is true, the user has already received their response and it should not be answered again.
   

   Apply the same pattern to Topic A and Topic B with their own outputs.
3. For multi-part requests, have each topic return only its own structured result and completion state. Then let the orchestrator combine those outputs into one final response.
4. If a topic currently writes the answer directly to the user, make sure it also reports what it answered and any values needed by later steps. Otherwise another component can answer again.
5. If one component fully handles the request, use End all topics so the orchestration layer has no reason to add another response.
6. Test with the exact model configured for the agent. Whether the orchestrator restates or duplicates an answer can vary by model.

About suppressing default orchestration:

It can’t be forced to use a specific knowledge article or prevented from using knowledge simply because a topic exists. The documented approach is not to suppress orchestration globally, but to design topics as mini-agents that:

• return outputs instead of only messages,
• include answered-state outputs,
• return any values later steps need,
• clearly describe in the topic description how the orchestrator should treat those outputs.

Also note:

• Knowledge can complement topics and tools proactively, not only as fallback.
• In standard harness context, plain text from topics may be available, but the fact that the user already saw an answer is not reliably preserved unless returned as outputs.
• Adaptive Card interactions are a known source of context mismatch, so card selections should also be returned as outputs.

For the behavior described, the root cause is consistent with duplicate-message design issues in generative orchestration: each topic answers its own part correctly, but the orchestration layer still sees the other part as unanswered and generates an additional partial answer. The fix is to make both topics explicitly report completion and values through outputs, then rely on orchestration to merge those outputs into one response.

---

References:

• Design best practices to avoid duplicate messages
• Design topics as mini-agents that avoid duplicate messages
• Troubleshoot duplicate messages and missed answers
• Apply generative orchestration capabilities
• Context distribution in the standard harness
• Orchestrate agent behavior with generative AI
• Inconsistent Output Behavior in Generative AI Action within Copilot Studio Topic - Microsoft Q&A