ChatResponseExtensions.ToChatResponse; No messageId present

[flintlouis]

Hi,
When using the OllamaApiClient, after getting the IAsyncEnumerable<ChatResponseUpdate> responseStream from GetStreamingResponseAsync(), I use the ChatResponseExtensions.ToChatResponse() from Micrsoft.Extensions.AI to squash all the seperate response chunks into a ChatResponse with a list of response messages. This extension uses the MessageId to distuingish which response chunks belong to which message and seperates it in this way.
But with the ChatResponseStream there are no message ID's implemented so this extension method just adds all AIContent into 1 message, even if it has a different role.

I was wondering, is it an idea to add messageId's to the ollama Message?

Example:
Before:
responseChunks =
[
{ role: assistant, content: [text] },
{ role: assistant, content: [tool_call] },
{ role: tool, content: [tool_response] },
{ role: assistant, content: [text] }
]
After:
response.Messages =
[
{ role: assistant, content: [text, tool_call, tool_response, text] }
]

[ypyl]

Any updated regarding it? AGUI from https://github.com/microsoft/agent-framework is also using MessageId to emit proper events

[awaescher]

I see, thanks for the shoutout. To be honest, I mean we could improve the aggregation logic - I'd be happy to review a pull-request, by the way. But I'd draw the whole picture more like this:
As the ecosystem grows daily or at least weekly and new patterns emerge left and right, I personally think we should encourage people to use Semantic Kernel or the newer Agent Framework.
This does not mean this project is getting obsolete. As I tried to write here, OllamaSharp will be the runtime that powers these frameworks when Ollama is being used. But it doens't make much sense to reimplement all the features these frameworks already provide today.
I think people should go with the standards Microsoft sets these days, not just because of a huge ecosystem of plugins and extensions but also to be more flexible for future use cases like adding new providers to choose from next to Ollama.

What would that mean for you?
Adding OllamaSharp + the Microsoft framework of your choice (I'd recommend the Agent Framework) and setting up Ollama as an provider. From there on, you can make use of features Microsoft releases very frequently, while OllamaSharp is taking care of the communication to your Ollama service.

[ypyl]

Thanks for the clarification: that aligns with my understanding of the intended architecture.
In my case, I am already using the Agent Framework on top of OllamaSharp (via Microsoft.Extensions.AI.Ollama) and exposing AGUI using MapAGUI (as it is suggested here). The integration issue I am hitting is that OllamaSharp does not populate MessageId, while the Agent Framework relies on it for emitting AGUI events such as TextMessageStart.

So from my perspective this is not about reimplementing framework features, but about provider compliance with the Agent Framework contract. If OllamaSharp is positioned as the runtime powering these frameworks when Ollama is used, then setting MessageId seems to be part of that responsibility.

I’m raising this to clarify ownership: whether MessageId generation is expected from the provider layer (OllamaSharp), intentionally delegated elsewhere, or if this is actually something that should be handled within the Agent Framework itself. Or end user should do it by using a middleware.

If it makes sense architecturally for OllamaSharp to set and propagate MessageId, I’m happy to prepare a PR.

Sample code that I am trying to run (not working):

var chatClient = new OllamaApiClient(
    new Uri("http://localhost:11434"),
    "lfm2.5-thinking:latest");
var agent = chatClient.AsAIAgent(instructions: "You are a helpful assistant.");
app.MapAGUI("/", agent);
await app.RunAsync();

there is a middleware that I am using now to get the correct set of events from the server (working workaround):

async IAsyncEnumerable<ChatResponseUpdate> CustomChatClientStreamingMiddleware(
    IEnumerable<ChatMessage> messages,
    ChatOptions? options,
    IChatClient innerChatClient,
    [EnumeratorCancellation] CancellationToken cancellationToken)
{
    var id = Guid.NewGuid().ToString()[..8];

    await foreach (var chatResponseUpdate in innerChatClient.GetStreamingResponseAsync(messages, options, cancellationToken))
    {
        chatResponseUpdate.MessageId = id;
        yield return chatResponseUpdate;
    }
}
AIAgent agent = ((IChatClient)chatClient).AsBuilder().Use(getResponseFunc: null, getStreamingResponseFunc: CustomChatClientStreamingMiddleware)
    .Build().AsAIAgent(options);

[awaescher]

Oh I was not aware that it seems to be an issue in this setup, too. I'd need to look into this. Thanks for clarifying.