Multi-agent :Microsoft 365 Copilot returns "Sorry, I wasn't able to respond to that"

(2) Share

Report

Posted on by CU27080519-2

multi-agent setup and I'd really appreciate any insight — even partial information or things to rule out would help a lot.

My setup

Multi-agent architecture in Copilot Studio
Agent A (parent): acts purely as a router. Its instructions explicitly tell it not to reason or search on its own, and it has no knowledge sources attached at all.
Agent B (child/connected): holds the actual knowledge. It uses SharePoint documents uploaded as knowledge (Dataverse-backed upload, not link-based).
A calls B, and B performs the knowledge search and generates the answer.

What works

In the Copilot Studio test pane, everything works perfectly. B searches the knowledge and returns a complete, accurate answer every single time.

What doesn't work

When I use the same agent in Microsoft 365 Copilot, the first one or two turns return the answer correctly. After that, every subsequent turn returns:

"Sorry, I wasn't able to respond to that. Is there anything else I can help you with?"

The confusing part

When I check the Activity map / Activity tab in Copilot Studio for those failed turns, the answer IS being generated correctly. The knowledge search runs, and a full, well-formed response exists in the activity log. It just never reaches the user in Microsoft 365 Copilot — the generic error message is shown instead.

So this doesn't look like a generation failure or a knowledge retrieval failure to me. It seems like something between the generated response and what Microsoft 365 Copilot actually renders.

What I'd like to know

Has anyone seen this specific pattern, where the response is confirmed generated in Activity but Microsoft 365 Copilot still shows the generic error?
Is this a known limitation with connected/child agents in the Microsoft 365 Copilot channel specifically?
Could response length or formatting (my answers contain markdown tables and multiple sections) cause the M365 renderer to drop the response?
Could conversation state size or throttling explain why it only fails after the first couple of turns?
Is there a better place than Application Insights to see why the M365 channel discarded a response that was successfully generated?

Any information at all would be genuinely appreciated — pointers, similar experiences, or even just confirmation that someone else has hit this. I've been stuck on it for a while.

Thanks in advance!

Categories:

Bot administration

All responses (5)

Answers (0)

Sort by

Suggested answer

Haque 4,280 Super User 2026 Season 2 on at

Like
a
(1)

Report
Copy link

Link copied!
Hi @CU27080519-2,

One suspected area is in Microsoft 365 Copilot, the conversation context and token limits are more strictly enforced than in the test pane. After a few turns, the context passed between the parent and child agents may be truncated or lost, causing the child agent to fail to generate a response.

Two things we can do her is, One: consider passing essential context only from Agent A to Agent B, summarise or truncate conversation history. Two: let's add retry or graceful fallback logic in the parent agent to handle child agent failures.

It may happen that backend generated response but the Microsoft 365 Copilot frontend or channel may discard or fail to render it, resulting in the generic fallback message. This discrepancy often points to issues in the rendering pipeline or response handling on the client side.

Yes, multi-agent orchestration (or connected/child agents) can behave differently in Microsoft 365 Copilot compared to Copilot Studio test panes.

Please note that large or complex responses with markdown tables, multiple sections, or rich formatting can exceed rendering limits or cause parsing issues in the Microsoft 365 Copilot UI, leading to dropped or truncated responses and fallback messages.

References:

Token Limit Exceeded and where it breaks

Mastering error handling in copilot studio
Suggested answer

11manish 4,802 Super User 2026 Season 2 on at

Like
a
(0)

Report
Copy link

Link copied!

High probability of a connected-agent/context/response-handoff issue, with Microsoft 365 Copilot channel processing as the leading area to investigate — not a SharePoint or knowledge-generation failure.
Suggested answer

Mohsin Ali 1,075 on at

Like
a
(0)

Report
Copy link

Link copied!

Hello @CU27080519-2 - From your Activity logs, it looks like the child agent is actually generating the response successfully, this actually roll out knowledge retrieval or SharePoint issue.

My suspicion would be around the response handoff from the child agent back to the parent agent / Microsoft 365 Copilot channel. Since it works for the first couple of turns and then starts failing, the conversation context or response size may be growing enough to hit a token, payload, or rendering limitation.

I would try reducing the amount of conversation context passed to the child agent and also test with a much shorter plain-text response without markdown tables or multiple sections.

Also, if possible, test the child agent directly from Microsoft 365 Copilot instead of invoking it through the parent agent. If the same response works when the child agent is called directly but fails through the parent agent, that would strongly point toward an issue in the parent-child handoff rather than the child agent itself.

If the shorter response consistently reaches Microsoft 365 Copilot, that would further support the possibility of a response size or context-related limitation.
Suggested answer

M Bilal Khan 376 on at

Like
a
(0)

Report
Copy link

Link copied!
I’ve seen a very similar pattern reported with Copilot Studio connected agents, and based on what you’ve described, I would also focus on the channel delivery/rendering path rather than the knowledge retrieval itself.

The strongest clue is that the Activity map shows the child agent completing the search and generating a valid response, while the Microsoft 365 Copilot channel replaces it with the generic “Sorry, I wasn't able to respond…” message. There is a recent Microsoft Q&A case with essentially the same Test-pane-vs-M365/Teams behavior, where the response was successfully generated but failed when being surfaced through the channel. Microsoft’s guidance there was to treat this as a channel-side serialization/rendering issue and provide the conversation/operation IDs to Support.

A few things I would test before changing the architecture:

Test the child agent with plain text only. Temporarily remove Markdown tables, complex formatting, multiple sections, etc. If a short plain-text response consistently reaches M365 Copilot but the formatted response does not, that would strongly point toward response serialization/rendering rather than grounding.

Test the same parent → child flow in Teams as well as M365 Copilot. If both channels fail while the Copilot Studio Test pane works, that further isolates the problem to the published channel path.

Check whether the issue follows a particular child-agent response. For example, have the child return only Knowledge search completed successfully without actually returning the generated answer. Then progressively add the answer content back. This can help establish whether the failure is related to the payload/format rather than conversation state.

Capture the Conversation ID, timestamp and operation/activity IDs for one successful turn and one failed turn. Since the Activity map already proves that the response was generated, these identifiers should give Microsoft Support something concrete to trace on the channel side.

I would also be cautious about assuming that conversation-state size or throttling is the cause simply because it starts failing after a couple of turns. It is worth testing with a fresh conversation and very short responses, but the fact that the Activity log contains the complete generated answer makes a downstream delivery problem much more likely.

There is also an important point around multi-agent chaining. Microsoft’s current connected-agent experience has limitations around multi-level agent chaining, and this area is still evolving. A similar Microsoft Q&A case found that inserting another Copilot Studio child-agent layer did not resolve the channel failure.

So, based on the symptoms you provided, my first conclusion would be:

Knowledge retrieval/generation: working → Copilot Studio orchestration: working → response delivery/serialization to M365 Copilot: likely failing.

I would not redesign the knowledge architecture yet. First reproduce it with a minimal plain-text response and collect the successful/failed operation IDs. If the minimal response still fails only in M365 Copilot, I would raise it with Microsoft Support as a channel-specific connected-agent delivery issue, including the Activity trace showing that the response was successfully generated.

That distinction should help Support investigate the correct hop instead of troubleshooting the SharePoint knowledge source again.
Suggested answer

Valantis 7,545 Super User 2026 Season 2 on at

Like
a
(0)

Report
Copy link

Link copied!

Hi @CU27080519-2,

A Copilot Studio orchestrator with connected agents hits this exact pattern, works in test pane, activity log shows the connected agent's response was generated, M365 Copilot and Teams both show the generic fallback instead.https://learn.microsoft.com/en-us/answers/questions/5942484/copilot-studio-orchestrator-agent-returns-sorry-i

A GitHub issue on the official microsoft/Agents repo describes the same pattern more broadly, external skill responses completing successfully in the activity trace but never relayed to the user on SharePoint and M365 Copilot specifically. States plainly this isn't documented anywhere.https://github.com/microsoft/Agents/issues/576

Two things worth testing that haven't come up yet. One, a separate case ties this exact message to a stale channel config after republishing, fix is toggling the Teams or M365 Copilot channel off and back on in Copilot Studio, then republishing.https://learn.microsoft.com/en-us/answers/questions/5891103/encountered-response-failures-after-updating-or-re

Two, another case ties it to the signed in test user not holding an M365 Copilot license specifically, separate from Copilot Studio access. Worth confirming your test users' licensing.https://learn.microsoft.com/en-us/answers/questions/5789363/inconsistent-responses-from-copilot-studio-custom

Best regards,

Valantis

✅ If this helped solve your issue, please Accept as Solution so others can find it quickly.

❤️ If it didn’t fully solve it but was still useful, please click “Yes” on “Was this reply helpful?” or leave a Like :).

🏷️ For follow-ups @Valantis.

📝 https://valantisond365.com/ 💼 LinkedIn ▶️ YouTube