.NET: Agent AuthorName not preserved during group chat role-switching

[ltwlf]

Summary

In group chat workflows using AgentWorkflowBuilder, agent responses lose their original AuthorName during role-switching between ChatRole.Assistant and ChatRole.User. This causes routing failures and incorrect message attribution in multi-agent conversations.

Reproduction

Note: This is a timing-dependent issue that may not reproduce consistently. It appears to be a race condition in how ChatMessage objects are modified during role-switching.

1. Create a group chat workflow with multiple agents (5+ agents increases likelihood)
2. Implement custom GroupChatManager that checks message.AuthorName for routing
3. Run workflow with multiple sequential agent responses
4. Intermittently, SelectNextAgentAsync receives messages with incorrect AuthorName values
5. Messages that should have AuthorName="agentA" instead show AuthorName="facilitator" or other incorrect values

Expected Behavior

Agent responses should maintain their original AuthorName throughout the workflow, regardless of role-switching operations.

Actual Behavior

• AuthorName is set from agent's Name property during initial response
• Role-switching changes Role but loses AuthorName
• Restored messages have correct Role but AuthorName remains incorrect or null
• Causes routing failures when checking message author for turn-taking logic
• Timing-dependent: Appears to be a race condition where message modifications aren't fully synchronized
• Inconsistent: Same workflow may work correctly on some runs, fail on others

Impact

• Custom routing managers cannot reliably identify message authors
• Multi-agent conversations fail or route incorrectly
• Conversation history shows incorrect attribution
• Affects any workflow using AgentWorkflowBuilder.CreateGroupChatBuilderWith()

Additional Notes

Debugging: The issue is difficult to trace because:

• Streaming events (AgentRunUpdateEvent) show correct AuthorName values
• But ChatMessage history passed to SelectNextAgentAsync shows incorrect values
• Suggests the issue is in how messages are modified/restored between event emission and history building
• Adding debug logging to ChangeAssistantToUserForOtherParticipants and ResetUserToAssistantForChangedRoles helps identify when attribution is lost

Related issues discovered:

• Agent name comparison uses case-sensitive string matching (should be case-insensitive)
• DisplayName property used for routing instead of stable Name property

I'm preparing a PR with fixes for these issues.

[ltwlf]

I finally tracked it down, but it costs me the entire weekend 😅

In multi-agent workflows (sequential/handoff), assistant messages get the AuthorName of the next agent. The issue is not the role switching - it is deeper.

Root cause: null-MessageId streaming updates are appended to the previous message during reconstruction, and last-write-wins metadata (AuthorName) overwrites the prior message.

Where it happens

• Agent sets author on every streaming update (expected):
  • agent-framework/dotnet/src/Microsoft.Agents.AI/ChatClient/ChatClientAgent.cs → RunStreamingAsync

  if (update is not null)
  {
      update.AuthorName ??= this.Name; // all updates, including reasoning/non-message deltas
  }

• Workflow reconstructs messages from updates:
  • agent-framework/dotnet/src/Microsoft.Agents.AI.Workflows/AgentWorkflowBuilder.cs → AgentRunStreamingExecutor

  // before fix
  messages.AddRange(updates.ToAgentRunResponse().Messages);

  • ToAgentRunResponse() (Microsoft.Extensions.AI) uses MessageId for boundaries; null MessageId updates are treated as part of the previous message, polluting metadata.

Fix (workflow layer)

Filter out updates without MessageId before reconstruction:

var filtered = updates.Where(u => !string.IsNullOrEmpty(u.MessageId)).ToList();
if (filtered.Count > 0)
{
    messages.AddRange(filtered.ToAgentRunResponse().Messages);
}

• Should be applied in sequential and handoff executors.

Why not filter in ChatClientAgent

That would drop legitimate reasoning/metadata deltas in single-agent scenarios. The correct boundary fix belongs at the workflow layer where multi-agent reconstruction happens.

Microsoft.Extensions.AI

I will create a separate issue in Microsoft.Extensions.AI repo to Ignore or separately handle null-MessageId updates in ToChatResponse/ToAgentRunResponse so they don’t participate in message boundary detection.

I will prepare a PR to fix this...

[ltwlf]

@markwallace-microsoft you can assign me to this

[stephentoub]

Dropping updates / messages without id's is not valid. It will need a different solution.

[stephentoub]

Note that the next release of M.E.AI factors author name into message coalescing.
dotnet/extensions#6910

[ltwlf]

I will test with the new build of M.E.AI