When developing an agent for M365 Copilot using the Agent SDK, I encountered some issues.

[leobleumer]

Background:
I’m currently focused on developing an Agent that works with M365 Copilot Chat, but I’ve encountered some issues. I’d like to ask whether these are limitations of the SDK or bugs.

Regarding this Agent, its functionality and presentation are very similar to the Researcher Agent shown below. It needs to analyze the user’s input, then call backend APIs (which take some time to process) to retrieve streaming SSE data, and finally process and stream the data back to the user.

Questions:
1.When I use turnContext.StreamingResponse.QueueTextChunk to push messages to Copilot 365, it always seems to disconnect after about 5 minutes. Does this mean M365 Copilot has a built-in timer that forcibly closes a StreamingResponse object? (I set the EndStreamTimeout property, but it still disconnects.)

2.How can I keep M365 Copilot in a continuous loading state? Researcher does this very well. Although I can use QueueInformativeUpdateAsync to maintain the loading state, it doesn’t accept Adaptive Cards, so I’m curious how Researcher achieves this.

3.Simply put, does the current .NET Agent SDK support building an agent like Researcher Or should I use the Node.js SDK instead of the .NET SDK? Are there any sample examples or document available?

Thanks~

[MattB-msft]

You are seeing limitations in M365 Copilot.
That client requires a response within 15 seconds of sending the request.
Then you must continue to update it ~45 seconds until the request completes,
if you fail to do that, the Client will time out and not receive further updates.

its a bit hard to find information on this.. however you can see it here:

https://learn.microsoft.com/en-us/microsoft-365-copilot/extensibility/custom-engine-agent-asynchronous-flow

Each user query should receive an initial response within 15 seconds. For long-running tasks, agents can send follow-up messages. A 45-second timeout applies between streaming updates.

The best pattern to use here shown in an example here:

Agents/samples/dotnet/azure-ai-streaming/StreamingAgent.cs

Line 65 in 616cab3

await turnContext.StreamingResponse.QueueInformativeUpdateAsync("Hold on for an awesome poem about Apollo...", cancellationToken);

This uses Informational Streaming updates to keep the connection alive while the LLM is working, ,then chunks messages back as the LLM delivers them.

When using tools, you would project the turncontext into the Tool invoker and send Informational updates as your LLM processes tool calls.
You can see that done in this example here:
https://github.com/microsoft/Agents/blob/616cab3f7721582c14c286064f1ea536c7e1cf63/samples/dotnet/semantic-kernel-multiturn/MyAgent.cs#L36C9-L46C101

and accessed inside a tool here: https://github.com/microsoft/Agents/blob/616cab3f7721582c14c286064f1ea536c7e1cf63/samples/dotnet/semantic-kernel-multiturn/Plugins/WeatherForecastPlugin.cs#L11C1-L11C61

[leobleumer]

Yes, I tried using the QueueInformativeUpdateAsync method, which keeps the client in a loading state. However, the downside is that once the client provides an answer (i.e., after QueueTextChunk sends a message), the messages from QueueInformativeUpdateAsync no longer appear. This means it can’t retain the reasoning or thought process like the Researcher agent does, and it also has the same time limitation. So I suspect that Researcher might be using Declarative Agents Plus. Thanks, @MattB-msft