Multi-Agent Orchestration with Semantic Kernel in C#: AgentGroupChat and Selection Strategies

When building AI-powered applications in C#, I've found that a single agent often isn't enough to handle complex tasks effectively. Multi-agent orchestration with Semantic Kernel in C# offers a powerful solution by letting specialized agents collaborate, each bringing unique expertise to solve problems that would overwhelm a generalist approach. Instead of trying to build one super-agent that does everything, the AgentGroupChat pattern enables us to compose systems where focused agents work together, each handling what they do best.

I've been working extensively with Semantic Kernel agents in C#, and the shift from single-agent to multi-agent systems has fundamentally changed how I approach complex automation. The key insight is that collaboration between specialized agents can produce better results in tasks that benefit from specialization -- individual results vary based on task and model -- compared to a single generalist agent attempting everything at once. In this article, I'll walk you through how to implement multi-agent orchestration Semantic Kernel C# systems using AgentGroupChat, explore different selection strategies that control agent interaction, and show you practical patterns for building robust multi-agent workflows in .NET.

Why Multi-Agent Systems?

Note: The Semantic Kernel agent functionality is currently experimental -- as an experimental feature, breaking changes may occur between versions without prior notice. Install the agent package with the --prerelease flag:

dotnet add package Microsoft.SemanticKernel.Agents.Core --prerelease

Additionally, AgentGroupChat orchestration is experimental per the official Semantic Kernel documentation.

Building multi-agent systems in C# with Semantic Kernel solves several critical problems that single-agent approaches struggle with.When I first started building AI agents with Semantic Kernel, I kept running into situations where one agent had to juggle too many responsibilities, leading to inconsistent results and bloated prompts that were difficult to maintain.

The power of specialization in multi-agent orchestration Semantic Kernel C# systems cannot be overstated. Instead of training a single agent to research, write, and edit content, I can create three focused agents where each excels at one task. The researcher agent becomes excellent at finding facts because that's all it does. The writer agent focuses solely on clear communication. The editor agent specializes in quality control. Each agent's instructions remain concise and focused, making them easier to test, debug, and improve independently when doing multi-agent orchestration Semantic Kernel C# development.

Decomposing complex tasks into agent-specific responsibilities also mirrors how real software teams work (this is an architectural analogy; actual performance depends on model capabilities and task design). Just as we use the Chain of Responsibility pattern to pass requests through a pipeline of handlers, multi-agent systems create a pipeline where each agent contributes its expertise before passing control to the next specialist. This separation of concerns makes our AI systems more maintainable and easier to reason about.

Multi-agent architectures also open opportunities for parallelism that single agents cannot exploit. When tasks have independent subtasks, multiple agents can work simultaneously in your multi-agent orchestration Semantic Kernel C# system, potentially reducing total processing time (no universal benchmark -- test with your specific workload). The orchestration layer manages coordination while each agent focuses on its specific domain, making multi-agent orchestration Semantic Kernel C# ideal for complex workflows.

AgentGroupChat: The Foundation of Multi-Agent Orchestration Semantic Kernel C#

AgentGroupChat is the core container that manages conversations among multiple agents in Semantic Kernel. I think of it as the meeting room where agents gather to collaborate on a shared task, with the group chat managing the conversation flow, tracking message history, and deciding which agent speaks next based on the configured selection strategy. This is the foundation for all multi-agent orchestration Semantic Kernel C# implementations.

When you create an AgentGroupChat, you provide it with a collection of agents that will participate in the conversation. The group chat maintains a shared conversation history that all agents can see, enabling them to build on each other's contributions. Each message in the chat includes the author's name, making it clear which agent said what and allowing agents to respond to specific contributions from their colleagues.

The conversation flow in AgentGroupChat follows a clear pattern. First, you add an initial message to the chat, typically from a user role, describing the task or question you want the agents to address. Then, as you invoke the group chat, it uses its selection strategy to pick which agent should respond next. That agent processes the full conversation history and adds its response. This cycle continues until a termination strategy signals that the conversation is complete. Understanding this message flow is essential for designing effective multi-agent systems because it determines how information moves between your specialized agents.

The ExecutionSettings property on AgentGroupChat gives you fine-grained control over how agents interact. Here you configure the selection strategy that picks who speaks next, the termination strategy that decides when the conversation ends, and other behavioral parameters that shape the group dynamics. Getting these settings right is crucial for creating multi-agent systems that collaborate effectively rather than talking past each other.

Sequential Selection Strategy

The sequential selection strategy is the simplest way to orchestrate multiple agents, and it's where I recommend starting when learning multi-agent orchestration Semantic Kernel C# patterns. This strategy rotates through your agents in the order you provided them to the AgentGroupChat, ensuring each agent gets a turn before cycling back to the first agent.

I use sequential selection when the task has a natural linear flow where agents build on the previous agent's work. Content creation pipelines are perfect examples -- research first, then write, then edit. Each phase depends on the previous phase completing, so having agents take turns in a predictable order makes sense both logically and practically.

Here's a complete working example showing sequential selection with a researcher and writer collaborating:

using Microsoft.SemanticKernel;
using Microsoft.SemanticKernel.Agents;
using Microsoft.SemanticKernel.Agents.Chat;
using Microsoft.SemanticKernel.ChatCompletion;

var builder = Kernel.CreateBuilder();
builder.AddOpenAIChatCompletion("gpt-4o", Environment.GetEnvironmentVariable("OPENAI_API_KEY")!);
var kernel = builder.Build();

var researcherAgent = new ChatCompletionAgent
{
    Name = "Researcher",
    Instructions = """
        You are a research specialist. When given a topic, identify the 5 most important 
        facts that developers should know. Keep your research concise and focused on 
        technical accuracy. Format as a numbered list.
        """,
    Kernel = kernel
};

var writerAgent = new ChatCompletionAgent
{
    Name = "Writer",
    Instructions = """
        You are a technical writer. Take the research provided and craft a clear, 
        engaging introduction paragraph for .NET developers. Use the facts from the 
        research and make them accessible. After writing, say 'DONE' on a new line.
        """,
    Kernel = kernel
};

#pragma warning disable SKEXP0110
var groupChat = new AgentGroupChat(researcherAgent, writerAgent)
{
    ExecutionSettings = new AgentGroupChatSettings
    {
        SelectionStrategy = new SequentialSelectionStrategy()
    }
};

groupChat.ExecutionSettings.TerminationStrategy.MaximumIterations = 4;
#pragma warning restore SKEXP0110

groupChat.AddChatMessage(new ChatMessageContent(
    AuthorRole.User,
    "Create content about async/await in C#"));

Console.WriteLine("Sequential agent collaboration:
");

await foreach (var message in groupChat.InvokeAsync())
{
    Console.WriteLine($"[{message.AuthorName}]:");
    Console.WriteLine(message.Content);
    Console.WriteLine("---
");
}

The sequential pattern works beautifully when you have a clear workflow where each agent's output becomes the next agent's input. The predictability makes debugging easier because you know exactly which agent will speak next. However, sequential selection can become inefficient if one agent needs to speak multiple times before moving to the next agent, which is where custom selection strategies come into play.

Custom Selection Strategy

Custom selection strategies give you complete control over which agent speaks next in your multi-agent orchestration Semantic Kernel C# applications, and the most powerful approach I've found is using a KernelFunctionSelectionStrategy that leverages an LLM to make intelligent decisions about who should contribute next based on the conversation context.

The KernelFunctionSelectionStrategy works by calling a Semantic Kernel function that examines the conversation history and returns the name of the agent that should speak next. This function-based approach is incredibly flexible for multi-agent orchestration Semantic Kernel C# because you can use prompt engineering to create sophisticated selection logic without writing complex C# code. The LLM analyzes what's been said, understands the current state of the task, and picks the most appropriate agent to move the conversation forward.

Here's how to implement a custom selection strategy that lets an LLM decide who speaks next:

using Microsoft.SemanticKernel;
using Microsoft.SemanticKernel.Agents;
using Microsoft.SemanticKernel.Agents.Chat;

var builder = Kernel.CreateBuilder();
builder.AddOpenAIChatCompletion("gpt-4o", Environment.GetEnvironmentVariable("OPENAI_API_KEY")!);
var kernel = builder.Build();

var selectionFunction = KernelFunctionFactory.CreateFromPrompt(
    """
    Examine the conversation history and decide which agent should speak next.
    Available agents: {{$agents}}
    
    Choose based on these rules:
    - If no research exists yet, choose Researcher
    - If research exists but no content, choose Writer  
    - If content exists but hasn't been reviewed, choose Editor
    - If Editor approved, choose Researcher for next topic
    
    Return only the agent name, nothing else.
    
    History:
    {{$history}}
    """);

var selectionStrategy = new KernelFunctionSelectionStrategy(selectionFunction, kernel)
{
    // Optional: configure how history is formatted
    HistoryVariableName = "history",
    AgentsVariableName = "agents"
};

#pragma warning disable SKEXP0110
var groupChat = new AgentGroupChat(researcherAgent, writerAgent, editorAgent)
{
    ExecutionSettings = new AgentGroupChatSettings
    {
        SelectionStrategy = selectionStrategy
    }
};

groupChat.ExecutionSettings.TerminationStrategy.MaximumIterations = 15;
#pragma warning restore SKEXP0110

For even more control, you can create a custom SelectionStrategy subclass that implements your own logic in C#:

public class PrioritySelectionStrategy : SelectionStrategy
{
    private readonly Dictionary<string, int> _agentPriorities;
    
    public PrioritySelectionStrategy(Dictionary<string, int> priorities)
    {
        _agentPriorities = priorities;
    }
    
    protected override Task<Agent> SelectAgentAsync(
        IReadOnlyList<Agent> agents,
        IReadOnlyList<ChatMessageContent> history,
        CancellationToken cancellationToken = default)
    {
        // Find agents that haven't spoken yet in this round
        var lastRoundStart = history.Count - agents.Count;
        if (lastRoundStart < 0) lastRoundStart = 0;
        
        var recentSpeakers = history
            .Skip(lastRoundStart)
            .Select(m => m.AuthorName)
            .ToHashSet();
        
        var availableAgents = agents
            .Where(a => !recentSpeakers.Contains(a.Name))
            .ToList();
        
        // If everyone spoke, start new round with highest priority
        if (availableAgents.Count == 0)
            availableAgents = agents.ToList();
        
        // Select highest priority agent from available
        var selectedAgent = availableAgents
            .OrderByDescending(a => _agentPriorities.GetValueOrDefault(a.Name, 0))
            .First();
        
        return Task.FromResult(selectedAgent);
    }
}

Custom selection strategies shine when your multi-agent workflow has complex decision points where the next step depends on the quality or content of previous responses. I've used this pattern to build review cycles where an editor agent can request revisions from the writer, or to create adaptive workflows where different specialist agents activate based on the type of problem detected.

Termination Strategies

Termination strategies determine when a multi-agent conversation should end in your multi-agent orchestration Semantic Kernel C# implementation, and choosing the right strategy is critical for preventing runaway conversations while ensuring agents have enough iterations to complete their work. Without proper termination, your agent group chat could continue indefinitely, burning through API tokens and never delivering a final result.

The DefaultTerminationStrategy is the simplest approach and the one I use most often. It stops the conversation after a specified number of iterations, providing a hard limit that prevents infinite loops. You can optionally configure it to only count iterations where specific agents spoke, giving you fine-grained control over the termination condition:

var terminationStrategy = new DefaultTerminationStrategy
{
    MaximumIterations = 10,
    Agents = [editorAgent] // Only count iterations where editor speaks
};

The KernelFunctionTerminationStrategy uses an LLM to decide when the conversation is complete by evaluating the conversation history against criteria you define in a prompt. This approach is powerful for complex workflows where the completion condition isn't just about iteration count but about the quality or completeness of the agents' work:

var terminationFunction = KernelFunctionFactory.CreateFromPrompt(
    """
    Review this conversation history and determine if the task is complete.
    
    The task is complete when:
    1. Research has been provided
    2. Content has been written based on the research
    3. Editor has reviewed and approved with 'APPROVED'
    
    History:
    {{$history}}
    
    Return 'YES' if complete, 'NO' if more work is needed.
    """);

var terminationStrategy = new KernelFunctionTerminationStrategy(terminationFunction, kernel)
{
    ResultParser = (result) => result.GetValue<string>()?.Contains("YES") ?? false
};

For maximum flexibility, you can implement a custom TerminationStrategy subclass that embeds your own logic. Here's an example that stops when the editor agent gives approval:

public class ApprovalTerminationStrategy : TerminationStrategy
{
    protected override Task<bool> ShouldAgentTerminateAsync(
        Agent agent,
        IReadOnlyList<ChatMessageContent> history,
        CancellationToken cancellationToken)
    {
        // Only check after the editor speaks
        if (agent.Name != "Editor") return Task.FromResult(false);
        
        var lastMessage = history.LastOrDefault()?.Content ?? "";
        return Task.FromResult(lastMessage.Contains("APPROVED"));
    }
}

I typically combine termination strategies by setting both a maximum iteration limit and a content-based termination condition. The iteration limit acts as a safety net preventing runaway costs, while the content-based condition allows successful completion before hitting the limit. This dual approach gives you both safety and efficiency in your multi-agent orchestration Semantic Kernel C# implementations.

Specialized Agent Patterns

As I've built more multi-agent orchestration Semantic Kernel C# systems, I've discovered several patterns that consistently work well for different types of problems. These patterns aren't rigid frameworks but rather proven approaches you can adapt to your specific needs, similar to how we use design patterns like the Observer pattern in traditional C# development.

The manager-worker pattern uses a coordinator agent that breaks down tasks and delegates to specialized worker agents. The manager agent understands the overall goal, decomposes it into subtasks, and assigns each subtask to the appropriate worker. This pattern works exceptionally well for complex projects where different expertise areas need to contribute. I typically implement the manager as the first agent in a sequential selection strategy, letting it analyze the task and explicitly state which workers should handle which pieces:

var managerAgent = new ChatCompletionAgent
{
    Name = "Manager",
    Instructions = """
        You coordinate the team. Break down the user's request into subtasks 
        and explicitly state which team member should handle each part.
        Available team: DataAnalyst, ReportWriter, QualityChecker
        """,
    Kernel = kernel
};

The critic-creator pattern pairs a generative agent with a critical reviewer agent. The creator agent produces initial work, then the critic agent evaluates it against quality criteria and provides specific feedback. The creator then revises based on the feedback. This back-and-forth continues until the critic approves the work. I've used this pattern extensively for content generation where quality is paramount:

var creatorAgent = new ChatCompletionAgent
{
    Name = "Creator",
    Instructions = "Generate technical content based on requirements. Revise based on feedback.",
    Kernel = kernel
};

var criticAgent = new ChatCompletionAgent  
{
    Name = "Critic",
    Instructions = """
        Review the content for technical accuracy, clarity, and completeness.
        If issues exist, provide specific, actionable feedback.
        If quality is acceptable, respond with 'APPROVED'.
        """,
    Kernel = kernel
};

The planner-executor pattern separates strategic thinking from tactical implementation. The planner agent creates a detailed step-by-step plan to accomplish the goal, then executor agents carry out each step of the plan. This pattern shines when you need to ensure a coherent strategy before taking action. The planner's output becomes a roadmap that executor agents follow, providing traceability and making it easier to debug when things go wrong:

var plannerAgent = new ChatCompletionAgent
{
    Name = "Planner",
    Instructions = """
        Create a numbered step-by-step plan to accomplish the user's goal.
        Be specific about what each step should achieve.
        Do not execute steps, only plan them.
        """,
    Kernel = kernel
};

var executorAgent = new ChatCompletionAgent
{
    Name = "Executor", 
    Instructions = """
        Execute the next step from the plan that hasn't been completed yet.
        Reference the step number you're working on.
        Report completion clearly.
        """,
    Kernel = kernel
};

These patterns can be combined and nested to create sophisticated multi-agent systems. I've built systems where a planner-executor pattern operates at the high level, with each executor actually being a manager-worker group chat for its domain. The key is starting simple and adding complexity only when your requirements demand it.

Full Example: Content Creation Pipeline

Let me show you a complete runnable example that brings together everything we've covered. This content creation pipeline uses three specialized agents -- a researcher, a writer, and an editor -- orchestrated by AgentGroupChat to collaborate on producing quality technical content:

using Microsoft.SemanticKernel;
using Microsoft.SemanticKernel.Agents;
using Microsoft.SemanticKernel.Agents.Chat;
using Microsoft.SemanticKernel.ChatCompletion;
using Microsoft.SemanticKernel.Connectors.OpenAI;

var builder = Kernel.CreateBuilder();
builder.AddOpenAIChatCompletion("gpt-4o", Environment.GetEnvironmentVariable("OPENAI_API_KEY")!);
var kernel = builder.Build();

var researcherAgent = new ChatCompletionAgent
{
    Name = "Researcher",
    Instructions = """
        You are a research specialist. When given a topic:
        1. Identify 5 key facts or statistics about the topic
        2. Note 2-3 common misconceptions people have
        3. Suggest the most important angle for a technical article
        Format your output as structured research notes.
        """,
    Kernel = kernel
};

var writerAgent = new ChatCompletionAgent
{
    Name = "Writer",
    Instructions = """
        You are a technical writer for .NET developers.
        Take the research notes provided and write a clear, engaging article introduction (2-3 paragraphs).
        Use concrete examples and avoid jargon.
        After writing, say 'WRITING COMPLETE' on its own line.
        """,
    Kernel = kernel
};

var editorAgent = new ChatCompletionAgent
{
    Name = "Editor",
    Instructions = """
        You are a senior editor reviewing technical content.
        Review the written content and provide specific feedback on:
        - Technical accuracy
        - Clarity and readability  
        - Missing context for the target audience (.NET developers)
        After your review, say 'APPROVED' if the content is good, or 'NEEDS REVISION: [reason]' if not.
        """,
    Kernel = kernel
};

#pragma warning disable SKEXP0110
var groupChat = new AgentGroupChat(researcherAgent, writerAgent, editorAgent)
{
    ExecutionSettings = new AgentGroupChatSettings
    {
        SelectionStrategy = new SequentialSelectionStrategy()
    }
};

groupChat.ExecutionSettings.TerminationStrategy.MaximumIterations = 9; // 3 rounds of 3 agents
groupChat.ExecutionSettings.TerminationStrategy.Agents = [editorAgent]; // Only editor can terminate
#pragma warning restore SKEXP0110

groupChat.AddChatMessage(new ChatMessageContent(
    AuthorRole.User, 
    "Create a technical article introduction about Semantic Kernel plugins in C#"));

Console.WriteLine("Starting multi-agent content pipeline...
");

await foreach (var message in groupChat.InvokeAsync())
{
    Console.WriteLine($"[{message.AuthorName}]:");
    Console.WriteLine(message.Content);
    Console.WriteLine("---");
}

Console.WriteLine("
Pipeline complete!");

This example demonstrates several key concepts working together. The sequential selection strategy ensures each agent contributes in order -- research, then writing, then editing. The termination strategy allows up to nine total iterations but can end early if the editor approves the work. Each agent has focused instructions that define its specific role in the pipeline, and the conversation history allows each agent to see and build on what previous agents contributed.

When you run this code, you'll see the researcher gather facts about Semantic Kernel plugins, the writer craft an introduction using those facts, and the editor provide feedback. If the editor requests revisions, the cycle continues with the researcher potentially adding more context, the writer revising, and the editor reviewing again. This collaborative process can produce better results in tasks that benefit from specialized handling than any single agent could achieve alone -- individual results will vary based on task and model.

The beauty of this pipeline is its modularity. I can swap out individual agents to change the behavior without touching the orchestration logic. Want a different writing style? Replace the writer agent's instructions. Need more rigorous editing? Update the editor's criteria. The Semantic Kernel plugins system even allows you to give agents access to external tools and data sources, dramatically expanding what they can accomplish.

Handling Agent Disagreement

Agent disagreement is inevitable in multi-agent systems, and learning to manage it effectively separates robust implementations from fragile ones. When multiple agents evaluate the same situation, they will sometimes reach different conclusions or contradictory recommendations, and your orchestration strategy needs to handle these conflicts gracefully.

The most effective approach I've found is building disagreement resolution directly into agent prompts. I give agents explicit instructions on how to handle conflicting information from other agents. For example, an editor agent might be told that when the writer disagrees with research findings, the editor should request clarification from the researcher rather than making assumptions. This turns potential conflicts into additional rounds of refinement:

var editorAgent = new ChatCompletionAgent
{
    Name = "Editor",
    Instructions = """
        Review the content for accuracy and quality.
        
        If the Writer's content contradicts the Researcher's facts:
        1. Point out the specific contradiction
        2. Request clarification from the Researcher
        3. Do not approve until the contradiction is resolved
        
        If the content aligns with research, provide approval or revision feedback.
        """,
    Kernel = kernel
};

Another approach is designating one agent as the final authority in your domain. In a content pipeline, the editor agent might have the power to override disagreements between the researcher and writer. In a technical decision system, a senior architect agent might resolve conflicts between multiple junior agents proposing different implementation approaches. The key is making the authority structure explicit in your agent instructions so agents know whose input takes precedence.

Termination strategies serve as a critical escape valve when agents can't reach consensus. Your maximum iteration limit ensures that even if agents continue disagreeing, the conversation eventually ends and you can escalate to human review. I often log disagreement patterns so I can refine agent instructions to reduce friction in future runs. If two agents consistently disagree about the same type of issue, that's a signal that one or both agents need better instructions or examples.

You can also implement voting mechanisms in custom selection strategies where multiple agents evaluate an output and the majority opinion determines the next action. This works well for quality assurance scenarios where you want confidence that multiple reviewers agree before proceeding. However, voting adds iterations and cost, so I reserve it for high-stakes decisions where consensus is worth the additional LLM calls.

Performance Considerations

Token costs in multi-agent orchestration Semantic Kernel C# systems can escalate quickly because each agent sees the entire conversation history every time it responds. With a long conversation and several agents, you might be sending thousands of tokens per agent invocation, and those costs multiply rapidly. I monitor token usage carefully in my multi-agent orchestration Semantic Kernel C# projects and have learned several techniques to keep multi-agent systems efficient.

The most effective optimization is keeping agents focused with terse, specific instructions. Verbose agent prompts and rambling responses waste tokens on every iteration. I train my agents to be concise, use structured formats where possible, and get to the point quickly. Instead of letting a researcher agent write paragraph after paragraph, I have it output bullet points or structured JSON that the writer agent can consume more efficiently.

Limiting conversation history is another powerful technique. AgentGroupChat settings allow you to control how many messages are retained in the history. For some workflows, agents only need to see the last few messages rather than the entire conversation from the beginning. Truncating history reduces the context sent to each LLM call, directly reducing token costs:

#pragma warning disable SKEXP0110
var groupChat = new AgentGroupChat(researcherAgent, writerAgent, editorAgent)
{
    ExecutionSettings = new AgentGroupChatSettings
    {
        SelectionStrategy = new SequentialSelectionStrategy()
    }
};

groupChat.ExecutionSettings.TerminationStrategy.MaximumIterations = 10;
#pragma warning restore SKEXP0110

// Only keep last 6 messages in history to reduce token costs
var historyReducer = new ChatHistoryTruncationReducer(6);
groupChat.HistoryReducer = historyReducer;

I also watch carefully for runaway conversations where agents get stuck in unproductive loops. If your researcher and writer keep going back and forth without making progress toward completion, you're burning tokens without value. Strong termination strategies and clear success criteria in agent prompts help prevent this. Each agent should know what success looks like and should signal clearly when its job is done.

Consider using cheaper models for simpler agents when your architecture allows it. Not every agent needs GPT-4 level capabilities. If an agent is just formatting data or performing simple validation, a smaller, faster model might work fine and dramatically reduce costs. You can configure different models for different agents by giving each agent its own Kernel instance with the appropriate model configuration.

Finally, I test multi-agent workflows with small, simple inputs first before running them at scale. This lets me identify inefficiencies, redundant iterations, or agents that aren't contributing value. Optimizing the workflow with test cases prevents expensive surprises when you start processing real workloads.

FAQ

Can I mix different LLM models in the same AgentGroupChat?

Yes, each agent can use its own Kernel instance configured with different models. This lets you use expensive, capable models for complex reasoning agents while using cheaper models for simpler agents like formatters or validators. Just create separate kernels with different AddOpenAIChatCompletion or AddAzureOpenAIChatCompletion calls and assign them to agents accordingly.

How do I debug which agent is causing problems in a group chat?

I add extensive logging to track each agent's input and output. The ChatMessageContent objects in the conversation history include the AuthorName property showing which agent spoke, so you can trace exactly what each agent saw and how it responded. I also test agents individually before adding them to group chats to verify their instructions produce the expected behavior in isolation.

What happens if an agent throws an exception during a group chat?

The exception will bubble up from the InvokeAsync call and terminate the group chat execution. You should wrap the InvokeAsync loop in try-catch blocks to handle failures gracefully. If you want the group chat to continue despite individual agent failures, you'll need to implement a custom agent wrapper that catches exceptions and returns error messages instead of throwing.

Can agents talk to each other directly without going through the group chat?

No, all agent communication in AgentGroupChat flows through the shared conversation history. Agents don't have direct peer-to-peer communication channels. However, agents can address specific other agents by name in their responses, and you can write agent instructions that teach them to recognize and respond to direct mentions. This simulates direct communication while maintaining the centralized conversation history that makes debugging and auditing possible.

Conclusion

Multi-agent orchestration with Semantic Kernel in C# can significantly change how we build complex AI-powered systems by replacing monolithic generalist agents with teams of focused specialists. AgentGroupChat provides the orchestration infrastructure, selection strategies control the conversation flow, and termination strategies ensure conversations reach meaningful conclusions without running indefinitely.

I've found that starting with simple sequential selection strategies and basic termination limits gives you immediate value with minimal complexity. As your needs grow more sophisticated, you can layer in custom selection strategies that use LLMs to make intelligent routing decisions, and implement specialized termination strategies that recognize task completion based on content rather than just iteration count.

The specialized agent patterns -- manager-worker, critic-creator, and planner-executor -- provide proven templates for common multi-agent scenarios. These patterns scale from simple three-agent pipelines to complex hierarchical systems where groups of agents collaborate at different levels of abstraction. The key is maintaining clear responsibilities for each agent, explicit coordination logic in your selection strategies, and robust termination conditions that prevent runaway conversations.

As you build your own multi-agent systems in .NET, focus on giving each agent a specific, well-defined role with focused instructions. Design your orchestration to match the natural flow of your domain, whether that's sequential processing through a pipeline or dynamic selection based on conversation context. Monitor performance carefully to avoid token waste, and remember that simpler architectures often outperform complex ones until you have specific evidence that the complexity is warranted. Multi-agent orchestration Semantic Kernel C# systems work best when they mirror how human teams collaborate (this is an architectural analogy; actual performance depends on model capabilities and task design), with clear specialization, explicit communication, and mechanisms to resolve disagreements and reach consensus.